#Models and areas don't inherit indeed.

1 messages · Page 1 of 1 (latest)

restive elm
#

For Shelly devices you can change a switch to light by appliance type (gen1) and consumption type (gen2+)

latent nova
#

Was too lazy to go into shelly interfaces tbh

#

But it shouldn’t drop existing entities

#

Or we need to declare breaking changes

restive elm
#

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.

latent nova
#

without looking at it: I guess it might include the device somehow

restive elm
#

Yes, that's my guess too

primal hollow
#

What I read in the switch_as_x code is that we do track changes, but only on runtime

coarse wadi
#

In that video the power of my Tesla charger moved to a sub device but the threshold helper linked to it did not

primal hollow
#

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?

coarse wadi
#

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)

primal hollow
#

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?

coarse wadi
#

REstarting HA ?

primal hollow
#

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

coarse wadi
#

restarting ⏳

#

So now it's on the correct device

#

But I lost configuration

#

eg. I lost the icon for exmaple

primal hollow
#

if you reload the browser?

coarse wadi
#

Extract fro before the restar

#

No

#

Even if I reload the browser / restart the browser

primal hollow
#

why on earth would you lose config

coarse wadi
#

Because it's attached to the other device somewhow?

primal hollow
#

custom icons and such is on entity level

coarse wadi
#

BEcuase it's uniquelely identified by a tuple that contains the device?

primal hollow
#

cc @untold helm Do you have an idea on why entity configuration is lost when restarting/changing device_id?

coarse wadi
#

Restarting one more time ... for some reasons

#

NOpe 🤣

#

It was worth a try

untold helm
#

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?

primal hollow
#

Okay so Shelly is now splitting up into more devices

#

Which means that helpers that are attached to those devices, should also move entity

untold helm
#

why would a helper move entities?

primal hollow
#

I have a power entity that measures if my tesla is currently being charged

untold helm
#

are the entities not same before and after this change?

primal hollow
#

and that entity is now being moved to a different device because in theory its a different device

primal hollow
#

as in, when a device has area significance, it's a reason to have separate devices

#

oh

#

yes

#

should also move device*

untold helm
#

ah

#

ok

primal hollow
#

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

untold helm
#

joost, can we take a step back please

primal hollow
#

yes

untold helm
#

customizations of what is lost? is it things like user changed name that has changed?

primal hollow
#

The icon in this case

untold helm
#

OK, so why all the talk about helpers? what's the relevance of that?

primal hollow
#

well, that was the direct thing that changed, which caused the icon to reset for some reason

untold helm
#

that makes no sense

primal hollow
#

I also think this doesn't make sense, but yet it happened

untold helm
#

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?

primal hollow
#

Like, it's not that the icon suddenly dissapeared, something unrelated changed, causing it to dissapear

primal hollow
# coarse wadi

The tesla icon got removed after the entity moved devices

untold helm
#

OK, and what does that have to do with helpers?

primal hollow
#

The helpers are the cause of the moving devices

#

and that is something separate I am looking into

untold helm
#

can we again take a step back then and start from the beginning

primal hollow
#

okay

untold helm
#

sorry, but I don't follow at all what problems are happening, could you try to explain what's happening?

primal hollow
#

Okay so, an entity moved from one device to the other, and then lost the icon customization

untold helm
#

OK, and what is that entity, is it a shelly entity or an entity provided by a helper?

#

Also, which helper?

primal hollow
#

It's an entity provided by the threshold entity, which is monitoring a shelly entity

untold helm
#

OK, so it's the threshold helper which looses the icon customization?

primal hollow
#

yes

untold helm
#

OK, and what does that have to do with switch_as_x which is mentioned above?

primal hollow
#

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

untold helm
#

ah, so that issue is about the helpers not appearing in the expected sub device after the shelly migration which changes sub devices?

primal hollow
#

yes, since the shelly integration was loaded after the threshold one, so the helper only changed devices after a restart

untold helm
#

ok, lazy helper authors. but that's understood and fixable?

primal hollow
#

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

untold helm
#

how do you know it did not change? has that been confirmed?

primal hollow
#

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

untold helm
#

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

primal hollow
#

Oh right

#

@coarse wadi Do you still have that old device around?

primal hollow
untold helm
#

where's the shelly migration to the new device structure? does shelly delete itself from any device?

untold helm
primal hollow
#

I would assume so, as the threshold entity was still attached

untold helm
#

it's attached to A device, but is it the same?

coarse wadi
#

(Catching up everything. Ping me if you want to test something meanwhile)

untold helm
#

@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?

coarse wadi
#

TL;DR :

  • I had a threshold helper attached to main_device
  • main device got split into main_device, subdevice_1 and subdevice_2
  • at first the helper stayed on main_device
  • after a restart it moved to subdevice_1 where it should be but I lost the icon I manually set.
restive elm
coarse wadi
#

@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.

untold helm
coarse wadi
#

Do entitiy and device registry contains critical personal info?

#

Can I share them here or do I share them provately to you @untold helm ?

untold helm
#

as you wish

#

maybe better to share privately since this is not a DM

coarse wadi
#

ONe sec

primal hollow
#

it could contain user identifiers or coordinates

coarse wadi
#

All shared to Erik!

untold helm
#

thanks

#

the entity has indeed been deleted and then recreated

#

it also lost the area btw

untold helm
#

Or maybe there's no migration as such?

restive elm
#

No migration, old device remains unchanged

primal hollow
#

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

untold helm
#

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)

restive elm
#

exactly, entities get new device_info

untold helm
primal hollow
#

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

untold helm
#

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

primal hollow
#

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

untold helm
#

why?

primal hollow
#

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

untold helm
#

Like I said before, i don't understand at all why these helpers are providing device info

primal hollow
#

because now the helpers are attached to the same device, which IMO is a nice enahncement

untold helm
#

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

#

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:

  1. Shelly config entry starts, and the entities are moved to new sub devices
  2. The threshold config entry calls async_remove_stale_devices_links_keep_entity_device which removes itself from the main device, which means the threshold entity is removed from the entity registry
  3. The threshold entity is set up, which results in a new entity registry item being created
coarse wadi
#

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

untold helm
#

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?

primal hollow
#

I think that would make sense yes

untold helm
#

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

untold helm
primal hollow
#

I think we found that squeezebox is doing something interesting here

untold helm
#

what's that?

primal hollow
#

Nvm a test was just failing on CI

restive elm
#

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.

primal hollow
#

Oh interesting

untold helm