Template sensor: how to set a friendly name with a non-legacy syntax?

[petro]

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.

[finity]

@PeteRage

Except if you want to use the new trigger based syntax

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.

@Ildar_Gabdullin

Easy-peasy to give similar advices.

?

Not sure what you mean…

What are you trying to accomplish by using the new syntax?

[petro]

@finity

IMHO, that would be the only reason to use the new syntax at all.

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.

@pedolsky

friendly_name equals name. There is no visible attribute ‘some friendly name’.

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.

[finity]

@petro

If you want state_class

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.

[Ildar_Gabdullin]

Hello people, thank everyone for participating in the thread!

@finity

What are you trying to accomplish by using the new syntax?

1. I believed that the old format (“legacy”) is going to be deprecated some day.
2. The new format has new promising features (like a mentioned “trigger”).
3. 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:

@petro

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.

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:

1. Declare a sensor:

      - unique_id: xxx_yyy_zzz_3
        name: xxx_yyy_zzz_3_name
        state: "some state"
        attributes:
          attr_1: "value 1"

2. It creates a sensor:
   

   

3. 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"

4. It changes the sensor - a new “friendly_name”, old “entity_id”:
   

   

5. 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"

6. 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).

@petro

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.

Totally agree.

@petro

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.

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”.

@petro

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.

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).

[CentralCommand (Mike)]

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:

1. It means users can change the friendly name and entity ID from the UI
2. 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)
3. It means If you later change name in 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 change unique_id which then causes a new entity to be registered with new values. The old one would still be there with state unknown and restored: true in 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.

[Ildar_Gabdullin]

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.

[petro]

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.

[Ildar_Gabdullin]

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).

[petro]

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.

[Ildar_Gabdullin]

@petro

Change the entity_id back and you get your history back.

Yes, but with a gap.

[finity]

@Ildar_Gabdullin

is going to be deprecated some day.

(Hopefully) not likely.

@Ildar_Gabdullin

Now I suspect that this reaction was exaggerated and these people probably did not understand the issue properly.

@Ildar_Gabdullin

Now I think that was a hasty decision.

yup.

[Ildar_Gabdullin]

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

[erkr (Eric)]

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.

[ingo.niehues]

Thank you so much. With your tips i was able to convert my template-sensors to the new format.

[chadbaldwin (Chad)]

Adding this comment here as it’s the only way I’ve found to add friendly_name to a template sensor. This is the top google search result when trying to troubleshoot.

Hopefully in the future, friendly_name and friendly_name_template will be supported again because allowing a template for friendly_name would save me some headaches. Most of my template sensors are supplemental to it’s source sensor, so I usualy just want the original friendly_name plus some suffix.

Anyway, here’s my solution:

Add (bring back) friendly_name to template sensors

So I admit I haven’t read through ALL of the comments, but it seems this is still an active discussion even over a year later. But I’m a little confused, because it seems this is already supported in Home Assistant. Unfortunatley, you can’t seem to specify the friendly_name directly on the template sensor, but it is possible to set the friendly name. configuration.yaml homeassistant: customize: !include customize.yaml template: - sensor: name: contact_4_adj_temp unit_of_measure…

[CentralCommand (Mike)]

What you put in name becomes the friendly name of the template entity. It also accepts a template. So it covers all the use cases of friendly_name and friendly_name_template from the legacy syntax.

[Ildar_Gabdullin]

I create an entity with “sensor.bathroom_co2” name - and this becomes “entity_id”.
But I want to have another “friendly_name” - I want it to be “СО2: ванная”.
Now I have to use customization.

I do not want to specify “СО2: ванная” (even transliterated) as an “entity_id”.

Let me remind you that many users have SAME friendly names for DIFFERENT entities.

[chadbaldwin (Chad)]

But I don’t want that…

I want to create a sensor whose entity_id is contact_04_adj_temp and friendly_name is Contact 04 - Temp (Adjusted).

If I set the name to Contact 04 - Temp (Adjusted), the resulting entity_id will be contact_04_temp_adjusted, which is not what I want.

[chadbaldwin (Chad)]

Check out the solution I linked to. I use it for all of my template sensors and it works great. The down side is you have to split your friendly names out to a separate file. But it 100% works.