You are right that {{states|count}} will trigger on each state change. For this simple example that is obviously redundant but for a slightly more complex example:
{{ states | map(attribute="last_updated") | max }}
we can see that each state change indeed must be considered when state is accessed. Incidentally, it is jaw-dropping to put this example into the template developer tool and see it update in real-time!
If this is actually a performance issue, it might be possible to make a special optimization for {{states|count}} where only life-cycle events are considered. I am not quite sure whether that is possible (or even desired), @bdraco could probably answer that. A workaround is to put the template into an input_number and update it manually as desired.
If you want to drive updates manually, automations are able to do that with much more flexibility than the templates were ever able to do. For example, your hour_icon value template seems to only need changes every hour and you can do that with a time_pattern which would make it 60x more efficient!
Please note, I am not saying that the current implementation is perfect. We will probably have to tweak it for a few releases. But the concerns I have seen are about things that can still be done so I think this will turn out fine once we get comfortable with the new ways
thanks for replying. I admire the hugeness of the 115 update. And thank everyone for that. Its just that the deprecation of this entity_id in templates seems to have been rushed in, and not all consequences are thought out carefully enough.
I am not sure what youāre saying here is acknowledging the issues introduced by deprecating entity_id:
I do understand for a majority of template sensors, this is very nice to see happening, dynamic and constant updating of relevant entity_idās even when not explicitly mentioned in the template.
However, suggesting even more convoluted solutions like creating timed automations for updating input_numbers or other domains which hold the current state of those templates is quite baffling tbh.
Especially since we had a perfect trigger/limiter for those updates!
Wouldnāt it be a viable scenario that the new way of evaluating the templates simply co-exist with the functionality of entity_id:
That way, we would have it all:
Automatic and dynamic template evaluation for entities in the templates
option for a global entity to be valid for the complete template sensor that limits updating to changes of that global entity (or entities in a list)
I donāt want to update manually, I simply donāt want to update on all state changes, which, now they are found automatically, drastically increase in numberā¦
(btw my hour icon needs updating every minute, hence the sensor.time)
In fairness to the changes, all of my concerns were because I didnāt realise how far reaching the changes went. Iāve removed entity_id from all of mine and patiently waited to see which broke and not a single one did
Itās no secret that your configuration is particularly complicated, which of course is your perogative, but I suspect if you went through all of your templates you can probably define a lot of them in different ways that work more effectively and wouldnāt require any workarounds, then the few that are left may just need the ācheatā defined above.
The downside for you, with which I sympathise, is that because your setup is complicated, going through it to achieve this is probably a lot of work.
well yeah, I am writing a few automations to get the next_alarm sensor up to speed with the new entity_id issueā¦ so Im am conforming. no worries.
the counter template sensor above was not mine tbh, (I use a python script to do the works) but was posted because quite a few members here use that. If so, it is to be expected that they all see a rise in processor spikes.
What I am trying to say, is that I am not really speaking for myself, but for the community as a whole. Seeing the demise of a perfectly fine technique for limiting the updating of a sensor, and a global one at that (you must sympathize with that) feels just so unnecessary.
To be even more precise in describing my worries: it is not that I see these sensors break because they canāt find an entity_id any longer.
It is more of the opposite: I fear they will keep firing because they are constantly checking the state they are findingā¦
the few ones that need sensor.time are easily spotted and rewritten. Itās a more fundamental worry than thatā¦
in fact it could be compared to the move custom button-card made some time ago. From updating on all state changes, to entering the triggers_update: configuration option. Donāt use that, and have the system update on all state changes mentioned. Do use it and have update only on that particular (set of) entity_id(s).
Best of both worlds. Would be great to have I core templates tooā¦
We might be able put together an optimization for {{states|count}} , Iāll take a look later today.
Iāve helped a few people convert their templates, and by far the most common cases donāt actually need to iterate all states which is the better solution.
Iāve seen a lot of these
states | selectattr('entity_id', 'in', state_attr('group.family','entity_id'))
to understand fully: does this in fact change the burden on the backend, or is it simply simpler in the yaml config.
iow, does it limit the states checked for the evaluation of the template value?
it listens to all state changes. Which isnāt necessary at allā¦
which is where my worry kicks in: deprecating the option of the entity_id: sensor.time is very expensive.
In 0.115 it appears to be slightly more inclusive than that.
In the first example, a listener is also created for group.my_lights.
In the second example, listeners are also created for all light entities.
My only purpose in mentioning this is to clarify its behavior, especially for people like me who still remember how its behavior was originally described.
To exercise the new handling of expand, I carried out a simple experiment consisting of nested groups:
An added bonus is that I can add/subtract a light from a group, execute Reload Groups, and the listeners are automatically revised. This fulfills my old Feature Request:
Sweet. If this particular entity counting template is popular, we might even provide an integration for that rather than have everyone build it with templates.
Please note that I am giving these workarounds as a way for you to get things back to working now. I am not necessarily saying that this is the preferred way for the long term.
However, I donāt think this has been rushed. At one point we have to get it out there and collect feedback, we cannot wait for it to be perfect because then it never will be. I do understand where you are coming from. It is a big change that takes some getting used to and at first it can appear strange. And of course, fixing up a big configuration is always a drag.
You mention fear and worry. We should not let that drive development, that is called premature optimization. I think it is better to identify real issues and then we will think of solutions to those.
cool. heavily into checking the config, which is not so very nasty to do, given the new possibilities galore ! font get me wrong, I am very excited
please let me ask one specific config question:
value_template: >
{% set ns = namespace(total = 0) %}
{% for state in states.sensor if '_actueel' in state.object_id %}
{% set ns.total = ns.total + (state.state|int) %}
{% endfor %}
{{ns.total}}
can be written using the expand(group) function now to? thereās a group.energy_actueel which could be usedā¦ adding the values of all these sensors ?
- alias: Create actueel group
trigger:
platform: homeassistant
event: start
action:
service: group.set
data_template:
object_id: sensors_actueel
entities: >-
{%- for s in states.sensor
if ('_actueel' in s.entity_id )%}
{{s.entity_id}}{% if not loop.last %}, {% endif %}
{%- endfor %}
beats writing the group verbosely.
Now only need to think of a way to get this restored. Or will the sensor be restored, even though the group is created at startupā¦ ?
Iāve got a branch that will significantly reduce the number of re-renders when we are only counting states and not actually looking at what is in the state that builds on https://github.com/home-assistant/core/pull/40250
Thank you!
