Does your template use states?
If it doesn’t then there’s no reason to use an automation with a Time Pattern Trigger. All you have to do is described in the first post of this thread. Basically, just add this to your template:
{% set x = states('sensor.time') %}
Oh, yes, I didn’t understand ( french guy 
) it’s possible to do like that. THX
With 0.116, the template related performance improvements should improve performance quite a bit, especially for those who were seeing templates update too frequently.
If you still are seeing a performance issue, I’ve put together a profiler integration that can help track down any remaining issues.
In the mean time, I’ve uploaded the integration here so it can be installed as a custom repository though HACS
How do we use the data generated by Profiler to investigate potential issues?
I’ve installed and run a scan to play around with it but I don’t know what to do to interact with the files generated.
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.
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:
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?
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.
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?