Not strictly a question about creating an automation but a UI/UX thing centred on automations. Why do they have a name field in Rename (which seems to be the “main” one?) and another in Settings? They can be set to different values. The main screen where automations are edited seems to use the Rename one. Has anyone got a reason for this oddness? Maybe the same thing happens for other object types and I’ve just not seen it. Basically it looks to me like the Name text field in Settings should be removed.
#Why do automations have two names?
summer wigeon
Am astonished that there is no interest in this issue. It seems like a fundamental problem. Automations have two names? One for the entity and one for… something else? What kind of nonsense is this?
wraith nexus
Because they don't have 2 names?
||-# It HAS MANY||
There is a name that the user calls it and an entity_id that is used for identifying it in the code and an entry_id that is a number for backend unique-ness and sometimes an unique-id and a device_id and another entity_id that looks like a number.
It's not confusing at all.
If you want more names, you can have a couple of hundred aliases if you want as well.
If you put the automation into a group or add a label, you can call it by that as well.
summer wigeon
Thank you for answering, even if your answer is difficult to follow. Can you explain how I would rename an automation? Since using the “rename” screen does not impact the entity_id I guess I must rename it in two places? That’s the kind of confusion I am referring to.
Basically the split between objects identified by human readable text, entity IDs basically, and UUIDs seems to be at the root of many problems like this. Devices are identified by UUID so can be renamed at will, great. Entity IDs seem to be a holdover to the early days of HA where most of it was driven by Yaml. The result is a lot of friction.
cold geode
Because they don't have 2 names?
||-# It HAS MANY||
There is a name that the use...
No, they really have two name AND an entity id. And no, I have no idea why.
One is just the name you fill in when making the automation. This is shown when you edit the automation and you can change via the Rename action there (name A). But you can also go to settings. There is a name field that's blank by default (name B). If you fill in something in name B, that's separate from name A. When editing the automation you still see name A. But in the list of all automations you now see name B....
Might be just a bug which rarely somebody notices as you don't end up in settings that quickly.
summer wigeon
Just glad someone else has ran into this, thank you for responding. It seems like such a fundamental problem. I think the root of this is HA can’t decide if it’s driven by human maintained text files or it’s controlled by a machine managed object database. The fact entity IDs are exposed in the UI layer is revealing. Don’t get me wrong, it’s amazing software. But this duality has consequences. Or maybe it is just a bug. I really hope so.
cold geode
Maybe, although entity id's are certainly not a thing from the past. That's still the main spill for the database. And I'm glad it's still an option as a unique but readable key for an entity.
I think this is more a result of the customize engine. Where settings will "customize" the name where (placing a mask over the rela name) the other option really do a rename. But yeah, think it would be best if the name name in the settings would set the real name as well for an automation. But practical, just don't use the name in settings :p
summer wigeon
Interesting, thank you. I’m very glad that its roots as a system managed by humans editing files is still very much a thing. Unix vs the Windows registry etc.
I am curious why UUIDs were chosen as the index into devices. It seems, to my limited eyes, a strange choice inconsistent with the rest of the architecture. Are UUIDs used anywhere else? I’m assuming devices weren’t around in HAs very early days?
wraith nexus
I am curious why UUIDs were chosen as the index into devices. It seems, to my limited eyes, a strange choice inconsistent with the rest of the architecture.
Ya, I didn't even bring up device_ids really. They are horrible to work with and don't do templates. Few if any of the longtimers like or use them. Suggest avoid wherever possible...
summer wigeon
The only place I’ve found where device IDs are mandatory is in device triggers. I haven’t found a way to trigger off a button press with an entity state change; have to use device IDs for that. Not sure it’s relevant but this is for IKEA Zigbee buttons. Other than that, yeah, I do try to avoid them cos they are not “portable”. The only advantage to dealing with device IDs is in that renaming things case, but I try to avoid doing that.