Fact is that using a python_script to produce an ‘unavailability’ sensor has always been possible. However, it wasn’t needed because it was achievable with a Template Sensor.
Suggestions to now use a python_script, instead of a Template Sensor, implies the Template integration has lost functionality it use to have when entity_id was available.
Whereas an ‘unavailability’ sensor was previously achievable, in an efficient manner, simply by adding entity_id: sensor.time, now the equivalent efficiency is via a python_script.
It appears we have gained functionality on one front (superior automatic entity identification) but lost on another (inability to control entity identification).
I have a bunch of counter templates to track # of different types of devices. They used to use entity_id to limit the update to minutely.
Now with the changes in 115 I believe they are done on every state change. For what it’s worth for simply counters by removing the “list” that I see being used quite often you get a 10x speed improvement on the time it takes to execute these.
{% set a = as_timestamp(now()) %}
{{ states.sensor | length }}
{{ states.zwave | length }}
Time: {{ as_timestamp(now())-a }}
The below run 10x slower due to the list; which doesn’t change the results.
{% set a = as_timestamp(now()) %}
{{ states.sensor | list | length }}
{{ states.zwave | list | length }}
Time: {{ as_timestamp(now())-a }}
My point is I think a lot of people have templated a lot of things and blazingly copy/pasted samples from this forum which perhaps are not the most optimal or best performing ways to accomplish certain tasks.
It pays to use the template editor to test results, test what it is intercepting, and using some simple way to benchmark the time it takes.
Perhaps we need some way to indicate to users they have such ineffective templates… A template optimizer so to speak
And/or possibly the fact that these templates are so popular means that they should be exposed as ‘normal’ sensors by the core without the need for templates, python scripts or whatever.
Although I agree there are sub-optimal ways of composing templates, the inclusion of list in your example never mattered in previous releases.
Why? Because your template wasn’t evaluated as frequently as it is now.
Previously, your template was evaluated every minute, so whatever ‘extra time’ involved to process list was hardly noticeable.
Now your template is evaluated every time any sensor or zwave device changes state. That’s far more evaluations so the aggregate of the ‘extra time’ becomes noticeable.
I believe the deprecation of entity_id has had far greater implications than originally anticipated. My first post suggests it’s simply a matter of including sensor.time in the template. However, in practice, there’s more to consider if the template relies on wholesale inclusions of all domains (i.e. using states or its derivatives).
I still believe all of this new complexity would be eliminated by the re-instatement of entity_id.
though I fully agree with you here, and would applaud the re-entry of the ‘control-to-the-user’ option. Thats what home automation is all about, control to the user. I believe that even is in the tag lines of Home Assistant somewhere…
We did get the hyper intelligence of the new template engine, which feels/seems great at first sight. No more need to specify which entities update the template. It simply finds these automagically, and keeps updating at each tick.
The cost is a 50% increase in processor usage …
As I have been deleting and rewriting a few heavy templates, I think I have reached the limit of optimizing options. Not a single {{states| xxx}} ,no counters at all and 2 custom integrations less, the system is still very heavy handed.
Hopefully the merged PR we can await in 116 will help. But yeah, please bring back entity_id as a limiter, update_trigger.
And some detective work… For example, what on earth is this telling me?
No need to answer unless you know exactly what the answer is. I’m not trying to branch this thread off on a tangent (I haven’t finished, ahem, ‘optimizing’ my system yet, so it is possible this error will just disappear at some point because it was a result of something else).
forgot to mention I also trashed the older AD3 add-on (thanks @Burningstone for updating my script) and set the recorder commit_interval to update half as frequently
commit_interval: 2
still, this all didn’t cause any further improvement. Much leaner, yet much slower and more expensive. But maybe there’s more to it than only templates. Should probably post this in the main 115 thread.
Food for thought:
If the superior automatic entity identification technique was introduced without deprecating entity_id, this ever-growing thread wouldn’t even exist.
Template Sensors employing entity_id would continue to work as in the past and users wouldn’t be obligated to change them. Whatever new Template Sensors a user created could be written using the new and improved functionality (such as the superior way the expand function is now handled).
One seemingly innocuous deprecation has had an outsized impact to the extent it almost overshadows the greatly appreciated improvements to automatic entity identification.
If those six media_players you listed represent all of the players you have (or even most of the players) then using states.media_player is probably fine.
On the other hand, if you have many more media_players or your template requires looking only at those six players, then you should not use states.media_player. In this case, I suggest you create a group containing the six media_players. Then change your value_template to:
{{ expand('group.my_six_players') | selectattr('attributes.last_called','eq',True) | map(attribute='entity_id') | first }}
{% set t = states('sensor.time') %}
{% set nw = as_timestamp(now()) %}
{% set ss = as_timestamp(states('sensor.astral_sunset')) %}
{{'- ' if nw < ss}}{{(nw - ss)|abs|timestamp_custom('%H:%M:%S',false)}}
{% set nw = as_timestamp(as_local(states.sensor.time.last_changed)) %}
{% set ss = as_timestamp(states('sensor.astral_sunset')) %}
{{'- ' if nw < ss}}{{(nw - ss)|abs|timestamp_custom('%H:%M:%S',false)}}
top template changes on every hit on the enter Key in template editor, while the bottom one, with the new local() version for now() doesnt, and only changes on the minute change, no matter what…
is this expected? Seems this is the contrary to what we discussed before. Using this new style Prevents updating…
No, I don’t think that’s the case, in fact one of the things I seem to recall bdraco saying (up thread somewhere) was that the old method and the new method will not be allowed to co-exist and that because this new method is foolproof at detecting the states to be monitored (it’s therefore preferred in the push for newbies) this is the one that will survive, though with perhaps a lot of ‘refinements’ to cater for ‘some’. of the outlier cases discussed (ad-infinitum).
