#Models and areas don't inherit indeed.
1 messages · Page 1 of 1 (latest)
For Shelly devices you can change a switch to light by appliance type (gen1) and consumption type (gen2+)
Was too lazy to go into shelly interfaces tbh
But it shouldn’t drop existing entities
Or we need to declare breaking changes
This is not a breaking change for Shelly integration because the original entity (switch) is still present and it has the same entity_id
I don't know why "Switch to X" is losing the original entity. I will investigate this.
without looking at it: I guess it might include the device somehow
Yes, that's my guess too
What I read in the switch_as_x code is that we do track changes, but only on runtime
I think it’s all helpers based on entities that moved
In that video the power of my Tesla charger moved to a sub device but the threshold helper linked to it did not
This now got me wondering, with switch_as_x we definetly bind to the same device
but with a threshold helper, you select the device you want to connect with during setup right?
I do not remember but for sure I cannnot change it now
For Template helpers I can change it after the fact for exmaple
You do not
We infer it from the entity
(Which makes a lot of sense)
oh no
you dont select a device in the threshold config flow
Looking at the code I would assume it worked
@coarse wadi can you try restarting?
REstarting HA ?
ye
The threashold one might be a load order thing, because following the logic, it would create itself for the device the entity is at at boot
but if that happened before shelly was booted (and thus the entity moved) it would stay in the old one
restarting ⏳
So now it's on the correct device
But I lost configuration
eg. I lost the icon for exmaple
if you reload the browser?
Extract fro before the restar
No
Even if I reload the browser / restart the browser
why on earth would you lose config
Because it's attached to the other device somewhow?
custom icons and such is on entity level
BEcuase it's uniquelely identified by a tuple that contains the device?
cc @untold helm Do you have an idea on why entity configuration is lost when restarting/changing device_id?
I don't understand the question, what does "restarting/changing device_id" mean?
short answer: it's not
are you sure it's the same entity?
Okay so Shelly is now splitting up into more devices
Which means that helpers that are attached to those devices, should also move entity
what does this mean?
why would a helper move entities?
I have a power entity that measures if my tesla is currently being charged
are the entities not same before and after this change?
and that entity is now being moved to a different device because in theory its a different device
So this was a typo?
as in, when a device has area significance, it's a reason to have separate devices
oh
yes
should also move device*
So what now happened is that shelly loaded after the threshold helper, so it only got applied after another restart
the unique id of the threshold entity is the entry_id
joost, can we take a step back please
yes
customizations of what is lost? is it things like user changed name that has changed?
The icon in this case
OK, so why all the talk about helpers? what's the relevance of that?
well, that was the direct thing that changed, which caused the icon to reset for some reason
that makes no sense
I also think this doesn't make sense, but yet it happened
no
that was the direct thing that changed, which caused the icon to reset for some reason
This explanation makes no sense
what changed? and what icon was reset?
Like, it's not that the icon suddenly dissapeared, something unrelated changed, causing it to dissapear
The tesla icon got removed after the entity moved devices
OK, and what does that have to do with helpers?
The helpers are the cause of the moving devices
and that is something separate I am looking into
can we again take a step back then and start from the beginning
okay
sorry, but I don't follow at all what problems are happening, could you try to explain what's happening?
Okay so, an entity moved from one device to the other, and then lost the icon customization
OK, and what is that entity, is it a shelly entity or an entity provided by a helper?
Also, which helper?
It's an entity provided by the threshold entity, which is monitoring a shelly entity
OK, so it's the threshold helper which looses the icon customization?
yes
OK, and what does that have to do with switch_as_x which is mentioned above?
There's a different issue where some helpers are listening to devicechanges on runtime, while some only set the entity to the right device on boot
ah, so that issue is about the helpers not appearing in the expected sub device after the shelly migration which changes sub devices?
yes, since the shelly integration was loaded after the threshold one, so the helper only changed devices after a restart
ok, lazy helper authors. but that's understood and fixable?
I think we can fix that yes
And the restart that Jlo did confirmed that this was the case
But then I could not explain why the icon suddenly dissapeared
as the unique id of the entity did not change
how do you know it did not change? has that been confirmed?
the unique id of that entity is the entry_id
While I did not explicitly rule out that an entity moving a device removes an entry and creates a new one, looking at the code makes it highly unlikely that that happened
After the restart, it first deleted the entry from the device using dev_reg.async_update_device(device.id, remove_config_entry_id=entry_id), after which it now created the same entity as before, but then with a different DeviceInfo
ok, but deleting a config entry from a device may delete the device if there are no more config entries, and deleting a device deletes all its entities
so I think the device helpers (I mean what's in helpers/device.py) may be a bit misguided
I don't understand why the threshold sensor adds its config entry to the host device
From looking at this video, it does not look like it was the last config entry that was attached to that device
where's the shelly migration to the new device structure? does shelly delete itself from any device?
Is that the same device(s) as before the migration though?
I would assume so, as the threshold entity was still attached
@restive elm
what does "still attached" mean?
it's attached to A device, but is it the same?
(Catching up everything. Ping me if you want to test something meanwhile)
@coarse wadi could you share entity registry + device registry json files before and after the upgrade?
or have you already checked those and confirmed no device or entity is being deleted?
TL;DR :
- I had a threshold helper attached to
main_device main devicegot split intomain_device,subdevice_1andsubdevice_2- at first the helper stayed on
main_device - after a restart it moved to
subdevice_1where it should be but I lost the icon I manually set.
the old device remains as the "main" device and sub-devices are created for the channels
@untold helm I can definitely share the registries I have now
The old one.... I can ... I just need to restore
It will take a bit of time, I am in a meeting and will have to jump out to take care of my daugther
So it will be later tonight
Wait .. I do not need to restore, I can simply unpack the backup, stupid me
One sec.
Thanks, that's a very clear explanation 👍
Do entitiy and device registry contains critical personal info?
Can I share them here or do I share them provately to you @untold helm ?
ONe sec
it could contain user identifiers or coordinates
All shared to Erik!
thanks
the entity has indeed been deleted and then recreated
it also lost the area btw
Where is the migration implemented?
Or maybe there's no migration as such?
No migration, old device remains unchanged
What I do find interesting, the main device still exists. In theory it would not have any loaded integration attached, but it would have entities. So I am not sure why it deleted the entity then
ok, so it's only entities' device_info that's changed so the entities are now part of a different device (which happens to be a sub device)
exactly, entities get new device_info
Probably because I f-ed up something when adding support for subentries
I am now looking for it by the way, but how do entities get removed when a device gets removed? I suppose with an event?
nvm I found it
right. i think it's very likely the async_remove_stale_devices_links_keep_entity_device is to blame here. but not sure if it's because of a bug in that function or how it's used or if there's a bug in the device registry
I don't think the async_remove_stale_devices_links_keep_entity_device is sane
I think that sounds about right
but I also think that we should be able to remove a config entry from a device without entities being removed
why?
Hmm, now I think about it, this is probably the only use case
as other integrations don't work across each others devices, and when they then get removed, we do want to remove entities generally
Like I said before, i don't understand at all why these helpers are providing device info
because now the helpers are attached to the same device, which IMO is a nice enahncement
No
it's not a pattern we want to encourage, and it will stop working when devices can only have a single config entry
the way switch_as_x does it is much more robust imo
i don't know why this second pattern was invented, instead of doing what switch as x does
Meh, never mind my rambling
I misremember how switch as x works
The way switch_as_x works was initially like I remembered, but it was changed by PR https://github.com/home-assistant/core/pull/89992 so it's now basically like the other helpers do it
Anyhow, I the problem is that async_remove_stale_devices_links_keep_entity_device results in the config entry link to the helper config entry being removed before the entity has moved itself to the correct device, the order is this:
- Shelly config entry starts, and the entities are moved to new sub devices
- The threshold config entry calls
async_remove_stale_devices_links_keep_entity_devicewhich removes itself from the main device, which means the threshold entity is removed from the entity registry - The threshold entity is set up, which results in a new entity registry item being created
From a user standpoint, the fact helpers are attacehd to devices is amazing 😄
I want that on even more of them. LIke inputs too
I'm adding them to soo many devices, it's my way of making a smart device smarter
I think the proper fix here is to make async_remove_stale_devices_links_keep_entity_device first update the entity's device link to match the source entity's device, and after that remove the helper config entry from any other devices.
@primal hollow does this make sense?
I think that would make sense yes
OK
Like this maybe?
diff --git a/homeassistant/helpers/device.py b/homeassistant/helpers/device.py
index 16212422236..41fc04a8b39 100644
--- a/homeassistant/helpers/device.py
+++ b/homeassistant/helpers/device.py
@@ -90,6 +86,13 @@ def async_remove_stale_devices_links_keep_current_device(
"""
dev_reg = dr.async_get(hass)
+ ent_reg = er.async_get(hass)
+ # Make sure all entities are linked to the correct device
+ for entity in ent_reg.entities.get_entries_for_config_entry_id(entry_id):
+ if entity.device_id == current_device_id:
+ continue
+ ent_reg.async_update_entity(entity.entity_id, device_id=current_device_id)
+
# Removes all devices from the config entry that are not the same as the current device
for device in dev_reg.devices.get_devices_for_config_entry_id(entry_id):
if device.id == current_device_id:
The name of the device helper functions should also be updated IMO, unless they're used by custom integrations
I think we found that squeezebox is doing something interesting here
what's that?
Nvm a test was just failing on CI
I think I might have found it https://github.com/home-assistant/core/pull/146329
Sorry I was almost unavailable for the last two weeks. I tested the update from 2025.5.3 to 2025.6.0b5 today and it looks like the switch_as_x entities are not created on the first HA run. After the next HA restart they appear correctly and are assigned to the correct device. The result is exactly the same with and without #146329.
Oh interesting