Yes agreed I would NOT version entity names.
Entity names are a specific construct ties to history stats and the database. You can maintain consistency of data for things like energy if you retain entity ID naming if you replace a device.
Also we recommend addressing automation by that same entity ID for the same reason. (You can swap a device and not have to rebuild everything.)
If you’re changing them all the time for version controls you break that
Ah! Ok. (light bulb over my head turning on)
I have been questioning myself about embedding version numbers. I do use git for versioning generally. My thought here was that I am planning to eventually replace the estimated ambient light level using sun.sun with some hardware sensors I’d like to construct myself. Which likely will cause significant changes. So I was thinking in terms of how I’d version a file format so updates to an app could account for enhancements to retain backwards compatability.
BUT to your point I should probably really think more in terms of object-orientation, or proper modularity - make the sensor I/O clean and simple so that my underlying implementation doesn’t matter to it’s consumers.
Correct. Commendable that you want version controls tho.
I actually use GUIDs for all my unique id’s. (they’re unique right?) my entity is descriptive of the actual devices and functions. And version controls happen elsewhere in git or archives.
GUIDs - yep; that’s the way I’ll go.
Thanks for your help!
Unique ID is not necessarily used to make the entity ID.
What they said. The unique_Id is used by the UI, and really not referenced anywhere else.
Do your self a favor and put uuid’s or something else very random in the unique ID so that you don’t try to use it later.
It’s not meant for human use, rather UI reference so you can change the human readable names and it will still know what it is…
UUID’s for the win…
example: f52f7134-1755-4911-8e63-f06ab1070855
Auto generated if you use Code Server / VS Code or other programs near you.
Yes, that’s my goal, and I’m confortable generating UUIDs. Now - can I use a ‘unique_Id’ string everywhere I might otherwise use an ‘entity ID’ string? And if so, should I? How stable are the “Entity ID” values?
And related - if a device or entity got an unhelpful name - like, say, a name that has some location info embedded with it due an initial ‘user friendly name’ assignment; can I change the Entity ID somewhere so that I can move the device and not be confused by the old Entity ID?
it is if you omit a name.
No you cannot. Unique ID is an internal structure.
Entity_id is a first class citizen - consider it a primary key. It should be your first choice for addressing a ‘thing’
Ok, very good. Thanks Nathan.
Just when I thought I understood…I am confronted with this - entity_id as a GUID in an automation YAML that I created using the Visual Editor.
What is this about??
See YAML code and screenshots below. The below YAML was generated by what you see in the screenshot of the visual editor. I have not touched the generated YAML as shown below:
alias: Set Alex Night Lights
description: ""
triggers: []
actions:
- delay:
hours: 0
minutes: 0
seconds: 3
- type: turn_off
device_id: 153b1cb739c40dc517406a668d4fe61a
entity_id: 9aa86ae2b4e5384f9a77b309e6d8454d
domain: light
That happens because you chose a device action, device condition and/or device trigger. They use those types of IDs and yes they suck because the code is pretty much unreadable. Simply don’t use device actions/conditions/triggers.
Hmmm…definitely a bit of a struggle trying to deduce the internal architecture of HA so that I can get myself organized on how to set it up.
I feel like there needs to be a Powerpoint deck walking me through the architecture of the HA object model in diagrams - and I can’t believe I’m saying I need a Powerpoint deck! lol
Ok - I am inferring that there are objects called ‘Devices’ and there are objects called ‘Entities.’ I further infer that a Device is-composed-of 1:many Entities. I think it may also be true that an Entity can stand on it’s own. I.e., an Entity is-contained within 0:1 Devices.
So then, based on what ya-all have been saying in this thread, the best practice is to always go at Entities in automations and templates; avoiding making references to Devices.
Am I on the right track with this thinking?
There’s a long history to this. The short story is: It used to be entity_id, however people wanted to be able to change the entity without updating the automation. So now that field accepts the config entry guid and entity_id. This allows you to update the entity_id without impacting the automation.
You aren’t meant to use device triggers, actions, and conditions outside the UI. So when you go over to yaml, it doesn’t really make sense.
If you plan on using yaml, you should steer clear of device triggers, actions, and conditions.
And just so you understand the complexities… In the beginning, we only had entities. No devices. As HA evolved, devices have become more and more prominent. This unfortunately makes many things more confusing for new people.
Hopefully I’m getting there with my understanding. The above statement is unclear to me. I think what I get from it (as an old SQL database guy) is: In the underlying data structures there is a record for the Entity, and the primary key of that record (hidden from the UI) is a GUID assigned when the entity is added into HA.
Then as part of that record there is a field for the ‘entity_id’ string that we see in the UI. Thus I could switch out my broken Entity for the new one the manufacturer so graciously supplied me (/off tongue in cheek) and as long as I do that correctly then, under the covers, HA just updates the appropriate fields in the original record, retaining the original GUID, and all the other parts inside of HA are none-the-wiser for having made the switch-over. (Sure - the true underlying data structure may be more complex than this, but I’m thinking this is the gist of it.)
fwiw, I would say that what I just stated, if I’m correct in my assumption, is a correct design decision; but, yes, it does add complexity that users need to have some level of awareness of. Sometimes writing the user manual is harder than writing the code.
If you use device actions/triggers/conditions which uses GUIDs in automations, those automations will not break if you edit any entity ids. They will however break if a device breaks and need to be replaced, because they are hardcoded to the GUID of the old device (which will never be reused, unless perhaps you manually edit the database outside what HASS normally would allow).
If you use other actions/triggers/conditions which uses entity ids in automations, those automations will break whenever you edit those entity ids. But unlike above, if a device breaks you can simply replace that device, as long as all of the entities on your replacement device is assigned the same entity ids.
Entity registry has 3 keys:
Out of those 3 you always have control only over entity_id. Consequently it is the entity_id, that is most commonly recommended to be used in all references (automations, templates, frontend, etc.), as it allows for the possibility of replacement. The disadvantage is that changing the entity_id requires updating all the references.
The primary id is generated every time a new entity is added and is therefore completely outside of your control. Nowadays it is used automatically by the frontend with device triggers/conditions/actions. Since you have no control over it, many people discourage the use of those patterns.
unique_id is decided by specific integrations and therefore also usually outside of your control. It is used only for internal references, hence you should generally not be concerned about it. The exception here are some integrations which allow manual configuration via YAML, where you need to specify unique_id manually. Good pattern here is to just generate something unique, like UUID, and not worry about it.
Ok, I see. At the risk of cursing myself I’m going to say once again that I think I understand it now, lol. The old systems modeler in me wants to study a UML or entity-relationship diagram tho.
Good info. So I’m thinking that I:
Pretty much exactly what I do, though can’t guarantee it is best practice 
For some things like lights I really hate the default entity id/name scheme and my OCD forces me to change them manually. I typically name the device according to location and what it is, so something like Lounge Ceiling Bulb (as opposed to say a Fixture which would imply something with a non-replaceable light source).
But then the light entity gets the generated name Lounge Ceiling Bulb Light with the even more redundant id light.lounge_ceiling_bulb_light, so I manually change those to only Lounge Ceiling and light.lounge_ceiling respectively. Entities that I deem secondary i.e. things that will never show up on a dashboard and seldom be used in automations I leave the default ids/names.
