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

[Ildar_Gabdullin]

With a legacy syntax I can set a friendly name like this:

sensor:
  - platform: template
    sensors:
      xxx_yyy_zzz:
        friendly_name: "Some friendly name"
        value_template: >-
          {{ ... }}

How to set a friendly name with a new syntax?
I tried this:

template:
  - sensor:
      - unique_id: xxx_yyy_zzz
        name: "Some friendly name"
        state: >-
          {{ ... }}

The sensor is NOT CREATED without any errors/warnings in a Log.

Probably I could use this:

homeassistant:
  customize:
    sensor.xxx_yyy_zzz:
      friendly_name: "Some friendly name"

but this is an extra effort.

OK, what I can do is:

template:
  - sensor:
      - name: "Some friendly name"
        state: >-
          {{ ... }}

which will (probably) create a “sensor.some_friendly_name” sensor.
But I need to create the “sensor.xxx_yyy_zzz”.

If setting a friendly_name is NOT possible with a new syntax - then I will be disappointed.

[pedolsky]

If you use unique_id you’ll be able to assign a friendly name via UI.

[Ildar_Gabdullin]

1. If I do not want to use UI - does it mean that I cannot customize a friendly_name?
2. The sensor is NOT CREATED. Nothing to customize.

[pedolsky]

@Ildar_Gabdullin

The sensor is NOT CREATED without any errors/warnings in a Log.

I’m not sure if I can follow.
I don’t mean using it in a dashboard. You can customize a friendly name under /config/entities.

[Ildar_Gabdullin]

May be I did not understand you.
My steps:

1. Declare a sensor:

template:
  - sensor:
      - unique_id: xxx_yyy_zzz
        name: "Some friendly name"
        state: >-
          {{ ... }}

2. Restart HA or reload template entities.
3. Go to entities list in Settings - there is no “sensor.xxx_yyy_zzz” sensor (as well as “sensor.some_friendly_name”). The sensor is not created.
4. Goto Log - it contains no info about this sensor.

What I expected:
3. The sensor "sensor.xxx_yyy_zzz" is created, it has a friendly_name “Some friendly name”.
or
3. The sensor "sensor.some_friendly_name" is created, now I can open it’s settings and manually input a friendly name “Some friendly name”.
or
3. The sensor "sensor.some_friendly_name" is created, now I can customize it (using YAML) with friendly name “Some friendly name”.

[pedolsky]

That’s the way it normally works ( sensor.some_friendly_name will be created and you can customize it via UI or customize.yaml / customize section). I can’t say why nothing is created in your case.
Can you please post your full sensor code?

[Didgeridrew]

Friendly name is just an attribute, so you add it as you would any other attribute:

template:
  - sensor:
      - unique_id: xxx_yyy_zzz
        name: "Some name I want the entity_id based on"
        state: >-
          {{ ... }}
        attributes:
          friendly_name: "This is my friendly name"

[Ildar_Gabdullin]

Sorry, do not know how it happened - but I was wrong.
The sensor IS created.
And it has a entity_id “sensor.some_friendly_name”, a name “Some friendly name”.

Now I can change it’s entity_id & name via UI.
But - I need this sensor to be "sensor.xxx_yyy_zzz" - and why I cannot get it via YAML?

OK, I may specify “xxx_yyy_zzz” as a name in YAML:

template:
  - sensor:
      - unique_id: xxx_yyy_zzz
        name: xxx_yyy_zzz
        state: >-
          {{ ... }}

and the created sensor is “sensor.xxx_yyy_zzz”.
Now to set a friendly_name I need to either use UI or customize option.
Why it is not possible to specify a friendly_name while declaring a sensor? (like it is possible for legacy syntax)

I do not like a trend to replace YAML by UI. I am trying to keep all code in YAML.
Currently I will have to use the “customize” option to set a friendly_name. This is not a progress.

[Ildar_Gabdullin]

I am not getting a logic of the new syntax.
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"

creates these sensors (I even restarted HA):

1. Why names & entity_ids are mixed?
2. Where is the 3rd sensor?

Seems that with the new syntax some code is stored in json files and CANNOT be changed by YAML.
That is why I do not call it a “progress”.

I just started using the new syntax (probably after more than a year when it was invented), currently seems that it is not as predictable as the legacy syntax.

[Ildar_Gabdullin]

@Didgeridrew

so you add it as you would any other attribute:

See my post above - no sensor is created ))))).
Unpredictable behaviour.

[finity]

Just don’t use the new style template. use legacy.

Easy-peasy.

[PeteRage]

Except if you want to use the new trigger based syntax which is super powerful.

Let’s just add the attribute in.

[Ildar_Gabdullin]

@finity

Just don’t use the new style template. use legacy.

Easy-peasy to give similar advices.

[pedolsky]

@Didgeridrew

attributes:
          friendly_name: "This is my friendly name"

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

[Ildar_Gabdullin]

@pedolsky

Seems that friendly_name isn’t accepted

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 (((

[pedolsky]

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'"

[petro]

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.

[pedolsky]

@petro

  - sensor:
      - name: xxx_yyy_zzz
        state: "{{ blah }}"
        attributes:
          friendly_name: Some Friendly Name

And how to display this friendly name?

[petro]

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.

[pedolsky]

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