Trying to use the ‘modern’ method for template sensors.
How do I get a sensor name without ‘template_’ stuck on the front … and get a nice friendly name for the entity to show on a card.
I’ve tried
template:
- sensor:
- unique_id: unique_id_10
name: 'name 10'
attributes:
friendly_name: 'friendly name 10'
state: >
unique, name and friendly name
Which
1) ignores the friendly name I defined and sets the attribute to 'name 10'
2) a card shows entity with a name of 'name 10'
3) and entity_id of 'sensor.name_10'
Whereas
- unique_id: unique_id_20
attributes:
friendly_name: 'friendly name 20'
state: >
unique and friendly name
Correctly gives the entity its friendly name on a card
But the entity_id is 'sensor.template_unique_id_20'
The name becomes the sluggified entity_id and unique_id is for editing via the UI (as per the docs). If you don’t specify name you get a made-up one. There’s no friendly_name option for these sensors. You need to customise it.
@parautenbach , Clearly there is a ‘friendly_name’ option for these sensors as it works - as described in my second example. And whilst not explicitly listing ‘friendly_name’, the ability to add attributes to these sensors is in the docs.
As you say customise does seem the only, inelegant way, to achieve what should be allowed, imho, in the yaml definition of a sensor.
Works in what way? Yes, you can add it, but the attributes section is just a generic (custom) dictionary of things. friendly_name has no special meaning here and it won’t be used automatically by anything. You can use it though for your own purposes.
If it was an option, it would be documented like this:
But to give my opinion: Friendly name is display purposes, and I’m in favour of splitting implementation from presentation, which is generally considered a best practice.
You might think it has no special meaning but the entities card likes it enough to replace the entity’s default name with the friendly_name I defined. lol
You can name it for display purposes in the entities card. Pretty much every card allows you to override the given name.
If you provide a name and a unique_id, the system will create the entity_id off the name. Then change the name to what you want in yaml and reload the template, the entity_id will remain the same, while the name will have an updated name.
The upshot is that you can’t define a desired object_id (like name_10) and desired friendly_name (that differs from the object_id, like friendly name 10) in one step; the process requires two steps.
Or…just use the “old” template format and continue on as before when it worked as expected.
I dislike that we keep moving down the road to needing to make additional sensors or write more code to override decisions like these that make less sense than the original implementation.
as an example from the latest release:
I now need to create another sensor to be able to display an input_datetime in any semblance of a useful manner when the original display looked pretty close to the way the sensor I needed to make to fix it does now.
How can anyone think that input_datetime display format is OK? I mean, you can’t even see the entire year (which I think is important for a date entity) let alone the name of the thing you want to see.
The controls start to look bad around 400 pixels or smaller in width. Are you zoomed in on your browser? Is your mobile device really old and is smaller than 400 pixels wide?
