FWIW, I use a combination of the UI and customize entities. All my old entities are customized via customize. Anything new, I just add a unique_id, a name to set the entity_id, and just set the name via the UI.
1 Like
Then that must have changed in the past year due to all the people wanting to template the name. If that’s the case, you’d have to use customize or keep the old style.
For my part, I have made peace with it because I like the new syntax.
I’ve never really had an opinion. I like editing things via the UI and I like things being un-editable, I pick and choose which ones I want.
Personally, I don’t give a crap what my entity_id is. I see too many people trying to manage their system based on entity_id’s and IMO it makes templates a pain in the ass to work with because you have to add strings together. I’d rather add custom attributes to things or use the built in functions to filter in my templates so that the entity_id doesn’t matter.
I.e. use integration_entities('zwave_js') to get all zwave entities.
If I have a bunch of entities that I want for a specific template? I create an automation that uses a template to generate a group on template reload and home assistant start. If I add an entity randomly, I just run the automations actions to add it to the group.
There’s a number of ways to work really fast without needing to organize off the entity_id, and IMO it’s an outdated way of doing things.
And my worse case scenario is if I want to single out a series of entities for a specific calc without a group. I just customize an attribute.
sensor.xyz:
custom_attr: custom_value
or add it directly to the template sensor / entity
attributes:
custom_attr: custom_value
1 Like
In the end, these are questions of taste, and it’s notoriously difficult to debate them.
I love everything pretty because I can work better with it. Anything else would be ‘pain in the ass’ for me.
And I also like to use the power of custom attributes in combination with filters. But I can also understand the OP very well, because having to edit different places to achieve a certain result is not stringent work.
1 Like
Right, but he should then just use the old style. There’s nothing stopping that and it isn’t deprecated. The way the code works, it doesn’t look like it will ever be deprecated because it just takes the legacy config and feeds it into the new style validation.
IMHO, that would be the only reason to use the new syntax at all.
And that feature’s usefulness is limited. most sensors update as desired without it and I have yet to use it. Tho I could potentially see the need for at times (which I haven’t needed yet).
I only have one situation that lends itself to that feature (my one second updater) that I was using a sensor and an automation to update it every second that I could use if I needed another sensor to update every second (I don’t use it anymore tho). with the triggered sensor I could have done it all in one step.
?
Not sure what you mean… 
What are you trying to accomplish by using the new syntax?
If you want state_class on sensors, template numbers, template selects, or template buttons, you should use the new integration. Also, any new template entity will go in this as well.
Otherwise you can use the new integration if you like the syntax better. Otherwise it’s just preference after that.
FYI I looked at the code and this was definitely changed at some point to support templating the name field. Useless change IMO. Should have just left the name as is and allowed friendly name in the attributes.
Another FYI, if you’re switching from the old platform to the new platform, you only need to supply the unique_id and everything will transfer over as the config entry already exists.
So this entity_id & name limitation is only when creating new entities.
I really don’t care about long term statistics so never had a use for that either.
But it is another good use case if someone does.
Hello people, thank everyone for participating in the thread!
- I believed that the old format (“legacy”) is going to be deprecated some day.
- The new format has new promising features (like a mentioned “trigger”).
- Sometimes I asked smth in the Community and posted the old format - and got a reaction like “oh, this is an old format, cannot say anything, probably you should UPGRADE to the new format”. Now I suspect that this reaction was exaggerated and these people probably did not understand the issue properly.
As a result - I started to convert all my sensors to the new format.
Now I think that was a hasty decision.
I only need to use the new format if I really need the “new features”.
I will keep the old format where I declared “friendly_name” as a part of sensor’s declaration and where do not need the “new features”.
Regarding my problem “why my sensors are mixed and some sensors are missing”:
I still do not understand why this code:
- sensor:
- unique_id: xxx_yyy_zzz
name: "Some friendly name"
state: "some state"
- unique_id: xxx_yyy_zzz_2
name: xxx_yyy_zzz_2
state: "some state"
- unique_id: xxx_yyy_zzz_3
name: xxx_yyy_zzz_3
state: "some state"
attributes:
friendly_name: "This is my friendly name"
caused this:
As Petro said:
But I am 95% sure that I did not change anything neither in YAML nor in UI.
Others 5% is “OK, I am stupid and forgot that I corrected smth in YAML”.
Anyway - what I did to fix that glitch is:
- comment a code for these sensors;
- restart HA (or reload templates);
- in the entities list (Settings → Entities) the old entities “sensor.xxx_yyy_zzz_2” & “sensor.xxx_yyy_zzz_3” are marked as unavailable and restored;
- remove these entities via UI;
- uncomment a code for these entities;
- restart HA (or reload templates).
After that all created sensors have expected entity_ids (equal to “name” options).
Another test:
- Declare a sensor:
- unique_id: xxx_yyy_zzz_3
name: xxx_yyy_zzz_3_name
state: "some state"
attributes:
attr_1: "value 1"
-
It creates a sensor:
-
Then edit YAML - change the “
name” & add an attribute:
- unique_id: xxx_yyy_zzz_3
name: xxx_yyy_zzz_3_name_corrected
state: "some state"
attributes:
attr_1: "value 1"
attr_2: "value 2"
-
It changes the sensor - a new “
friendly_name”, old “entity_id”:
-
Then again edit YAML - change the “
unique_id”:
- unique_id: xxx_yyy_zzz_3_corrected
name: xxx_yyy_zzz_3_name_corrected
state: "some state"
attributes:
attr_1: "value 1"
attr_2: "value 2"
- The original sensor becomes “unavailable”, the new sensor is created:
I find this very logical.
Also, if you need to change an “entity_id” for some sensor - you have to “comment the code / reload templates / remove unavailable restored entities / uncomment the code / reload templates” - or just change “entity_id” via UI.
Regarding “unique_id”.
Check this example:
template:
- sensor:
- unique_id: xxx_yyy_zzz
name: "Some friendly name"
state: "some state"
- binary_sensor:
- unique_id: xxx_yyy_zzz
name: "Some friendly name"
state: >-
{{ states("input_boolean.test_boolean") }}
Both entities seem to have the same “unique_id”.
But both entities are created:
That means that there is no need to specify a “DOMAIN.xxx_yyy_zzz” for “unique_id” - IDs should be unique within a domain (like entity_id).
First I believed that IDs should be globally unique but I was wrong - they are like “entity_ids”.
Regarding adding a “friendly_name” as an attribute:
- unique_id: xxx_yyy_zzz_4
name: xxx_yyy_zzz_4_name
state: "some state"
attributes:
friendly_name: "This is my friendly name"
The attribute is added but not used as a friendly name (as it was noted earlier).
It is not listed as an attribute in a more-info window:
but is available on a Dev tools page:
and probably may be accessed (as it was noted earlier).
Totally agree.
Except “friendly_name” option - it is not allowed in the new format, so you have to exclude this line from the code, and then provide a friendly name via UI or via YAML (“customize”).
Regarding using “entity_id”.
This is a very important thing for me.
Currently I am trying to follow some “naming rules” for entity_id.
I will try to come back to this issue later (probably this is a bit off-topic here).
1 Like
I think the confusion really this fundamental misunderstanding: unique_id is not entity_id.
In fact, the new format has no option to set entity_id. None. The initial entity_id is always generated from other fields provided, you cannot say “this is what I want it to be”.
That’s basically the TL;DR. More detailed explanation of pieces to clear some stuff up:
name = friendly_name. Whatever you put there becomes the initial friendly name. In addition if this field is provided the initial entity ID is generated by slugifying (i.e. lowercasing it and replacing all non-alphanumeric characters with underscores) this value.
unique_id = ID the entity is registered with in the entity registry. This value is generally entirely behind the scenes. Users do not interface with the entity registry directly. IDs there are not the same as entity IDs. However as petro noted above, if name is omitted and unique_id is provided then the initial entity ID is created using unique_id. It is a fallback basically. But only if name is omitted
UI config - If unique_id is provided the the entity is added to the entity registry. This changes a few things:
- It means users can change the friendly name and entity ID from the UI
- It also means other config can be changed from the UI (like adding it to an area or setting it to hidden and maybe more in the future)
- It means If you later change
namein the yaml that really doesn’t do anything at all. The entity is registered with the initial friendly name and entity ID. Changes to those values from that point forward are done via the UI only. To have changes in YAML affect these values you would need to changeunique_idwhich then causes a new entity to be registered with new values. The old one would still be there with stateunknownandrestored: truein its attributes though so it would need to be manually removed via the UI.
I should also note that the legacy format also has unique_id as an option. If you want to be able to add your sensor to an area then you have to use it. If you do then changing friendly_name or the entity ID in the legacy format also does nothing. Those values are now UI-configurable. My #1-3 applies the same there as well.
3 Likes
But there is a problem here.
Check this sensor:
- binary_sensor:
- unique_id: xxx_yyy_zzz
name: "Some friendly name"
state: >-
{{ states("input_boolean.test_boolean") }}
Change a value of this sensor:
Now change the “enity_id” of this sensor:
And here is the new history:
The old history is lost.
I believed that this sensor is SAME but with a new entity_id.
There is no any “restored” sensors after changing “entity_id” occur.
That’s completely separate. The unique id for the entity is not used in history or recorder. The unique id is for the entity registry. History and recorder work off entity ids, not the registry. If the entity id changes, history and recorder make a new entry to the database under the new entity id.
1 Like
Now many issues became more clear.
Thanks a lot for explanations.
As I can see, if a user is interested in a specific “entity_id” he is supposed to change it via UI only ONCE right after creation of the sensor - or this “entity_id” should be defined by the “name” option ONCE and FOREVER (like with the old format - once and forever, otherwise the history will be lost).
If you care about history, yes
Keep in mind, if you change an entity_id, the history is not lost. Change the entity_id back and you get your history back.
Yes, but with a gap.
(Hopefully) not likely.
yup.
1 Like
IMHO w/o using UI with the new format, in some cases specifying friendly names is not a big deal.
Assume we have 15 similar sensors, for them I need to specify friendly names.
Old format:
For these similar sensors I use a code-generator:
{% set OBJECTS = [
"object_1",
"object_2",
...
"object_15"
] %}
{% set code_sensor = '
test_{0}:
friendly_name: "Service: {0}"
value_template: >-
{{{{ ... }}}}
' %}
sensor:
- platform: template
sensors:
{%- for object in OBJECTS -%}
{{ code_sensor.format(object) }}
{%- endfor %}
The generated code is:
sensor:
- platform: template
sensors:
test_object_1:
friendly_name: "Service: object_1"
value_template: >-
{{ ... }}
test_object_2:
friendly_name: "Service: object_2"
value_template: >-
{{ ... }}
...
test_object_15:
friendly_name: "Service: object_15"
value_template: >-
{{ ... }}
New format:
The code-generator:
{% set OBJECTS = [
"object_1",
"object_2",
....
"object_15"
] %}
{% set code_sensor = '
- name: test_{0}:
state: >-
{{{{ ... }}}}
' %}
{% set code_customize = '
sensor.test_{0}:
friendly_name: "Service: {0}"
' %}
template:
- sensor:
{%- for object in OBJECTS -%}
{{ code_sensor.format(object) }}
{%- endfor %}
########################################################
homeassistant:
customize:
{%- for object in OBJECTS -%}
{{ code_customize.format(object) }}
{%- endfor %}
The generated code is:
template:
- sensor:
- name: test_object_1:
state: >-
{{ ... }}
- name: test_object_2:
state: >-
{{ ... }}
- name: test_object_15:
state: >-
{{ ... }}
########################################################
homeassistant:
customize:
sensor.test_object_1:
friendly_name: "Service: object_1"
sensor.test_object_2:
friendly_name: "Service: object_2"
...
sensor.test_object_15:
friendly_name: "Service: object_15"
Yes, I still do not like it - I have to keep a code for one sensor in different places.
Hope someone will convince the Dev team to add a new “friendly_name” option to the new format.
Why I do not like UI - because using YAML gives me a flexibility like:
- using global/package-wide constants/dicts (using “secrets” for this);
- using packages: disable a package, move packages to another HA setup;
- commenting some functionality;
- adding notes in the code;
- etc
5 Likes
For me preserving the original entity_id’s was crucial to keep my history and all cards working.
Migrating directly from the old to the new format results in new entity ids, being equal to the friendly name.
I found an easy way to migrate, without the need to change back all the entity_id’s. This is migration in two simple steps (instead of migrating directly), without UI editing afterwards!
The original legacy template definition, where:
-
entity_id=original_sensor_name -
friendly_name= “Some friendly sensor name”
sensor:
- platform: template
sensors:
original_sensor_name:
friendly_name: "Some friendly sensor name"
value_template: >-
{{ ... }}
First step in migrating to the new definition, where the result will be:
-
entity_id=original_sensor_name -
friendly_name=original_sensor_name(this is just for the initial creation with an unique ID)
template:
- sensor:
- unique_id: original_sensor_name
name: original_sensor_name
state: >-
{{ ... }}
reload the template definitions.
Second step in migrating to the new definition, where we change the name property to the desired friendly name:
-
entity_id=original_sensor_name -
friendly_name= “Some friendly sensor name”
template:
- sensor:
- unique_id: original_sensor_name
name: "Some friendly sensor name"
state: >-
{{ ... }}
reload the templates again. Due the unique ID, this only changes the friendly name, and preserves the entity_id assigned in step one.
Hope this helps others facing the same migration headache.
9 Likes
Thank you so much. With your tips i was able to convert my template-sensors to the new format. 
1 Like