Add (bring back) friendly_name to template sensors

simply use the friendly_name: template directly under name:

      - unique_id: driveway_buiten_sensor_light_level
        state: >

        name: >
          Driveway buiten:
          {% set light_level = state_attr('sensor.driveway_buiten_sensor_light_level','lightlevel')|int %}
          {% if light_level < 1 %} dark
          {% elif light_level < 3000 %} bright moonlight
          {% elif light_level < 10000 %} night light
          {% elif light_level < 17000 %} dimmed light
          {% elif light_level < 22000 %} 'cosy' living room
          {% elif light_level < 25500 %} 'normal' non-task light
          {% elif light_level < 28500 %} working / reading
          {% elif light_level < 33000 %} inside daylight
          {% elif light_level < 40000 %} maximum to avoid glare
          {% elif light_level < 51000 %} clear daylight
          {% else %} direct sunlight
          {% endif %}
        device_class: illuminance

you shouldn’t (cant?) use both, name is the direct replacement for friendly_name

and, if its only for the frontend, you could always use template entity row

I’m subborn in my desire - I want a clean and static entity_id and a useful and dynamic friendly_name.

friendly_name may have been better titled display_name, because friendly_name leads to semantic confusion, ambiguity and misuse. a “friendly entity_id” is redundant to “entity_id” and I think this is the direction that has been taken

really I am not sure what you’re on about.
I have all my template sensors use a static entity_id (can configure those via the UI even) and yes you can have a dynamic name:

as I illustrated above.
Why not go with the new flow, instead of fight it (because it’s named differently). It’s all there. Use it.

So I admit I haven’t read through ALL of the comments, but it seems this is still an active discussion even over a year later. But I’m a little confused, because it seems this is already supported in Home Assistant. Unfortunatley, you can’t seem to specify the friendly_name directly on the template sensor, but it is possible to set the friendly name.


  customize: !include customize.yaml
  - sensor:
      name: contact_4_adj_temp
      unit_of_measurement: °F
      state: "{{ (states('sensor.contact_4_temp') | default(0, true) | float + 0.4)  | round(1, default=0) }}"
      device_class: temperature


  friendly_name: Contact 4 - Temp (Adjusted)

With this configuration, the entity contact_4_adj_temp will have Contact 4 - Temp (Adjusted) for it’s display name in the UI.

I tried using various combinations of unique_id: and name: and attributes: ⏎ friendly_name:. But the above is the only one that works reliably for me.

Using unique_id: + attributes: ⏎ friendly_name: works…but then it prepends the actual resulting entity_id with template_. You can then edit the entity to fix the name…however, I don’t know if it is persistent across reboots/reloads.

Using name: + attributes: ⏎ friendly_name: does not work, it just uses a snake-case version of name: for the friendly_name attribute.

Using unique_id: + name: kinda sorta works…but you have to use just unique_id first, save, reload template sensors…then add name.

1 Like

I would like to have the actual power consumption reading as part of the name for lights showed in the lovelace interface.
I’ve used the template editor under developer tools to check the code and there it works flawless. But I’m not able to make it work to adjust the name of mqtt light entities. I’ve used the following 2 template coding:
Option 1

Buitenlamp achter {{ iif ((states('sensor.vermogen_buitenlamp_achter')|int)>=1,' ('+states('sensor.vermogen_buitenlamp_achter')|string+'W)','') }}

Option 2

Buitenlamp achter{% if ((states('sensor.vermogen_buitenlamp_achter')|int)>0) %} ({{ states('sensor.vermogen_buitenlamp_achter')}}W)
{% endif %}

Depending on whether the power consumption exceeds the threshold value of 1W, both options render the same in the template editor, i.e.:

  1. Buitenlamp achter
  2. Buitenlamp achter (12.68W)

But it doesn’t work if I apply it as follows

    - unique_id: "Buitenlamp_achter"
      name: Buitenlamp achter {{ iif ((states('sensor.vermogen_buitenlamp_achter')|int)>=1,' ('+states('sensor.vermogen_buitenlamp_achter')|string+'W)','') }}
      payload_on: "on"
      payload_off: "off"
      qos: 1
      state_topic: "shellies/shelly1pm-buitenlamp/relay/0"
      command_topic: "shellies/shelly1pm-buitenlamp/relay/0/command"
      json_attributes_topic: "shellies/shelly1pm-buitenlamp/info"


name: "Buitenlamp achter {{ iif ((states('sensor.vermogen_buitenlamp_achter')|int)>=1,' ('+states('sensor.vermogen_buitenlamp_achter')|string+'W)','') }}"


name: >
Buitenlamp achter{% if ((states('sensor.vermogen_buitenlamp_achter')|int)>0) %} ({{ states('sensor.vermogen_buitenlamp_achter')}}W)
{% endif %}

All that the above leads to is that the displayed name becomes Buitenlamp achter {{ iif ((states('sensor.vermogen_buit…
How can I make it work?

this topic is about sensors by the template: integration. All of the options support templates.

However, you’re asking about an mqtt: sensor. Which does not support templates on the name:. So, its simply returning what you enter there.

You cant just invent functionality :wink:

also, your templates are a bit odd with the |string filter (all templates are strings, so what are you trying to do with that? ) and all. also, you need to add defaults to the |int, see Updating Templates with the new default values in 2021.10.x

It sound like the problem here is not a lack of friendly name, but an issue with the way “identities” are derived from each other.

It is possible to assign a completely dynamic name (name, previously friendly_name) to template sensors. The issue causing confusion is that by default the entity_id is derived from the name, instead of the specified unique_id.

This perception is supported by:

  • Descriptions/workaround using the UI to configure the entity_id after assigning a unique_id.
  • Lifetime stability: unique_id > entity_id > name (friendly name)

If the following process (psuedo-code) was used, I think all this confusion would go away:

unique_id := specified.unique_id if specified.unique_id is defined 
                  else guid()
entity_id := specified.entity_id if specified.entity_id is defined  
                  else "domain."+specified.unique_id if specified.unique_id is defined 
name := templated( if is defined
                  else entity_id
1 Like

It already does this…. The only part of your sudo code that isn’t applied is a auto generated guid if no unique id is provided. And that’s not possible because the guid would be different every startup.

So what am I missing here… My YAML code (not migrated from legacy template code) is:

  - sensor:
      - unique_id: lana_home
        name: Lana Home Detection
        state: >
          {% if (states('sensor.lana_mobile_wifi_connection') == 'somewifi') %}home{% else %}not_home{% endif %}

And yet, in the UI, the templated sensor shows up as “sensor.lana_home_detection”.
How can I give it the unique_id of “sensor.lana_home”?

that is not the unique_id, but the entity_id.
If that is what you want to change, just click the cogwheel and change it

since you configured a name in the yaml, it has taken that to use for the entity_id.

(what I always do is startup with a yaml configured name, so the entity_id is what I want it to be, and then comment the name in the yaml, since you can alter the name in the UI afterwards)

So how do I specify the entity_id in the yaml configuration without going one by one clicking multiple times in the UI?

thats been covered many times above:

  • either set a name: and have the new entity get the slugified name as object_id
  • or dont set a name: and have the new entity get the unique_id as object_id, prefixed by template_

after that, click anything in the UI to change to your liking (and, let me repeat, comment the name in yaml, so there is no double ledger on that if you would change the name in the UI)

Feels like its been a backwards step from what existed previously… Everything needs more clicking now…

So where is the cog? I check the sensor.entity_id after removing the unique_id but it says there’s no unique_id associated with the entity so I can’t modify anything…

that’s odd, since you clearly have set a unique_id

unless, you are clicking on the original entity, and not the newly made one. did you check dev tools states and look for lana_home? there might just be 2 of them now?

o wait, I see you removed it? never do that, its your way into the UI…

Ok, so put the unique_id back (I only commented it out) and then try? I’ll give that a go

If you actually set it to a UUID it becomes more obvious what’s going on here. It’s an internal reference and not something seen or used by the end user. Marius’ explanation is accurate. Here’s more info: This entity does not have a unique ID? - Home Assistant.

1 Like

What you still can do is use a workaround with customize: as follows:

  - sensor:
      - unique_id: lana_home
        name: lana_home
        state: >
          {% if (states('sensor.lana_mobile_wifi_connection') == 'somewifi') %}home{% else %}not_home{% endif %}

      friendly_name: Lana Home Detection

Like this you should get what looks as the legacy template sensor. Also entity_id and friendly_name are editable from UI.

Note: when you try it first time make sure that generated entity_id is indeed what you set in YAML (does not get duplicated) :wink:

In the end this indeed seems like a step backwards :pensive:

1 Like

What I do is giving it the name i would like my sensor to be:
‘name: I want this as my sensor name’
‘unique_id: I_want_this_as_my_sensor_name’

It creates the sensor as the name you like it to have. (sensor.I_want_this_as_my_sensor_name)

Than in the UI, change the name of the sensor (i will be the friendly name).
“This is the friendly name i want”

Now you have the (friendly) ‘name: This is the friendly name i want’ and the sensor name stays the same as the unique_id.

yep thats is what was posted many many posts above too :wink:

you can even take out the name: option from the yaml after that, as from now on you can edit the name in the UI.

Yes, but removing the name in yaml will give a sensor named sensor.template_xxx
Don’t like that haha :stuck_out_tongue:
With Name and ID it will label the sensor as a template integration only