If an integration doesn’t provide a unique_id for an entity, the entity cannot be customized (custom entity_id, room etc.). Why can’t the entity_id provided by the integration not simply double as the unique ID for all practical purposes, if the integration reports no unique ID? Just assume the integration had reported what it reports as the entity_id as the unique ID. Sure, this ID is not as stable as a serial number, but that doesn’t really matter because we use the fixed entity_id as the unique ID for all practical purposes anyway.
What would the harm of that be compared to what we have today? If all we have is an entity_id that we cannot change, clashes already happen. Does it really matter if the clash happens based on a unique_id rather than an entity_id?
Because it comes from yaml. Home assistant is asynchronous. Meaning events happen when they happen. The startup process is asynchronous. Yaml integrations are loaded asynchronously. What happens when you have 2 integrations with the same entity_id configured in yaml? They flip flop between sensor.xyz and sensor.xyz_1. It’s not really unique, and we can’t tell which one is which. This was a big problem back when most integrations were all yaml without a unique_id. It still is a problem when yaml integrations don’t provide an option to use a unique_id.
It’s a “been there, done that, didn’t work” situation. So we have unqiue_id and entity_id.
In that setup, what good is the avoidance of a unique ID? How am I gonna do anything with sensor.xyz if it could be sensor.xyz_1 the next time around, and my sensor.xyz then is a different entity, thus invalidating all my dashboards, automations, …? I don’t have any other handle to that entity other than the ID sensor.xyz, and if that’s not reliable, well, to me that seems like that’s pretty much the end of the story anyway.
I get the point of clashes between integrations though. Because unique IDs don’t have to adhere to the domain.sensor pattern, a straightforward extension of the above would seem to just prefix the entity_id-based unique_ids with the name of the integration. Not sure what the rules are for unique_ids, but one certainly can think of a scheme that also makes clashes with real unique_ids unlikely, something like hass-assigned-unique-id:<integration name>:<entity id>. Then an integration is just responsible for avoiding clashes between the entities it reports, which it probably has to do anyway.
Unique_ids are truly unique under the hood in home assistant. When an entity has a unique_id, we 100% know. Secondly the unique_id system doesn’t allow creation of a clash, it will report an error. Entity_id on the other hand is as old as home assistant, and it behaves the way it does due to backwards compatibility with old integrations that haven’t been brought up to speed with unique_ids.
I still don’t understand the adverse practical consequences of substituting a fake unique ID derived from integration name and entity_id. Are there instances of one integration reporting two entities with the same entity_id? Even if so, if the two entities flip-flop between sensor.xyz and sensor.xyz_1, what does it matter if they do so based on the entity ID or the unique ID?
The adverse affect is: the unique id would be created based on the entity_id which you can change via the ui. It’s a chicken egg scenario.
Secondly, every integration would need to implement this change separately. Just like what we have for the ui. To put that into perspective, it’s taken ~3 years to convert 30% of the integrations into the ui. So even if this wth is satisfied in any integration, the chances of it being in all integrations is effectively zero.
When an integration that doesn’t set a unique_id adds an entity to HA, it does so through a provided callback. Furthermore, each of these entities has some “pre-defined” entity_id, either set by the integration or derived according to some scheme. What I had in mind was to (a) use only that entity_id for generating the unique ID, not the one that can be changed later, and (b) do the injection of unique_id by modifying the callback supplied by the core, not any integration-specific logic.
That’s not true, it’s set through the naming engine which can cause conflicts because it’s set by the user. Entity_ids are restricted to numbers, letters, and underscores and are autogenerated from the name field. You can have 2 unique names but end up with the same entity id. This is because all the names or user input entity ids are sluggified before creating the entity.
There is no “one solution fits all” for this change while maintaining backward compatibility. Embrace the unique_id for yaml entires or use the ui.
Also, the callback is provided by each integration. It’s not a single callback like you’re assuming it is. It needs to be added to each and every callback for every integration.
Unique ID: This is a stable, none-changeable identifier. For example, consisting of a MAC address of a device, a serial number, that kind of thing. It is used to be able to uniquely, and stably identify a device and its entities. Regardless, of any other change.
Entity ID: This is a user identifier. You define the entity ID, you can change it or it could be based on the name. Additionally, entity IDs will iterate when a collision occurs (e.g., adding _2 to it).
So, the unique ID is what internally is always used to be able to point to the same entities in a stable way. Entity ID is yours to do whatever you like and want.
Considering the above, it means that a unique ID should be provided by the integration, not the user.
That said, adding unique IDs to integration, in general, is a fairly easy task for a developer to do, so if you run in such cases: Maybe just ask if it is possible to add for that specific integration.
When I started learning about HA, most videos don’t advise the use of Unique ID especially in templating. so most of my template sensors are with names/friendly names.
so my inquiries are:
Should I go over all my yaml stuff and provide Unique ID (the VS Code UUID generated) for them?
If I do so, what effect will this have on my system? will I need to go all over the dashboards and correct things?
Finally! What will I benefit from this time/effort put into this process?
One thing I know for sure, is that your advice will help me manage my HA development.