New to HA and still on the learning curve. Currently learning how to create custom template sensors. My instinct is to version each sensor, which I have tried to do my appending an underscore and v# onto the end of my unique_id string. As in “test_sensor_v1”
I have observed that when I do this HA truncates off that final ‘_v1’ part.
Is this by design?
Example yaml:
- sensor:
- name: a-test-custom-sensor
unique_id: a-test-custome-sensor_v1
state: "This is a test"
This is what HA shows for resulting ‘Entity ID’ in the UI: sensor.a_test_custom_sensor.
Any thoughts on this?
(I am asking for two reasons - one, I just want to truly understand the workings of HA for most effective use. Two, I have what might be a related problem with referencing a custom sensor by it’s unique_id; but thought to start with this oddity first.)
The name is what is used to generate the entity id. The entity id is what is used in automations, scripts and scenes. The unique id is not shown. It is used internally to link customization data to the entity. So nothing is truncated, you just did not put v1 in the name (which can be a nice friendly name, HA will sluggify it for the entity id).
However, versioning entities is not something I’d recommend. If all your automations, scripts and scenes refer to v1, then when version 2 arrives you will need to update all references if you want all your automations to keep working.
If you want versioning, I’d use github to check in your yaml, and use its features for versioning your configuration files.
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
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.
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?
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??
Why both device_id and entity_id?
Why is the entity_id showing here as a GUID and not the entity_id string as shown in the user interface (see screenshots below)?
How would I dereference such a entity_id GUID back to it’s UI ‘friendly’ entity_id as shown in the UI’s entity listing?
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.
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.
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.
