Add (bring back) friendly_name to template sensors

Feature Requests
41

They work perfectly in anything that supports templates.

Recorder doesn’t support templating and only provides a simplistic wild-card text-matching technique. However, that never stopped me from explicitly indicating each entity to be excluded.

Nevertheless, feel free to continue creating entities whose names are loaded with metadata.

42

I’m just starting to get familiar with the new template format and find myself struggling with similar problems as described above. To me, the legacy format has a few strengths which makes me hesitant to migrate over to the new format before the issue of being able to separately define the name, unique_id and friendly_name completely independently from each other has been resolved.

Is there a plan for when the legacy format will be abandoned?

Cheers, Per

43

REALY? I have to create something in the configuration.yaml and then switch to the UI and adjust it there afterwards (again)??

As Per mentoined, I will stay at the legacy format where I can setup those figures on one place.

44

4 posts were split to a new topic: Need help with Rest sensor name

45

So if I want to convert existing legacy template sensors to the new format and retain:

  • the original sensor name (without the added template_ )
  • the equivalent of friendly_name

Is there something easier than:

  1. Convert to the new format
template:
  - sensor:
      - unique_id: legacy_sensor_name
        name: Legacy Sensor Friendly Name
        state: >
          {{ states('sensor.example')}}

  1. Reload/restart Home Assistant

    (i need to test it again, but I think the existing entity names didn’t change during a template reload. I got bit with the name change when I did an upgrade/restart a couple of weeks later going from 2021.12.x → 2022.2.9)

  2. Use the UI to change sensor.template_legacy_sensor_name back to sensor.legacy_sensor_name?

Note: when I do rename through the UI, it does seem that the history under the old entity_id stored in recorder becomes available again, so glad that works.

Thanks

1 Like
46

make sure legacy doesn’t exist when doing this

template:
  - sensor:
      - unique_id: legacy_sensor_name
        name: Legacy Sensor Name
        state: >
          {{ states('sensor.example')}}
        attributes:
          friendly_name: Legacy Sensor Friendly Name
47

FWIW, all I did was add this

template:
  - sensor:
      - unique_id: legacy_sensor_name
        name: Legacy Sensor Name
        state: >
          {{ states('sensor.example')}}

and delete the legacy system and restart and everything was back up and running. However all my names are controlled in customize.yaml

48

Thanks for the fast reply.

So are you saying that if sensor.legacy_sensor_name doesn’t exist, the new template sensor defined with unique_id won’t have template_ prefixed?

Can making the old entity_id go away be done without a restart?

In any case, I want to retain the history in both recorder and downstream InfluxDB.

49

but it does exist in legacy format.

You do it all in 1 sweep.

Keep HA running: Delete old, add new, restart HA.

Not: delete old, restart, add new, restart.

50

My experience was that when I converted the entry to the new format, along with commenting out the old definition, upon reload the entity did not get renamed. Several weeks later when upgrading to 2022.2.9 and doing a restart, I got bitten by the rename.

So I did

  1. Change the YAML to remove the old, add the new
  2. Reload template
  3. verified it was working.

The entity name didn’t change as far as I could tell. IAll was fine until I restarted/upgraded to 2022.2.9. I haven’t tried to test that again.

51

i’ve a lot of issues using both unique_id and name or both unique_id and attributes:friendly_name
if i use unique_id and name : unique_id is ignored
if i use unique_id and attributes/friendly_name : friendly_name is ignored
I have to manualy change values in UI.
Better use customize until a workaround !

52

there wont be any changes to this functionality. This FR is effectively closed unless all aspects of the naming process are changed.

53

Just ran across this trying to work around a different issue with zwave stuff getting a status sensor back the way I had it.

Is there some “trick” to making it work?

I like my entity IDs to be much more verbose than the short name it shows on the Lovelace dashboard…and it seems to be no way to have that anymore.

For example:
- name: “Inside Garage Door Lock”
unique_id: deadbolt_inside_garage_door_status

If i have it display the full name, it gets ugly and mushed because its SO long on the dashboard. But I want it to be named similarly to the actual lock entity so its easier for debugging and code management to tell it matches the deadbolt lock, and to tell its status (not alarm, not control).

Or is there a way to have “trigger template” sensors that use the “old” format?

54

I’m not happy with the current solution as well. For all template, I did not use friendly_name the move to the new template platform was easy and ok.
But if I need friendly_name, I have to use the unique_id. And then the prefix “template_” will be added to the ID which makes moving all other template sensors, swiches and binary_sensors difficult becaue I have to either change the automations, scripts and dashboards or I have to modify the unique_id in HA. Is it at least possible, to make the prefix optional?

55

you can simply delete that, provided you have a unique_id set. That’s the great thing about this new format. Instant edit is possible on all fields in the UI.

56

How exactly does one “simply delete that”? Its not in the yaml to delete?

Surely this doesn’t mean having to hand edit EVERY sensor you want to name this way thru the UI manually?

I have in some cases hundreds of template sensors, many of which I generated using scripts to craft YAML based on combinations of inputs…I can trivially tweak to the new syntax but having to hand-edit everything to make names work the same way when something is added or removed is insane.

57

Sorry meant ‘edit’

And yeah, ui is for ‘straightforward’ config, yaml for advanced, also called ‘old style’, see the new platform: group helpers in Ui

Even so, you can still create them with your 1 time script, and make those edits if you need.

Advantage of the Ui is you can keep doing that with immediate effect, no more reload needed.

58

I have 123 template entities in my HA right now. I have never once made one that showed up with template_ as a prefix in either its entity ID or friendly name. If you’re seeing that it must be in your config, it doesn’t do that automatically.

59

I’ve just set up a brand new template sensor and for the life of me I cannot prevent the template_ prefix from appearing. I’ve tried every combination of what’s suggested above.

60

That happens when you only provide a unique_id and omit the name and it’s a new entity that isn’t in the entity registry.

1 Like