Thank you. Turns out, I had the same code in a different named package… Weird. Interestingly, devtools/states only lists one of each.
The Template sensor causes the following warning in logs since HA Update to 115: WARNING MainThread homeassistant.components.template.sensor The entity id option is deprecated, please remove it from your configuration
If I remove the entity id option entity id: sensor.time, the sensor will stop working. What can I do?
regards
I have the same question. I was looking at this entry in the docs to see if this might be useful, but templating still confuses me. 
In the case where the template should be updated every minute, just reading states("sensor.time") can achieve the desired result without the need to create an automation:
sensor:
- platform: time_date
display_options:
- 'time'
binary_sensor:
- platform: template
sensors:
minute_is_odd:
value_template: >-
{% set dummy = states("sensor.time") %}
{{ now().minute % 2 == 1 }}
In your example, it’s possible to include sensor.time within the calculation:
binary_sensor:
- platform: template
sensors:
minute_is_odd:
value_template: "{{ states.sensor.time.last_updated.minute % 2 == 1 }}"
Thx… any idea how to include it and replace the entity_id from the original code (below)?
sensor:
- platform: template
sensors:
unavailable_entities:
entity_id: sensor.time # updates sensor every minute
That’s a long-winded discussion that has taken place in this thread (deep within its bowels) and I don’t want to repeat it here.
It almost doesn’t matter if you do or don’t include sensor.time because 0.115 handles that template quite differently.
Because the template begins with states (as seen in {% set count = states|selectattr( ...) 0.115 will assign listeners to each and every entity in your system. That means the moment any entity changes state, the template will be evaluated. That’s more frequently than is needed but that’s how it now works in 0.115.
To prevent it, either don’t use states in a template (given the purpose of this particular Template Sensor, that’s not a practical option) or replace the entire Template Sensor with a completely different solution. That’s what’s happening in this thread:
Gotcha @123… and thanks for the info! I was hoping someone may have come up with an updated version of this unavailable sensors package that doesn’t use the entity_id… guess not yet.
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