D’oh! Sorry lost track.
I don’t see the ignored sensors group in the config you posted. That’s probably your issue. That is explained in the comments in the gist. Also I think the sensor config in the gist has been updated since version you have there.
I updated the gist to include the time_date sensor config. I guess I assumed everyone would have that already configured (really not sure why it isn’t just present by default). I really gotta stop assuming things…
There are big changes coming in how listeners are assigned to Template Sensors. Currently, if the entities in the template aren’t obvious, no listeners are assigned and the template never gets evaluated (only at startup). So a common workaround is to include sensor.time just because it changes state every minute (which causes the template to be evaluated). This will become far less necessary once the improvements are released (possibility in 0.115).
So many changes happening now it’s hard to keep up with them. Thanks for the heads up!
I actually have a few sensors where I’ve had to resort to using sensor.time to keep it updated. Always been curious how much overhead was involved in doing that. I imagine there has to be some sort of performance hit, but I’ve never noticed it.
Ok now it’s working as expected except that file editor shows the red exclamation mark after adding the ignored sensors group.
I don’t use that file editor. The syntax and indentation look correct to me. Do you have another group set up somewhere else in your config?
It looks like you are doing everything in your configuration.yaml file. I very strongly recommend you look into splitting up your configuration and setting up a packages directory if you’d like to use packages like this one.
Yes, I had another group in the config. I saw it from pc. It’s working now, thanks for your help!
You’ve got several automations all with the same names.
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.
@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.