Add (bring back) friendly_name to template sensors

Feature Requests
101

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.

102

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.

103

This does not work.

image
image973×119 4.99 KB

      - name: sun_state
        state: ok
        attributes:
          friendly_name: "My Sun State"

image
image863×138 8.83 KB

104

did you reload the templates? I’ve been using it for a couple of years…

105

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.

106

It used to work… Hmmm.

107

May be some time ago HA allowed to create attributes with same names as “standard” ones…

108

This is what’s going on.
Template sensor: how to set a friendly name with a non-legacy syntax? - #31 by CentralCommand.

109

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.

110

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.

111

It needs 2 steps:
Create:

template:
  - sensor:
      - name: desired_entity_id
        unique_id: desired_entity_id
        state: ok

image
image893×80 5.64 KB

Edit:

template:
  - sensor:
      - name: "The best sensor"
        unique_id: desired_entity_id
        state: ok

image
image891×77 5.52 KB

1 Like
112

Let’s mark that as the solution…

113

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.

1 Like
114

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…

115

Yes let’s close this one.

116

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.