Hello everyone first time here, I posted it also the discort chat (Discord).
I’m using HA now for about one year and everything was well documented and clear so far But now I’m struggling with one thing I don’t fully understand: the default entity_ids (for newly created sensors created through the config) are generated through the name. I tried basically all variants to get more control about it (using friendly_name, unique_id, skipping name, etc…) but there is no way. I couldn’t really find a discussion or bug about it, so that’s why I was thinking I try it here. What’s the design decision that the “default” entity_id is generated through the name, and not the unique_id?
What’s my use case:
I have several sensors, which then are “evaluated”/combined in another sensor. Therefore I need to reference the sensors via entity_id, but there is no way to configure this in a “developer friendly” way. Saying so, yeah I know I can just use the name attribute, but I like to organize things by scope or other relations, and then using the name for this is not really usefull for the UI site. My “workaround” is now to use the name for the entity_id, and reconfigure the name later in the UI, but again, I don’t understand why I cannot do this with e.g. the friendly_name attribute from the beginning on and skip the “additional & manual” UI settings for these new sensors? Another idea I was looking into is to look up the entity_id via unique_id, but I couldn’t find a way doing so. Looking things up via unique_id, would also solve my problem. It even improves the situation because renaming the entity id later on would not break anything :).
Long story short:
What’s the reason why I cannot set an entity_id and a friendly_name?,
Would it be feasable to implement an “entity-lookup-helper” to get entity-ids via unique_id? Or is this performance wise not a smart idea?
also ugly, but a working workaround… (haven’t tested it yet though).
still would like to know why it is designed like this, and what’s preventing us to just add “unique_id” earlier in the list of possibilities to generate the entity_id.
frenck can you have a look at this thread and let me know if a PR is welcome to “re-add” the ability to use friendly_name for UI name, and name (like it is right now) for the enitity_id.
Basically same thing like today, but in case “name” and “attributes.friendly_name” is explicity set, the friendly_name is not overwritten by name.
Do not tag people who are not involved in the conversation.
As for the topic at hand, the configuration style for modern template entities is not slug driven. Therefore the entity_id must come from some place. It cannot come from the unique_id as it may not exist. Secondly unique_id for template integration appends template_ to every unique_id under the hood. The resulting name when coming from uinque_id would be template_<whatever_you_entered, ultimately not something you’d want. Unfortunately, this isn’t something that can be changed.
Now that I have taken over the template integration, I will likely attempt to add object_id back in at some point. However it will not be done the way that the previous PR attempted to do it. It will be added in a non-invasive way if accepted.
Just understand that object_id is a low priority for me and the template integration needs other improvements first.
Hi petro, thanks for your response and sorry for tagging frenck, what’s the best way to check in advance if a PR will be accepted before working on it?
Regarding my last question to frenck, can you give me also some insights regarding the behaviour that friendly_name is always overwritten by name if it is set. Just quickly checked the code, here it seems that friendly_name is always set to name, if it is available
do you think it would be accepted to change this in case the attribute “friendly_name” is set already?
I’m sorry, but the name convention isn’t going to change because it needs to be backward compatible with all the integrations that are stuck in yaml. It also needs to support customize.yaml and renaming via the UI (if a unqiue_id is present). The core naming convention is likely here to stay. That doesn’t mean the modern style template entities will always remain that way.
Do you refer to the entity-id name convention or are you talking about the UI name? I’m not sure if I fully understand this, because the attributes.friendly_name is only frontend relevant, it wouldn’t change any existing behaviour regarding entity_id or configurations, except if there is a name and a attributes.frienldy_name defined and the name is different to the attributes.friendly_name:
Before: Now the friendly_name is silently overwritten, and name is used.
After: The friendly_name is used for the initial setup of the sensor.
Still only talking about the initial config.
But I don’t know all things of HA regarding names, the customize.yaml is quite new to me. As this affects the friendly_name, I’m pretty sure this cannot overwrite name at this stage…otherwise it would also impact the entity_id…which it doesn’t :). How well is the test suite? We could find it out with implementing it and looking into the test results?
All old yaml integrations require the name field and, in most cases, that name derives the entity_id. This functionality cannot change otherwise those integrations will break. So, no, the friendly name is not just “frontend relevant”.
