Add (bring back) friendly_name to template sensors

[Mariusthvdb (Marius)]

yes, thats a bit funny.

But, that (adding prefix template_ to the entity_id) only happens when. you don’t set a name in the config.

If you do, and use identical unique_id and name, creation is perfect. (entity_id == unique_id)

If you set another name than unique_id, entity_id is set to name, and you have to manually edit the entity_id in UI (to have it be exactly like unique_id).

this is still somewhat clumsy, but in the end , it is a onetime effort. And most of all, the template can be used for name: …

o well. I am fine either way, but for me this is no longer necessary.

[Alex9779 (Alexander Leisentritt)]

Well I am still irritated about how this should work.
I changed my whole template config now to the new format, I set a unique_id and a name resulting in an entity_id made from the name, then I changed the entity_id with the GUI.
Reading the docs also is strange to me, all required there is “state” but then I get an “unnamed sensor”, how am I supposed to find it then? And I can’t do anything with it because it has no unique_id.
Shouldn’t be name or unique_id be required?
And why am I forced to change the entity_id with the GUI and am not able to set this all in the YAML config?
Why isn’t just the unique_id used for entity_id too if given?
IMHO name should be also required, with a name a unique_id could be created maybe like the docs says with “template_” prefix and the entity_id is then made form the name too.

[ccpk1 (Chad)]

With the updates in 2021.8.2, it’s great that I can now consolidate my modern templates into the same packages file with all of the other related components for good organization. That said, the ability to define a specific entity_id, and at the same time within the template specify a different unique friendly name, is still not possible. So I do agree this FR is still a open, but guessing it won’t likely get a lot of attention since the simple workaround is just to add any friendly names you want to specify within your customize section as a one off effort.

[Mariusthvdb (Marius)]

You can set a name different from your unique_id.

Not sure what your issue really is?

[ccpk1 (Chad)]

Thank you for pointing that out. I just made a correction to my post where I said unique_id when I meant to say entity_id. In my case, I’m using a naming pattern in my entity_id’s in order to filter and process my sensors. So can name the templates to get the desired entity_id, but then I’m not able to specify a friendly_name that will look nice in the reporting and dashboards without doing a customization or manually editing the entities.

[123 (Taras)]

@ccpk1

I’m using a naming pattern in my entity_id’s in order to filter and process my sensors

Use custom attributes for that purpose. It makes it much easier to filter entities and eliminates long-winded entity names packed with metadata.

Recommended ways to manage devices and entities names

I’m not an advocate of using an entity’s name to store metadata. In other words, I don’t recommend creating an entity name packed with its characteristics. sensor.manufacturer_model_identifier_color_size_location_bla_bla_etc When the time comes to select entities based on their characteristics, the resulting template can become quite messy. What I suggest is to add metadata as custom attributes to an entity. Simple add them to customize.yaml or via Configuration > Customizations. For example…

[Mariusthvdb (Marius)]

@ccpk1

So can name the templates to get the desired entity_id, but then I’m not able to specify a friendly_name

well, you can. once the entities have a unique_id, you can set any entity_id you like in the ui of the entity. I set my entities to have the same object_id and unique_id, and some of those have another (more friendly) name. Or even use a template for name. Anything is possible really.

just an example:

      - unique_id: dark_sky_forecast_1
        name: >
          {{as_timestamp(now() + timedelta(days=1))|timestamp_custom('%a %-d %b')}}: {{
            states('sensor.dark_sky_forecast_icon_1d').replace('-',' ')|capitalize}}
        state: >
          {{- states('sensor.dark_sky_forecast_daytime_high_temperature_1d')|round(0)}}°/
          {{- states('sensor.dark_sky_forecast_overnight_low_temperature_1d')|round(0)}}°/
          {{- states('sensor.dark_sky_forecast_precip_probability_1d')|round(0)}}%
        picture: >
          {{'/local/weather/icons/' ~ states('sensor.dark_sky_forecast_icon_1d') ~ '.png'}}

[ccpk1 (Chad)]

In concept, this is what I would like to do, but I experimented quite a bit with this approach and unfortunately I got stuck because there are still too many of the integrations and cards that only don’t allow efficient use of custom attributes. As an example, just look at the Recorder which is one of the fundamental components of Home Assistant and it only allows filtering by using the entity_id name.

[ccpk1 (Chad)]

If I’m understanding correctly, the first time this entity is created, you manually go in via the ui and edit the entity_id. Once you do that, the entity_id will remain unchanged, but the “Friendly Name” can continue to be changed as needed? Thanks

[paddy0174 (Patrick)]

Yepp, that’s exactly the way (as described from @Mariusthvdb).

[123 (Taras)]

@ccpk1

I got stuck because there are still too many of the integrations and cards that only don’t allow efficient use of custom attributes

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.

[per.takman]

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

[Senbei (Tristan's Smartes Heim)]

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.

[rct]

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')}}

2. 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)

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

[petro]

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

[petro]

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

[rct]

@petro

make sure legacy doesn’t exist when doing this

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.

[petro]

@rct

So are you using if sensor.legacy_sensor_name doesn’t exist, it won’t be called

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.

[rct]

@petro

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

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.

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.