Just remove the line containing entity_id: sensor.time. The Template Sensor will continue to work. The primary difference is that in version 0.115 it will be evaluated more frequently than just once a minute. Let us know if you notice any performance-related issues.
1 Like
@123’s explanation about sums it up. I have removed this sensor from my own configuration. On my RPi 3 with everything else I have going on it pretty much brings the system to a standstill. Perhaps if one is running something a bit more powerful it may still be a viable, but it’s still going to be a pretty resource intensive sensor either way
I’m hoping the devs come up with a way to let us limit the updating of these kinds of sensors with something like a scan_interval option.
The solution already existed but was deprecated. It was called entity_id.
scan_interval would theoretically let you control how often the template is evaluated (in seconds from 1 to whatever). At first glance, that sounds better than using entity_id: sensor.time which is limited to updating once a minute. However, what scan_interval can’t do is update at the start of every day. Why not? Because it’s an interval and there’s little control over when these intervals start.
Some template sensors have a requirement to be refreshed at the start of every new day. scan_interval can’t do that so it get messier because now you need an automation, with a Time Trigger, to update the Template Sensor moments after midnight. What was once very easy, using entity_id: sensor.date, becomes more complicated.
Honestly, up until 0.115, using either sensor.time or sensor.date with entity_id was sufficiently flexible to satisfy the majority of needs. The only way scan_interval would improve things is if in addition to accepting values like this:
scan_interval: 15 # 15 seconds
it would accept values like this:
scan_interval:
seconds: 30
scan_interval:
minutes: 15
scan_interval:
period: minute
scan_interval:
period: hour
scan_interval:
period: day
scan_interval:
period: week
However, that wouldn’t fly because it deviates from how scan_interval is used elsewhere. It would have to redefined to operate this way for every integration that uses it and that’s probably not an attractive task for most developers.
Thanks again @123! I commented it out and it seems to work fine. I’m running it in a VM with plenty of horsepower so I don’t notice any CPU hit.
Many people aren’t. I just had a random thought based on @jazzyisj comment about the pi, and I’m wondering if those that are having performance issues are all on arm processors or there is some other correlation that needs to be looked into.
Quite the difference in observed performance. I agree with mf_social that perhaps system architecture might be responsible. Basic template processing should not overtax an RPI3.
1 Like
Maybe one of you could try this (warning, it grinds my Rpi4 to a halt)
{% 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)}}
And about the unavailable sensor, do try the python script, it is so fast, totally controllable and breaks no sweat at all
I can’t test the template as I’m not home until the weekend, but I’ve noted before that these templates causing issues seem to be doing so on arm processors, and I thought I’d mention it again so that maybe anyone that does test it can say what architecture they’re on when they report the results, as if there is a correlation then maybe the devs need to look at these changes again and make sure they are ‘computable’ on all architectures.
yes, that’s why I posted, so maybe see if this would be platform induced too. As said, using an Rpi4, 4 gb mem.
btw, I’ve moved this particular sensor to a python script too, some time ago. Which seems do much more reliable, and doesn’t harm at all.
Where can I find this script as I don’t seem to find it in this page? I’m not well versed in python and not sure how to do this…
here you go: Develop and rebuild template sensor to python_script
you need to enable python scripts in your config, using
python_script:
in your configuration.yaml
and after that, you can call the python script as a service, see https://www.home-assistant.io/integrations/python_script/
1 Like
Thank you VERY much
1 Like
YW 
got a few more of those, eg creating all the counters you need… 1 click, bam, all domains/entities counted. Beats any jinja template (and wont burden the processor)
1 Like
Any chance you have them on a GitHub or anything? 
I’d like to create a dynamic group according to entity id, I’ve got plenty of pond and pool entities that I’d like to ignore for winter time as I shut power to them. Can I create a dynamic group that would exclude them in the UUN?
I had only two of these “types” of sensors (the one in this thread and another that counted various entities that I stole from Marius 
) and those were the sole reason that my system was very bogged down as discussed in the other thread. It didn’t grind things to a halt but they definitely made a hit in the performance of my system. Once I removed those two sensors everything returned to normal.
I’m on an intel NUC i3.
That’s surprising as my system isn’t as powerful as yours and mine is unaffected 
no, but if allowed, I gladly post here, they are rather short.
would know why not, just add the group to the exclude_entities (to exclude the group itself), and to the exclude_groups, to exclude the entities in that group.
No, I realise I forgot few words in my request, I meant how to auto generate a group with all entities that has pool or pond in the entity id