as title,
it would be really nice if we could do that:
please see:
allow for:
binary_sensor.low_lux_input:
friendly_name_template: >
Low lux input - {{ states('input_number.low_lux') }}
binary_sensor.high_lux_input:
friendly_name_template: >
High lux input - {{ states('input_number.high_lux') }}
binary_sensor.home_theater_lux_input:
friendly_name_template: >
Home theater lux input - {{ states('input_number.home_theater_lux') }}
cover.template (https://www.home-assistant.io/components/cover.template/) also needs a friendly_name_template as well. +1 for normalisation between all sensor templates.
I found two posts both by @jms3000, he has written the code to do this I just figure it needs someone to cast their eye over it, see it doesn’t break any rules and merge it in.
and
Basically, I think ALL standard entities should have friendly_name_template 's
I would most certainly welcome that indeed. Not sure if @jms3000 still has his code lying around to create a PR?
I’d like to extend this feature request:
ALL attributes should be parsed for templates.
To maintain backward compatibility, attributes named “xxxxxx” and “xxxxxx_template” are equivalent and should not be used together. Eventually this can be deprecated in favour of phasing out the “_template”.
TL;DR There should be no distinction between template and non-template attributes.
quite. like it is on the custom: button-card after some development 
just have a look at the icon, which needs to be icon_template for the template sensor. Forcing us to use a fake icon_template, or even setting the icon in customize.
A fine illustration of what the future for attributes should be, not matter the name. ‘Simply’ use or not use a template, and forget about the configuration variables names ending in _template or not.
How nice that would be.
Now, about volunteering to write the PR’s…?
I wonder if it’s as simple as “if attribute.Name.EndsWith(’_template’) then parse template” 
Probably not, eh?
Edit: I mean, I wonder if that’s what the Home Assistant code looks like right now.
no, fear not. The whole idea would be not to have to end it with the suffix_template:
this would be the idea:
friendly_name: >
Low lux input - {{ states('input_number.low_lux') }}
or
icon: >
{% if is_state('binary_sensor.lightning_active','on') %} mdi:flash-outline
{% else %} mdi:flash-off
{% endif %}
in fact, the distinction for all _template entities would become superfluous, a (current) template sensor would simply be a sensor using templates in 1 of its configuration variables fields…
That’s exactly what I would love to see. The forum is riddled with people wondering why their templates don’t work only to find that they used data: instead of data_template:.
that would be another big step indeed, no more need to make a distinction for data: and data_template in scripts, automations etc etc.
this could be a fine discussion for the architecture section on HA.
Can you imagine the potential possibilities if your sensors could dynamically be updated with templated values instead of just raw data.
My code is here:
I like the train of thought in this topic but I wonder how difficult it would be to implement. Especially when considered in light of how it works now: even a small modification to an entity (change its device_class) requires restarting the entire application. That kind of architecture implies there may be some aspects of an entity’s definition that might be challenging to make dynamic (via templates).
Nevertheless, it’s a worthwhile goal because, I agree, the current state of what can and cannot be templated is not readily self-evident. It should be comprehensive and transparent.
The sensors are defined in configuration.yaml at system start time. Even if you use a template, the sensor is defined only once. Hence this is not dynamic. You can’t reconfigure the sensor.
There’s no debating the fact that you’ve described the status quo (entities are created at startup and remain fairly static thereafter). I believe the discussion is about altering it.
Sorry Marius (I may have missed something) but should this not be : -
friendly_name: 'Low lux input'
as a present and valid usage but given your proposal extend that to also include : -
friendly_name: >
{{ 'Low lux input - ' ~ states('input_number.low_lux') }}
As I say, I may have missed something but you would have to give the interpreter a decent whack at distigushing the difference in the absence of the “_template” bit ???
Thanks for posting this Martin, nice to see that your code may ‘yet’ make a difference
though this FR has grown somewhat into a more general discussion about the need for a distinction between regular sensor and template sensor…,
you are right, my proposal would be to include the friendly_name_template for binary_sensors.
Not really sure what you mean with your final sentence, because as it stands, I was simply proposing to add friendly_name_template: to the binary sensor.
If and when this would develop, it wouldn’t matter any more, and we would be allowed to simply write a template after the variable friendly_name:
to the format of the template itself: both would fit the bill, just as we can write service_templates or other templates in different ways to reach the same goal:
service_template: >
script.turn_{{'on' if states('sensor.example') == 'on' else 'off'}}
or
service_template: >
{% if states('sensor.example') == 'on' %} script.turn_on
{% else %} script.turn_off
{% endif % }}
or
service_template: >
script.{{'turn_on' if is_state('sensor.example','on') else 'turn_off'}}
or
service_template: >
script.turn_{{states('sensor.example')}}
or…
Marius, you are correct and have provided some excellent examples.
I am considering Steve’s suggestion that any entity attribute - should be template able (if that’s even a word) and without the _template suffix.
But, without taking anything away from your proposal, when we use those examples you gave, the interpreter ‘knows’ a template is coming because we tell it so, with the “_template” at the end of the item listing.
The ‘normal’ way has just a text string and this loads a static piece of text into memory for that entity attribute.
When it is a template it has do do something different, it observes entities within the template that will have to be monitored and it loads the template that will have to be evaluated (a completely different method)
I merely suggest (because I like the proposal endorsed by yourself and extended by Steve) that we should be able to use a template anywhere (that does not affect the entity_id or its place in the ecosystem) but the interpreter will need to know the difference. And I would suggest the best way to do that is to ‘ensure’ that we give it a clue by using a full jinja interpretable expression.
I would not be coding this, it would probably need several different coders if this is spread across different entity types, they need to implement this in a consistent manner and I am merely ‘suggesting’ a method.
Actual implementation is going to be upto a committee of a select few (if it happens at all) and I’m trying to plan ahead.
The general proposal (in its current form) is the child of yours but also of Steve for the extension and it is simply a brilliant and (in hindsight) obvious step for HA to make.
Thank you both for your time and efforts
well, I seem to be missing the point of your extensive post, other than that we would agree on the fact that we hope/feel that all entity attributes should be templatable, and that we shouldn’t need the suffix _template to tell the interpreter, but that the underlying code would recognize a template automatically.
But, that was summarized already before your post
and, as I hope my previous post would illustrate, a full interpretable template is anything in valid Jinja between {{ }}. That doesn’t need to be the full resulting string, but can be just a small part of it. As long as it follows Jinja definitions.
I would even think icon_template: mdi:homeassistant would pass, and, as a matter of fact, have seen people use that in the template sensor