Add (bring back) friendly_name to template sensors

Mariusthvdb · July 6, 2022, 8:36am

you can change object_id in the UI using the new template: syntax

markfrancisonly · July 18, 2022, 5:32pm

the template sensor doesn’t allow copy and past of the entity_id (step backward) and doesn’t allow dynamic display names. e.g. the folllowing doesn’t work

- sensor:
    - name: QQQ percent change today
      unique_id: qqq_percent_change_today
      unit_of_measurement: "%"
      state: >
        {{ "{:.2f}".format((state_attr('sensor.qqq', 'regularMarketPrice') | float(0) - state_attr('sensor.qqq', 'previousClose') | float(0)) / state_attr('sensor.qqq', 'previousClose') | float(0)  * 100) }}
      availability: "{{state_attr('sensor.qqq', 'regularMarketPrice') != none and state_attr('sensor.qqq', 'previousClose') != none}}"
      attributes: { "friendly_name": "{{ 'QQQ ' + '{:.2f}'.format(state_attr('sensor.qqq', 'regularMarketPrice') | float(0)) }}" }

Mariusthvdb · July 18, 2022, 8:51pm

simply use the friendly_name: template directly under name:

      - unique_id: driveway_buiten_sensor_light_level
        state: >
          {{state_attr('sensor.driveway_buiten_sensor_illuminance','light_level')}}

        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

markfrancisonly · July 19, 2022, 11:52am

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

Mariusthvdb · July 19, 2022, 12:23pm

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.

chadbaldwin · September 10, 2022, 7:22pm

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.

configuration.yaml

homeassistant:
  customize: !include customize.yaml
template:
  - 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

customize.yaml

sensor.contact_4_adj_temp:
  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.

Vliegeraar · October 24, 2022, 9:31am

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.:

Buitenlamp achter
Buitenlamp achter (12.68W)

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

mqtt:
  light:
    - 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"

or

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

or

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?

Mariusthvdb · October 24, 2022, 9:55am

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

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

slogen · January 2, 2023, 9:52am

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 
                  else specified.name
name := templated(specified.name) if specified.name is defined
                  else entity_id

petro · January 2, 2023, 5:31pm

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.

alexismadd · June 28, 2023, 7:23am

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

template:
  - 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”?

Mariusthvdb · June 28, 2023, 7:59am

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)

alexismadd · June 28, 2023, 8:15am

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

Mariusthvdb · June 28, 2023, 8:19am

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)

alexismadd · June 28, 2023, 8:20am

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…

Mariusthvdb · June 28, 2023, 8:46am

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…

alexismadd · June 28, 2023, 9:32pm

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

parautenbach · June 29, 2023, 4:50am

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.

farrad · October 15, 2023, 7:48pm

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

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

homeassistant:
  customize:
    sensor.lana_home:
      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)

In the end this indeed seems like a step backwards

Ricks88 · February 8, 2024, 5:28pm

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.