Excessive entities with duplicated names

[Znegl]

The problem

I added my Vølund/Nibe S2125 heatpump with a SMO20 control unit to the integration which results in 579 entities of which most of them have them same name repeated 3-8 times, making it impossible to know what to change and whether it works or not.

What version of Home Assistant Core has the issue?

core-2024.3.0

What was the last working version of Home Assistant Core?

none

What type of installation are you running?

Home Assistant OS

Integration causing the issue

myUplink

Link to integration documentation on our website

https://www.home-assistant.io/integrations/myuplink

Diagnostics information

config_entry-myuplink-aa203b31e92104d9ee609daef1916743.json

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @pajzo, @astrandb, mind taking a look at this issue as it has been labeled with an integration (myuplink) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `myuplink` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign myuplink` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

myuplink documentation myuplink source _{^{(message by IssueLinks)}}

[astrandb]

Thank you for reporting. This integration is fairly new and tested only with a few heatpump models. We use the API data to create relevant entities using best effort but there is obviously some tuning to do,

After a quick look through the diagnostic file I can see a few types of problems.

1. Problem in myUplink API - E.g the degree minutes data is repeated 16 times with exactly the same parameter name and id and slightly different no of decimals. The issue is reported to myUplink a month ago but we have only got a message that they have recieved the issue report.
2. A lot of sensors are multiplied, e.g. the ones shown on the screenshot above. They have identical names but different internal numbers in the API. The probably represent slots where there can be a real device behind, but in most cases there is not.

We will have to figure out a better way to hide irrelevant entities but that will take some time.

[astrandb]

@Znegl this issue seems to be specific to SMO20 (there might be other models affected too). I guess that 90-95% of the almost 600 published device points (=entities) are irrelevant to you at least in the Home Assistant context. Most other models publish 20-60 entities and therefore we chose to create entities for all data points. I have started a discussion with the Home Assistant core team to get ideas how to handle this problem. I suggested that users that are affected of this "entity storm" could create a list of points to include in configuration.yaml but the team is very reluctant to accept such a solution. The discussion continues... In the mean time I understand if the integration is more or less unusable for you. All good ideas are welcome.

[Znegl]

@astrandb After digging around the entities during the weekend it seems like the many duplicate entity names are just missing prefixes that are present when navigating the myUPlink app or the menu system on the heat pump. If there is anything I can do to provide those prefixes, I'll be happy to help.

I already figured out how to use the integration to boost the temperature of both my hot water and radiator/underfloor heating system when I'm producing excess solar power, so it's very much usable — just a bit confusing.

[astrandb]

Thanks. It would be helpful if you could take a few screenshots from the app so I can try to see it I can figure out something.

[astrandb]

@Znegl I would appreciate if you could share your system with me for a while. Goto system profile/security in the app or on the website. Read-only privileges are enough.

[Znegl]

@astrandb You should have received an invitation now.

Upon inspecting their API myself, it seems like some of the values are quite easy to convert to their enum values for easier understanding, whereas other (such as Current hot water mode) are very hard to get any sense of, because they behave like enums but are not configured as enums.

Also all of the scheduling stuff is just one long list with the same names. I haven't been able to find any documentation of which parameter ID matches which schedule, so it seems like it's a matter of trial and error (or just ignoring them).

[astrandb]

Thank you. Your unit is now visible in my account. To summarize the problem, the specification of the API is fine but the implementation sucks (for some models).

We have tried to avoid having mapping tables with 600 entries multiplied by the number of supported models. In your setting there are a handful of entities that are tagged with "smart-home-categories" indicating e.g outdoor temperatures, supply temperatures, hot-water-boost etc. We could create active entities for those tagged datapoints, keep a few more disabled by default, and just skip the majority. The problem is that we have this handling for SMO20 only. My F730 does not implement smart-home-categories, but as it publishes 55 entities with understandable names and no visible duplicates it is OK to show them all.

We should try to keep it simple in HA though. That can never be a platform for fine-tuning every aspect of a heat-pump installation. If we can monitor a handful of relevant parameters and control boost modes, home/away modes, adjust temp setpoint or curve shift and picking up alarm states that could perhaps be enough.

Perhaps we can setup a test later on, if you have a development environment for HA it is easy to share the branch, otherwise the integration can be installed as a custom_component with minimal manual adjustments.

[astrandb]

I have a version that creates entities for device points that have a smart-home-category assigned and a few hand-picked data points without a smart-home-category. All in all around 40 entities, most of them with understandable names. I just wait to get acceptance from the core reviewers to have this type of algorithm to select what entities that should be created.

[Znegl]

@astrandb That looks nice! I'm trying to get a beta install of Home Assistant running in Docker during the weekend, so that I'll be able to test it.

[astrandb]

It will not be available in the beta channel until march 27. You will have to load dev channel and that is updated every 24 hours for docker.

[Znegl]

Hi again @astrandb

I just set up an install of the dev channel on a Docker machine (on macOS) and sadly I'm getting an error when trying to set up the integration:

Here is the debug log for the integration: home-assistant_myuplink_2024-03-16T20-32-50.557Z.log

[astrandb]

Ah, there is a bug in the library, I have submitted a PR to fix and just waiting for the maintainer to return to keyboard. It easy to patch if you have access to the source code in your installation, but I don't know how to do it in the docker image. Better wait a day or two and it will be sorted out.

[astrandb]

The fix is merged into dev branch. The docker dev bulid will normally be available at 11.00-ish (CET) tomorrow.