Add (bring back) friendly_name to template sensors

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.

Mariusthvdb · February 8, 2024, 6:47pm

yep thats is what was posted many many posts above too

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.

Ricks88 · February 8, 2024, 7:19pm

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

Mariusthvdb · February 8, 2024, 7:20pm

no it wont. I said ‘after that’. So first create the entity with the unique_id, and then remove the name: option

Ricks88 · February 10, 2024, 7:04pm

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)

Sir_Goodenough · February 11, 2024, 2:51pm

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"