Check out the docs I linked in the middle of my last post. There are multiple utilities for visualizing the data
to be really honest, I had high hopes for this version, but cant say I see any significant improvement on the performance side of templates. Of course, I had taken out all ācompromisingā templates to get 115 up and running, or prevent it from grinding to a halt all together.
There is a thing with recorder, (which hopefully is already addressed by Balloob) which pumped up usage to a steady 28 percent form 4 am this morningā¦) but other than that, seems to be business as usual on the percentage .
Havent checked any new templating options either, so this is a report from a mere update only.
btw, all new options discussed above on rate and entity limiting and update frequency , have they not hit 116? Nothing in the docs on that? (sorry if my tired eyes miss the complete obviousā¦)
The new template engine is not inherently slower so if you already removed the problematic templates it is possible that your remaining performance problems are not from templates.
With 0.116, most problematic templates should be usable again because they are limited to update only once per minute.
Thatās right, only the automatic limiting of states and states.domain templates (1 update per minute) made it into 0.116.
1 Like
thanks.
can confirm that this:
{% set ns = namespace(domains=[]) %}
{% for d in states|groupby('domain') %}
{% set ns.domains = ns.domains + [d[0]] %}
{% endfor %}
{% set list = ns.domains|join('\n') %}
{{list if list|count < 255 else
list|replace('input','inp')|truncate(255,true)}}
now doesnāt kill the instance, as it did upon updating to 115. so that is great. Since this was the only one for me really (next to the counter, but they had already been replaced) I would be interested to exactly understand what was changed, and what we couldnāt do before and can do now again.
Is this something the dev team could describe in a clear comment (maybe also in the docs)? I mean, Id like to understand when a template is limited to only update once a minute, and when it listens to all state changes. And, if the user needs to set anything to have it behave either way.
not sure if I have remaining performance problems 
why would you say so? Iād say my large instance simply needs some processor powerā¦ 10/11 % average for now. Think the MQTT could be more efficient, but thatās another thread I suppose.
If I have understood the following explanation correctly:
it means it no longer listens to all entities when the template contains states or states.sensor (or other domains like light, switch, binary_sensor, etc). In 0.116, it evaluates the template once per minute. In other words, it behaves just like if you had used entity_id: sensor.time in pre-0.115 versions.
ah, but that would be a bit of a disappointing outcome of the whole discussion above, any template using {{states}} not updating in real timeā¦ ok, if it where only for counters, meaning templates not actually listening to the state of states, but there mere existence, those dont need tp be updated every state change. Not even very minute.
But templates that do listen to state changes (as in the on/off select_attr ) would need factual updating?
Where did this go astray?
itās a rate limit, when thatās released itāll update based on your configured rate limit.
Everyone here lead this astray. You essentially have a choice but you can only choose 1:
- update on every state change but itās a system hog
- do not hog the system, but the update rate is limited.
In every version prior to 0.115 it wasnāt updated in real time. states was assigned no listeners in the past. Thatās why we used to add entity_id: sensor.time to ensure the template was evaluated at least once a minute.
0.116 emulates the same behavior (update once a minute) without having to include sensor.time.
yes, but in doing so, it takes away what was the progress of 115ā¦
Again, the system is thinking for us, offering only the 2 default situations we can choose from. While each and everyone needs their own solution in their specific situation.
We really need the option to not update at all (like before 115), update continuously (like 115 gave us), or on regular frequency/demand, (not necessarily each minute). Without extra inputs, automations or what have we. Cut it short, thatās pre-115 plus automatic and continuous updating.
never blame the user base ā¦
It does not. What you donāt understand is you canāt have both. Itās one or the other. Optimized to not hog the system. Or allow everything to update.
Yes, but you seemed to gloss over the fact that you will be able to adjust the rate_limit like I said in the previous message. Itās not released yet.
You can when this thread directly affected the changes that occured. You literally complained about your system being hogged previously in this thread. He made changes to account for that and now youāre upset with them. Do you see how thatās frustrating from a developer standpoint?
1 Like
I really beg your pardon, but you are turning things upside down here. Iāve had a few big templates that had been working perfectly up to 115. All of a sudden the template engine changed without announcement and with these templates, that killed the system.
Iāve adapted meanwhile. So yes, I was ācomplainingā at that time. But the thing that seems to be not understood is that from a user perspective trying to keep up with fundamental system changes is not a very desirable situation.
Whats feeding that frustration, is that with all so called progress, very reliable techniques we had before are no longer available. Bam, gone.
Now howās that for frustration. Iām not the one to be very upfront about these emotions, so sorry if this comes across a bit strong. Itās not personal, not to anyone, and I most definitely appreciate everyones effort in making HA a great platform.
2 Likes
Ok then, downgrade and wait till all the features of templates are fully released.
It always did.
It has always examined the template to identify entities and assign listeners to them. Except it used to omit states and states.domain. Thatās why entity_id was available, as a means to mitigate the deficiencies of the automatic entity detection.
The new entity identification system is better to the point of being ātoo goodā. It assigns listeners to every entity represented by states. That results in a lot of template refreshing. 0.116 attempts to mitigate it by reverting to the technique users employed in the past, namely refresh once a minute.
Optimally, one could choose how states is handled. However, the throttling introduced in 0.116 is but the first step along that road to āoptimalā.
no, I can live now. and dont want to lag to much behindā¦ and about all features: are they still in the pipeline? As far as I read all Prās that were retracted from 116 shortly before release, they seem to be put on hold?
summarizing:
templates using
-
{{states.xxx}}or{{states|xx}}are updated once a minute -
{{now()}}are not updated at all, and need the extra{% set trigger = states('sensor.time') %}, or any other entity_id that updates to a desired frequency -
all other templates are updated continuously based on each state change of identified states in that template
So (I appreciate this is now contrary to otherās wishes in this thread), my template that I wanted to react to all state changes so I would be instantly notified of any unavailable entities is no longer useful? In fact I could lose connectivity with something for 59 seconds and never know?
If so whatās the solution for those of us that didnāt suffer any performance impact and do want every state change monitoring?
1 Like
There is resistance to adding a lot of knobs and complex rules that only a handful of people are asking for. That is why the manual rate control was reverted shortly before 0.116 final and I donāt think it will be returning without some real use cases (i.e. actual, useful templates that do not currently work).
1 Like
That is correct; if the template value changes forth and back within a minute, you might not know.
Explicit updates are not rate limited so maybe this can be used for inspiration?
automation:
- alias: Update template sensor for unavailable entities
mode: parallel
trigger:
- platform: event
event_type: state_changed
condition:
- condition: template
value_template: "{{ trigger.event.data.new_state.state in ('unavailable', 'unknown', 'none') }}"
action:
- service: homeassistant.update_entity
entity_id: sensor.unavailable_entities
You can leave out the condition but it should be quite an optimization because then we only take the expensive look at all states (i.e. render the sensor.unavailable_entities template) when something actually changes to a value that we care about.
Writing a condition that checks for entities becoming available again is left as an exercise, or you might be happy to have that delayed for (up to) a minute.
1 Like
Iāll check this out when I get a second, cheers 
funny you should advise this now, because I have gone lengths to rewrite several automations that used that trigger, which is creating listeners on all statesā¦ and all state changesā¦ causing the issues in the first place.
I now have a few automations that trigger on 48 listed states, rather than on the 2707 entities in the setupā¦
because isnāt that what this trigger does for a config like:
?
btw, if listing them now is the only/better option, I still have my hopes up to be able to use the expand() function for that in the near future:
platform: state
entity_id: >
{{expand('group.github_repos_in_use', 'group.github_repos_not_in_use')
|map(attribute='entity_id')|join(',')}}