I was trying to help you with the issue you raised.
Ok, thanks for the good intention, but it didn’t help because you misunderstood me; It is a fact that I said three times by now that Z2M is just an example. I don’t even use Z2M. There is no issue with the Z2M integration.
I’m talking about when entity_ids change which could be due to migrating from one platform to another so when the same device is readded to HA via the new integration/platform the entity_ID is different, for example when moving from one zigbee coordinator to another, or when pairing a sensor that dropped out of the network, sometimes the sensor will get the same name as before with an _2 appended after it. This breaks automations that depend on entity_id. Truthfully HA is awful at tracking these things, it’s a massive pain. I am NOT, I repeat, NOT ATTACKING HA or its developers, it is a massive weakness of the platform though, and this month you guys asked for us to say what’s causing pain so I’m doing that.
All the zigbee devices are the same before the migration, but their entity_id can change just because HA isn’t the best at tracking a device. I chose Zigbee as an example because the sensors have IEEE addresses that are hardcoded. So it’s kinda ridiculous that HA amends entity names when pairing the device to a different integration, when the hardware identifier should easily help HA understand that the device is not new, it was previously added but because it’s now handled via another integration the entity_id is different. HA is terrible at tracking these changes and automations break as a result. I have hundreds of automations and I can’t spend two days going through all of them every couple of months to see what broke, when HA already knows an entity is unavailable or unknown and should tell me. HA is not proactive about showing issues in automations, the user either has to find out by chance or they have to open each automation and see if triggers/actions are available or faulty.
HA should be like a modern car, showing warnings clearly when things break. But automations can break silently with no warning. It’s kinda ridiculous when a Home Automation platform’s core utility - Automating - breaks so easily with no warning due to just an entity_id changing, with no easy way to fix the issue.
At least make some sort of bulk editor to replace old ID with new ID and HA should then automatically amend any automations that relied on the old values with the new values.
To be clear, I am not stupid and you can trust me when I say this is a problem with HA not any other system, and again I used Z2M as just one of many potential examples
This is an issue with HA, absolutely, because HA decides how entity_id names are created, either internally or the integration does. I can already edit an entity_id by accessing the entity’s info page then clicking the gear. But imagine doing that for hundreds of entities.
I’m saying it would be great if there was some sort of spreadsheet-style table to allow bulk editing of entity_id for any ones that are unavailable/unknown to replace old value with new value, and automatically have automations work again.
Do you want me to do a whiteboard session to explain better? I understand that how I’m expressing the issue may not be clear and I’m happy to have a friendly web meeting with you if it helps. I don’t know how involved you are with development of the product but I am open to talking to anyone in your development team to take questions.
The issue is Home Assistant not having a way to amend entity_ids in bulk when a device name is changed by swapping integrations or amending a device in the integration’s app directly. Automations break as a result and rather than showing the user that the automation has an invalid/unknown entity_id on some sort of status page, it just silently fails.
If an automation trigger or action has a device/entity that stops existing in HA then HA should warn the user (it does sometimes, as “repair” warnings, but not every time. And there should be a way to edit/replace entity_id within home assistant itself, because it is HA that utilizes the concept of entity_id.
I actually have a real-life example:
I use ZHA for my zigbee devices. I have a laundry door sensor: binary_sensor.laundry_door
The sensor battery died a couple of weeks ago, I didn’t notice. I opened the door today and the light didn’t come on, so I manually checked, and saw that the sensor was powerless. When I replaced the battery the sensor didn’t reappear online, it dropped out of the network. But the trigger in the automation to turn on the light when I opened the laundry door is still expecting binary_sensor.laundry_door to react. When I went on the ZHA integration and put the coordinator into discovery mode and paired my sensor, HA assigned the entity_id as binary_sensor.laundry_door_2, for no reason! The sensor IEEE address never changed, so HA has no reason to do that, literally. It’s bad logic/programming. Now I had two choices: do I amend just this one automation to use the trigger binary_sensor.laundry_door_2, or do I edit the entity to amend the entity_id back to binary_sensor.laundry_door? The first one fixes just the single automation. The 2nd one requires an extra step of deleting the “unknown” device binary_sensor.laundry_door before I can rename binary_sensor.laundry_door_2 to binary_sensor.laundry_door otherwise HA complains that there is already a binary_sensor.laundry_door entity_id even though it’s invalid because HA decided to take the same device and give it a fresh new binary_sensor.laundry_door_2 entity_id when I paired it back to get it seen by the coordinator after the change of battery.
Now I want you to imagine that you have 50 sensors in the same situation… and I was using just one automation as an example. Imagine having to manually amend 200+ automations.
I am not being a b^^^^, this is a real issue, a real pain in the backside and it’s definite a WTH that I hope can be addressed in the future to make the platform better. I can’t complain about HA, it’s been of great utility to me, but nothing is perfect and this is definitely the platform’s pain point, the way things break with no warning message and no way to easily fix things. Hopefully it can become easier and more intuitive in the future.
Thanks and nothing more to add here.