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.
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.
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.
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_name or the template you want to dynamically set friendly_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_id to whatever you want from there
Never change unique_id. As long as unique_id stays the same in YAML, so will entity_id.
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 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);
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:)
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.
Notice that the implied name of those sensors are sensible things that would be easy to find in the entity list (as each one would begin with “sensor.swx1” From my experiments, those would end up being entity_id’s. The ‘friendly_name’ is treated as a UI element, and NOT as something that would eventually be part of the entity_id.
Examples that use templates include “swx1_current_print”, “swx1_nozzletemp”, and “swx1_bedtemp.”
Sure, the data could be presented in some other way. Or a person could keep using the legacy format. However, telling people both that they have to use YAML (instead of the UI) and then severely limiting their option (as if they were using the UI to begin with) is silly in my opinion.
A lack of flexibility in the UI is understandable. A lack of flexibility when using YAML is just cruel.
I see what your goal is. Personally I would only template the name in the frontend. Anyways, you can still keep your current config and minimize your template sensors by mixing and matching what you need.
This is the YAML I ended up with after converting (with some data altered for privacy.) It mostly results in the same as the original above (with some slight tweaks.) In order to fix the entity_id’s, I first loaded the YAML with all the “name:” lines commented out. I though that would give me entity_id’s based on the unique_id’s, but actually resulted in a bunch of “sensor.unknown”'s. So, I searched for “sensor.unknown” in the entity list and based on the entity values, I was able to determine what was what, and manually edited each of the entity id’s (which was annoying.) Then I uncommented all the ‘name’ lines and things work as expected.
It shouldn’t be that difficult when I’m already messing around in the YAML. Once I’m committed to that level of tweaking, I should be given all the flexibility I need without limitation as long as it doesn’t break anything.
rest:
resource: "http://1.2.3.4:5678/printer/objects/query?heater_bed&extruder&print_stats&toolhead&display_status&virtual_sdcard"
sensor:
- unique_id: v2_3061_state
name: "Status"
#friendly_name: "Status"
icon: mdi:printer-3d
value_template: >-
{{ value_json.result.status.print_stats.state if value_json is defined else [] }}
- unique_id: v2_3061_current_print
name: >-
{{ ("Printed" if value_json.result.status.display_status.progress == 1 else "Printing...") if value_json is defined else [] }}
icon: mdi:video-3d
value_template: >-
{{ (value_json.result.status.print_stats.filename.split(".")[0]) if value_json is defined else [] }}
- unique_id: v2_3061_current_progress
name: "Progress"
unit_of_measurement: '%'
icon: mdi:file-percent
value_template: >-
{{ (value_json.result.status.display_status.progress * 100) | round(1) if value_json is defined else [] }}
- unique_id: v2_3061_print_time
name: "T-elapsed"
icon: mdi:clock-start
value_template: >-
{{ value_json.result.status.print_stats.print_duration | timestamp_custom("%H:%M:%S", 0) if value_json is defined else [] }}
- unique_id: sensor.v2_3061_time_remaining
name: "T-remaining"
icon: mdi:clock-end
value_template: >-
{{ (((value_json.result.status.print_stats.print_duration / value_json.result.status.display_status.progress - value_json.result.status.print_stats.print_duration) if value_json.result.status.display_status.progress > 0 else 0) | timestamp_custom('%H:%M:%S', 0)) if value_json is defined else [] }}
- unique_id: sensor.v2_3061_eta
name: "T-ETA"
icon: mdi:clock-outline
value_template: >-
{{ (as_timestamp(now()) + 2 * 60 * 60 + ((value_json.result.status.print_stats.print_duration / value_json.result.status.display_status.progress - value_json.result.status.print_stats.print_duration)) if 1 > value_json.result.status.display_status.progress > 0 else 0) | timestamp_custom("%H:%M:%S", 0) if value_json is defined else [] }}
- unique_id: sensor.v2_3061_nozzletemp
unit_of_measurement: "°C"
name: >-
Nozzle
{{ (["(-> ", (value_json.result.status.extruder.target | float | round(1)), "°C)"] | join if value_json.result.status.extruder.target > 0) if value_json is defined else [] }}
icon: >-
{{ ("mdi:printer-3d-nozzle-heat" if value_json.result.status.extruder.target > 0 else "mdi:printer-3d-nozzle-heat-outline") if value_json is defined else "" }}
value_template: >-
{{ value_json.result.status.extruder.temperature | float | round(1) if value_json is defined else [] }}
- unique_id: sensor.v2_3061_bedtemp
unit_of_measurement: "°C"
name: >-
Bed
{{ (["(-> ", (value_json.result.status.heater_bed.target | float | round(1)), "°C)"] | join if value_json.result.status.heater_bed.target > 0) if value_json is defined else [] }}
icon: >-
{{ ("mdi:radiator" if value_json.result.status.heater_bed.target > 0 else "mdi:radiator-off") if value_json is defined else "" }}
value_template: >-
{{ value_json.result.status.heater_bed.temperature | float | round(1) if value_json is defined else [] }}