We already have a search by entity name, it would be great if we had a refactor functionality that changes the entity name in all locations (lovelace, automations, scrtips, etc.) when changing the entity name.
This is gold!!!
3 Likes
Voten! This is key functionality to get users on board when moving forward with migrating integrations from yaml to UI.
3 Likes
Oh please I’d love this
Would be awsome, though technically very challenging i think
This. I was honestly expecting something like it in the new “Fix Me” system: “You seem to have an automation with an entity that doesn’t exist…”
10 Likes
Oh heck yes! I’ve been wishing for this ever since I started HA.
This would be a nice touch. Perhaps we could also add (immutable, unique) uuids for entities the way we do for devices, which could be used for configuration stored in the database, and transformed into the “friendly” name for viewing. It seems like these two ideas would complement each other.
Conceptually, I feel like entities should have a back-end immutable identifier for automations, dashboards, etc, and a front-end user-facing mutable identifier. The UI should be smart enough to use the immutable one while exposing the mutable one when building things.
I would also really like the ability to batch-refactor these entity names. If I add 30 zigbee sensors with 3 entities each, and don’t like how HA decides to name them, that’s 90 entities I have to change individually.
Perhaps beyond the scope of this particular issue, I think there are overall probably better concepts for how to implement entities than type.arbitrary_name as well, especially if you uncouple the actual identifier and what’s shown to the user. “Front Stoop Light Brightness” and “Kitchen Temperature” are much more clear than temperature.kitchen, especially when temperature.kitchen might start as temperature.zigbee_Temp_sensor_4.
9 Likes
You’re literally just describing how HA works. If you can click on an entity and change its “entity ID” in the UI then that means the entity has been added to the entity registry and has an immutable unique id in the backend. Hence why its possible to change its entity ID.
Granted not all integrations support this yet. If you have an integration which is configured in YAML which hasn’t been updated to use the relatively recent registry additions then the entity ID is the only unique ID. That’s why if you try and change the name or unique ID for those entities in the UI it says that it can’t be edited there.
EDIT: Ok wait, I realized you’re asking for the unique ID to actually be used in automations and dashboards instead of the entity ID (i.e. in user config). Not just exist to give the backend a way to way to reference entities uniquely without relying on entity ID. I don’t agree with that.
The problem with doing that is quite simple really, what happens if you need to replace a light bulb? Or if you don’t like a particular smart device and replace it with one of a different brand? You’re obviously going to get a new unique backend immutable identifier in these cases. If you didn’t then it wouldn’t be unique. But I wouldn’t want that to break all my automations and scripts. It’s still a light or switch or lock or whatever it is, who cares if its not actually the same device anymore? As long as it supports all the mechanisms of interaction the previous model did then everything should continue to work.
This is the same reason why all over the forum you’ll see people cautioning users about the device type actions and triggers for reference. I don’t want to tie my logic to the actual physical device unless I have to, I want to be able to replace it seamlessly someday.
6 Likes
There’s another WTH asking about a “replace device” feature.
Ultimately I think the root problem is that the system is rigid, breaks easily, is prone to needing to refresh all your names as things change, and is difficult to restore to a working state en masse when it does break.
2 Likes
I mean, unless you use entity IDs for everything… Those are for me, the human, to use. If I replace I device I can make sure all the entity IDs are the same so everything keeps working. And the backend of HA can also have its guids for uniquely identifying the objects that exist right now without being totally fouled up if I change an entity ID.
I’m a big fan of this WTH for reference, would love a refactor option. But implementing it by swapping out my entity IDs with GUIDs in the actual config? No thanks, that sounds like way more trouble then its worth.
How would one ever write a template in this model? Instead of {{ states('sensor.my_sensor') }} you have {{ states('876103957029rsdgyfiherhewryeri') }}? 
1 Like
Those are the UX details people smarter than us get to come up with.
So a GUI based template editor is a requirement for this suggestion to work? Templates aren’t in the GUI right now, you must drop to text to work with them.
Nothing is a requirement for anything. The entire point of this month is to post our frustrations that we would like to be solved, not to litigate every minor implementation detail that might be required. Entity names are a huge frustration that break easily.
6 Likes
For bonus points, make this work for Node-RED as well!
i.e. I change an entity in HA and it either gets flagged or simply updated in Node-RED.
I do all of my automations in NR and this would certainly save some self-induced bugs.
GUIDs for all!
1 Like
Totally agree that this should be a part of the core functionality. The lack of this feature was a reason I’ve created a custom integration which does similar thing.
Agreed here
I think this is important especially I just found that if you rename an entity ID the new group helpers don’t pick that up. This is annoying as when using groups in yaml you could at least search/replace the yaml but if you use groups in the UI you can’t do that anymore. (The workaround for groups is goigng to Developer Tools → State and filtering on attributes)