StyraHem / ShellyForHASS

Shelly smart home platform for Home Assistant
MIT License
616 stars 111 forks source link

[BUG] Strange entity to devices to integration mapping when having integration added 2 (or more) times #696

Open bcutter opened 1 year ago

bcutter commented 1 year ago

Environment

Describe the bug

I added the custom Shelly integration a second time (accidentally, thought it would be the default one). Now I have two integrations with the same name. All entities of the Shelly devices wildly get sorted to the one or the other integration. In total it should be 26 entities. See screenshots below.

Steps to Reproduce

Add a second custom Shelly integration with the same name (nothing / default ("shelly")) and watch entities switching integrations wildly.

Expected behavior

Nothing will happen as no new devices are integrated. All devices and entities should stick to the first integration.

Screenshots

grafik 1st integration: grafik 2nd integration: grafik

Traceback/Error logs

Plenty of log entries (new ones - and HA has been restarted 2 minutes before!!!): grafik

Additional context

bcutter commented 1 year ago

I ran into several issues (at least the log flooding ones) of these:

...and therefore had to restore a Home Assistant backup only to "fix" this custom Shelly integration.

Clearly my initial fault (never change or play with a running (productive) system) - but I would have never expected that adding a second ShellyForHASS-integration will render the whole setup useless. And THAT'S the real issue here. Therefore I'll leave it open and hope for the best.

PMPoulsen commented 1 year ago

Hi,

Accidentially stumbled over this bug report, so thanks for making it.

I have the excact same issue in my production system. Actually I believed it to be normal (expected) behaviour as all my 27 devices were available and I could configure them as I expected. So I must (due to lack of knowledge) have installed it twice as well when I was adding the integration (or updating to version 1.0.0).

Actually this issue seems to be the root cause of what I believed to be a memory leak introduced in 2022.7, which I have spent days on trying to trace for the past month now. However now I realize that this is actually a log overflow which causes my system to restart every 2-3 hour, not a huge memory leak. I have just verified this at my backup system, just install twice causes excatly this behaviour and starts to drain the system for memory as the log's fill up.

I believe that there are no other way than to remove the integration and start over. But it is probably worth the work to avoid the system restarting every 2-3 hours

So for the coming users it would be nice to have this fixed to avoid this problem.

bcutter commented 1 year ago

My "fix" was to restore a HA Core backup to a time where only one Shelly custom integration existed. Lost a few hours of data, had some downtime etc. but simply removing one integration did not fix it: the log flooding kept going on; actually I don't 100 % remember if it deleted the devices and entities being bound to it but I think it did which is why I was going the restore backup path.

Next escalation would have been to really start from scratch. Usually meaning that all the history of all entities is gone, it takes a considerable amount of time etc. In that case I would have kicked the custom Shelly integration and went for the default shipped one. I don't know if there are still differences in features, but for sure the official one is maintained much better (in terms of "faster") and therefore I would consider it as more stable. Currently ShellyForHass is actually still blocking me from updating to HA Core 2022.7 because of some other issues which might be introduced with 2022.7. That would not happen with the official integration as it is being tested before - and just in case being fixed within few days.

Back to this issue: I think the integration should take care of this. I don't know if there are actual use-cases to have more than one Shelly integration on the same system. If that's not the case and it could technically be avoided, that should be the way to go.

No one stops users of doing this and it's just a matter of time it happens to the next one. 😑

PMPoulsen commented 1 year ago

I litterally just finished my changes (total 4 hours worth of editing). I did the following:

  1. remove the two instances of the integration = lost all entities (but I kept the HACS integration)
  2. restarted HA
  3. installed one instance, selecting "configure a different one" instead of the obvious choice (that reults in error 500)
  4. Changed naming of my 27 devices back to the previous installation names, so I didn't have to update Lovelace nor automations, as they all fit to the naming.
  5. restart again

result everything is up running on 2022.7.7, now the memory usage is gone,and the processor load is down to 3-5% instead of peaking at 30-40%, and no strange log issues anymore

I agree with your statement that this should never have happened in the first place, Iam just happy that I managed to ged rid of constant reboots due to log overflow.

so thanks for pointing me in the direction, I have litterally tried to disable almost everything to find the problem, but my mind was set to find a memory leak, not a runaway logfile (i didn't even look into this)

hakana commented 1 year ago

It should work to have multiple integrations but you must use a different name/prefix for them, otherwise, the entity id will get the same id. I will have a look at this. Maybe a warning if given the same name or something like that.

bcutter commented 1 year ago

Thanks for taking a look at this.

The interesting thing is: I removed the predefined name (shelly) from the input box and set nothing. But "shelly" was used anyway, probably because it's a default.

And my existing one was also named shelly, so I think you are very right. Possibly that's a point to work around this: randomize or alter the default name, implement checks for existing names etc., just as an idea.