(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
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:
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.
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.
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.
1 Like
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.
Thank you, that is what I am already using - customization.
And you MAY NOT specify customizations in a separate file.
Described here.
So you’re missing an entity_id field, not a friendly_name field. Ok, different then what you said. You were asking for a replacement for friendly_name and friendly_name_template and that exists. But yes there is no way to set entity_id to something other then the name slugified in YAML.
If you are determined to do it in YAML only then what you linked is the best way. Although that means it is impossible to use a template for friendly name. The way to do it which still supports using a template for friendly name is like this:
- Set name to the value you want to use for
friendly_nameor the template you want to dynamically setfriendly_name - Add something unique in
unique_id(you’ll never see this value anywhere in the UI it just makes it UI-editable) - Reload template entities
- Find your new entity anywhere in the UI. Open its more info panel and set its
entity_idto whatever you want from there - Never change
unique_id. As long asunique_idstays the same in YAML, so willentity_id.
I’m not sure what you mean when you say you can’t specify customizations in a separate file. I’m currently doing that now.
configuration.yaml
homeassistant:
customize: !include customize.yaml
template:
- sensor:
- name: contact_01_adj_temp
unit_of_measurement: °F
state: "{{ (states('sensor.contact_01_temp') | default(0, true) | float + 2.9) | round(1, default=0) }}"
device_class: temperature
customize.yaml
sensor.contact_01_adj_temp:
friendly_name: Contact 01 - Temp (Adjusted)
Not saying “cannot”. I mean - “you MAY specify it in a separate file, in the same file - as you like”.
Update: probably my English was not clear, sorry!
I see. So unique_id is essentially the natural key used by HA when storing it in the database. And since it’s able to store it in the DB, it’s now able to let you customize it. So it allows you to change the entity_id and it’s persistent.
I’ve always wondered what the difference between entity_id and unique_id is.
I’ll try that out, thanks!
1 Like
This method requires changes in UI.
Earlier users may only use yaml config.
Right. That’s your requirement, not everyone’s.
I wasn’t trying to solve this post. I was simply trying to help the user who replied saying the only way to set friendly_name is via customize. Wanted to make sure they knew that’s not true as long as you’re willing to use the UI. Seems like they were willing to do that.
Sure.
Since I started using HA (September 2020) I have always been against moving settings from yaml to UI w/o possibility to manage them in yaml.
Keeping settings in yaml for entities (sensors, automations, customization, …) gives a great opportunity to:
- disable whole modules - disable all entities, automations etc related to some functionality - by simple moving related yaml files (or renaming them to different file extensions);
- moving whole module to another HA instance.
But this is another story.
2 Likes
Old thread, but I encountered this limitation last night. I was trying to set up some RESTful sensors (which can only be done in YAML) and realized that specifying the entity_id and friendly_name was impossible using the “new” format.
In this fairly long thread, I’ve seen people question the need for specifying an entity_id in the yaml. After all, it can be edited in the UI, right?
Consider, then, a package that creates a restful sensor named “status” and trying to find that in the UI to change it:
Now, I’ll admit I’m fairly new to HA so perhaps I’m missing something, but the only way I’ve found to find that entity in the UI is to go to the settings->entities page. Because RESTful doesn’t create devices, or even show as an integration in settings, I can’t filter the entities list. So, head to that page containing ALL the entities, and type “status.” On my particular installation, that results in over 100 lines. It seems every single one of my devices at least one entity with the word “status” in it.
Personally, I’d much rather if the default entity name was based on the unique_id and only used “name” if the unique_id wasn’t specified. At least that would make it easier to find the created entities for editing, inclusion, etc. It would also have the advantage of not creating silly entity names such as “sensor.status_2”, “sensor.status_3”, etc.
Restful sensors have never had this ability? They were previously platforms and the entity_id was built off the name, like everything else.
Legacy templates is one of the few integrations that has the ability to pull the entity_id from the slug used in it’s configuration.
There’s also developer tools → states.
All YAML created entities are like this, not just rest.
Rest entities are not the same as template entities. Their default setup w/ unique_id & name most likely differs from the template integration (which is what this thread is about). I recommend trying to exclude the name and see what name is used. Chances are, it will not have an template_ in the entity_id.
Sorry, I neglected to mention that my venture into restful sensors originated from a legacy rest platform sensor, and then legacy template sensors that pulled data from that first sensor.
I was converting that into a single restful thingamajig with a bunch of sensors. (I’m still too new to have the terminology right. It might be better if I showed examples:)
This is what I started with:
sensor:
- platform: rest
name: sensor.this_has_my_data
resource: ...
....
- platform: template
sensors:
sensor1:
unique_id: unique_string
name: this_becomes_part_of_entity_id
# the templates use "sensor.this_has_my_data"
friendly_name: {{ "name1" if something else "name2" }}
...
sensor2:
...
This is what I ended with:
rest:
resource: ...
sensor:
- name: {{ "name1" if something else "name2" }}
unique_id: unique_string
...
- name: sensor2
....
In the old style I can reference entities because I know what the entity ID’s are. I also have more flexibility with the name/friendly_name. In the new style, all that control is lost. My very first impression was that I moved from linux to macOS.