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?
