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.
May be I did not understand you.
My steps:
- Declare a sensor:
template:
- sensor:
- unique_id: xxx_yyy_zzz
name: "Some friendly name"
state: >-
{{ ... }}
- Restart HA or reload template entities.
- 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. - 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”.
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?
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"
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.
2 Likes
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):
- Why names & entity_ids are mixed?
- 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.
See my post above - no sensor is created ))))).
Unpredictable behaviour.
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.