Just don’t use the new style template. use legacy.
Easy-peasy.
Except if you want to use the new trigger based syntax which is super powerful.
Let’s just add the attribute in.
Easy-peasy to give similar advices.
I tried this from version to version. Seems that friendly_name isn’t accepted. The attribute is only built if I use another alias (e.g. friendly: or details: ).
1 Like
Did you see any records in the Log?)
I did not.
The sensor is just not created. Silently.
Moreover, the “friendly_name” is not supposed to be added as a simple attribute. So, that advice of another person “add this attribute” was not based on knowledge (((
I can access the attribute, but it’s not displayed as one:
- sensor:
- name: "what we'll not see in frontend"
unique_id: wwnsif
state: "{{ this.attributes.friendly_name |default('Value when missing') }}"
attributes:
friendly_name: "attribute 'friendly_name'"
If you use unqiue_id, then your entity_id will be sensor.template_xxx_yyy_zzz. If you omit unique_id and jus t use name, your entity_id will be sensor.some_friendly_name. Your entity is created, but you’re searching for the wrong term.
FYI. Everything I just said is what happens when you FIRST create the sensor. If you make changes to the configuration but maintain the unique_id, everything I just said is thrown out because it’s now inside your entity_registry and you have to manage the names in the UI.
If you want everything set via the YAML with a name and friendly name…
- sensor:
- name: xxx_yyy_zzz
state: "{{ blah }}"
attributes:
friendly_name: Some Friendly Name
Second to Lastly, as @finity said… just don’t use the new style if you want a unique_id, entity_id, and name to be all different. The sole purpose of supplying a unique_id is to manage the entity from the UI. If you don’t have those intentions, don’t use it with the new style.
Lastly, the other option is to also customize your entity in the customize section.
And how to display this friendly name?
It should be like any other entity and be an attribute on the entity itself. Again, keep in mind that you cannot have a unqiue_id and you have to be editing a new entity. As soon as you create a sensor with unique_id, any yaml edits to name may not appear depending on what you did in the UI.
1 Like
friendly_name equals name. There is no visible attribute ‘some friendly name’.
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