Yes, but removing the name in yaml will give a sensor named sensor.template_xxx
Don’t like that haha 
With Name and ID it will label the sensor as a template integration only
no it wont. I said ‘after that’. So first create the entity with the unique_id, and then remove the name: option
1 Like
Is there any other reason to not (besides the name) use unique_id to make it editable in UI?
(i have read something about not editable in the YAML anymore, but can’t find it)
This has been around WAY too long and should be completed with a solution. The friendly name never went away, it just changed. Unique_id is not meant for the user to use at all, it is a backend thing used by the UI. So that has to be unique and it is not referred to by humans anywhere.
You add an attributes key then a friendly_name key.
If you think about it, it makes a lot of sense because that is an attribute and belongs there with any other attributes you would like to add.
This was available when the format changed, but was not explained very well.
- name: sun_state
unique_id: f2ef3978-8f60-4f49-9ce5-1198306412fd
state: >
{% if is_state('sun.sun', 'above_horizon') %}
up
{% else %}
down
{% endif %}
availability: >-
{% from 'availability_template.jinja' import avail %}
{{- avail(['sun.sun']) | bool -}}
attributes:
friendly_name: "My Sun State"
Not exactly.
Many users wish to define entity_id & friendly_name SEPARATELY.
In YAML, w/o using UI.
Ofc we can do
- sensor:
- name: "Battery iPhone 99S+"
...
and then change entity_id in UI to “battery_iphone_99s_plus”. But as I said - some prefer yaml.
Like in my example> If I used the same name, forgive me, I’ll change one of them in an edit.
They are different data, friendly_name is an attribute of the entity_id.
did you reload the templates? I’ve been using it for a couple of years…
Ofc I reloaded templates (the sensor was created).
HA seems to not allow to add a custom attribute with same name.
No errors in Log.
It used to work… Hmmm.
May be some time ago HA allowed to create attributes with same names as “standard” ones…
This is what’s going on.
Template sensor: how to set a friendly name with a non-legacy syntax? - #31 by CentralCommand.
The post of Mike describes (very clear) what name, friendly_name, entity_id & unique_id stand for.
But it does not confirm/explain your suggestion to use a custom friendly_name as a custom attribute.
I had it wrong, this looks better solution.
Template sensor: how to set a friendly name with a non-legacy syntax? - #39 by erkr.
And yes, history is messed up apparently sometimes.
Template sensor: how to set a friendly name with a non-legacy syntax? - #42 by CentralCommand.
It needs 2 steps:
Create:
template:
- sensor:
- name: desired_entity_id
unique_id: desired_entity_id
state: ok
Edit:
template:
- sensor:
- name: "The best sensor"
unique_id: desired_entity_id
state: ok
2 Likes
Let’s mark that as the solution…
But it is not what was asked for.
It’s a workaround.
In my ideal world a user should not achieve the goal in 2 steps.
Consider one (or several) yaml files related to some equipment.
You took these files to some HA setup - reloaded yaml (made HA reboot if needed) - and the setup got the desired functionality w/o any additional tunings here & there in UI…
Currently it may be achieved only by “homeassistant::customize” to define friendly_name.
2 Likes
But that has been posted over and over.
I’ve asked for this fr to be closed ages ago, but it wasn’t, and hence people keep getting back to this.
There really is no issue at all, other than the legacy friendly_name being called name: in the template: syntax.
And yes unique_ids have been around for both since very long too, so people without that in the legacy syntax should fix that instead of worrying about the wrong issue…
Yes let’s close this one.
Best way to close things is to flag them and then a mod can close it.
I flagged 113 above, just flag that one too. They had the answer but didn’t like it.