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.
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 ???
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'}}
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
I tend to use _template everywhere, whether I have a template in mind or not, just in case I end up wanting to use a template later. It doesnât seem to hurt anything, so why not make templates the default everywhere?
It is starting to bug me that we only have 15 votes for something that would help âeveryoneâ whereas (looking at the list of feature requests) we have 21 votes for âNokia Health Productsâ (that would probably help ⌠what ? ⌠21 people ???)
getting back to this.
Comparing the binary_sensor file and the sensor for the template sensor integration would suggest that adding the small bits for friendly_name_template is rather straightforward.
Id be very willing t create that PR, but before I do so, would request some confirmation that would be all required. I donât have a working test setup/dev-environment and my latest PRâs have only been merged because of some serious assistance from the devâs. Donât want to bother them yet again with my incompetenceâŚ
please have a look if you would, to see if comparing these files would suffice.
Donât be so hard on yourself. Unless someone does this for a living, setting up a development environment and then complying with the requirements of a submission and vetting process is quite foreign to the average home automation hobbyist. Donât hesitate to ask for the developersâ help. Itâs in their interest to get you up to speed so that you can be in a position to help others (and so on and so on).
I added my support on github
Sorry if I âsort ofâ went for a harmonisation across many platforms (it is a bit irritating that you can only do âx functionâ under âthat platformâ and then you have to try to remember which is which and why). So I then re-inforced the template binary sensor option.
no you are right of course, that s why I repeated that in the architecture discussion. Still why not begin with the TBS and maybe some development on that will follow suit.
I truly donât get it why the devâs sometimes want to keep the HA system so rigidly unattractive for a human and keep it so robotically digital. Especially when core already has comparable functionality available in other spots.
I have a sensor âat least one window is openâ. I would like to have its name set to âat least one window is openâ when at least one window is open, and âno window is openâ when all window is open. If it doable for a sensor, why not for a binary sensor?
