This might all boil down to me not appreciating why the 35-char id’s for entities are used in HA, but …
My use case:
I’ll often start to create an automation using the UI and then switch to YAML to refine it.
If I need to duplicate an automation for other devices / scenarios I will edit the YAML version.
My problem:
I often find that the automations created by the UI will insert the 35-char id entity rather than the friendly name. This makes reading/managing/maintaining the automation in YML much more difficult than it needs to be.
eg. In the example below, the UI used entity_id: b789317b200889731872d3fffb8ecee5 instead of entity_id: sensor.humidity_rate_of_change_per_hour_loft_bathroom
There’s probably a good reason the devs used the 35-char id’s instead of the friendly ones - they’re more stable I imagine - but from my point of view its a WTH.
My proposed change:
When the UI generates YML, insert the friendly entity_id instead of the 35-char id. If this can apply to device_id’s too that would be superb.
Example trigger generated from the UI:
alias: Turn on towel radiator when loft bathroom is humid
description: ""
triggers:
- type: value
device_id: 2f6790abff2b69ec4c141d0e5484b419
entity_id: b789317b200889731872d3fffb8ecee5
domain: sensor
trigger: device
above: 15
device triggers (and also conditions and actions) have been using the entity_id in the past. This has been changed to the entry_id (this 35 charater code you see now) a while ago.
The reason this has been changed is that this now allows you to change the entity_id of the sensor which is used in this device trigger, and the trigger will still work, as the entry_id will not change when you change the entity_id.
Before this change, device triggers/conditions/actions would no longer work if the entity_id was changed.
And basically the developers so far thought they have to choose between human-readable (human-friendly) and machine-friendly. But with some logic that wouldn’t be the case.
if entry_id is there (the 35 char long hex thingy), then it has precedence.
the human readable entity_id is more-or-less documentation only
if the entity_id is missing, it will be auto-created
if the entity_id is not matching the entity_id, it will be re-created (overwritten). This is in lieu of my point 1 above. If you don’t like rewriting, then understroke it with some red wiggly line in the YAML editor or something like this. And ignore it. Because the entry_id “is da boss”
if however the entry_id is missing, it will be created from the human-readable entity_id
So, as a human: if I now edit the yaml of something and want to change the entity_id, I simply remove the hex thingy and write a new entity id, using the completion in the editor. And then I save. And by magic, the correct machine-readable entry_id will be created, taking precendence from now on.
This trigger from the start post states that for a specific device, a specific sensor should be above 15 to trigger. A device could have several numeric sensors in it, without a reference to the actual entity (represented here by the entry_id) it will not know which one to use.
I’m not sure how that would work with hidden entry_id like @tom_l proposes.
I guess you could just list them both like @holgerschurig proposes, and upon saving the automation check the entry_id and find the matching entity_id in case it was updated since last time the automation was saved.
The thing with device triggers/actions/conditions is that they are not intended to be YAML friendly, they are built to be functional in the GUI.
Use the entry_id in the backend. Interpret this to the the entity_id in the the frontend. Similar to the way way state values are translated from their actual backend value to their “nice” frontend display.
I do use the automation editor and also switch to yaml often. I do not experience the above problem because I avoid device actions for all kinds of reasons, this being one of them.
My entity_ids are readable, and easy to use with state triggers and conditions. Visual Studio code and other editors allow autocomplete to assist in entering the entity ids while displaying friendly names. So basically the problem is avoidable for what I can tell.
Using friendly names in yaml is a recipe for problems, because my friendly names are not always unique, and might change. I would not like the automations to break or be ambigous because of it.
I do agree. I have normalized entity_ids naming in order to be able to factorize the code and avoid code lines inflation. I’m not in favor of this WTH.
or whatever it is currently named. So it will be HA that translates the incomprehensible b789317b200889731872d3fffb8ecee5 to something I can understand.
And should I want to change this, then I can change this by hand to
- entity_id: sensor.quoarks
and when I save it, then (internally) HA deduces the current hex value and therefore might store
assuming that I didn’t rename “quoarks” to something more comprehensible. The point is that these user-friendly names aren’t really stored, but just generated at “yaml presentation time”.