I searched that. Nothing about entry_id. None of the mentions of “template” seemed to apply. Did I miss something?
I’m concerned that if I remove the “entry_id” line (mine are all on one line) then I’d break other things which use that ID. What I’d really like to see is the description of the specific change which introduced this warning message. Maybe then I’d understand what’s going on.
Meanwhile, as I said, I have 17 “entry_id” lines, but the log only complained about 7 of them. Any idea how I could figure out which seven?
I mentioned the deprecation of entity_id for Template Sensors in this post (~ 3 weeks ago):
It’s much more difficult to find it in the release notes for 0.115.
If entity_id contains entities you can easily identify within the actual template, you can safely remove it. However, if entity_id contains entities not listed within the template, you will have to remember why you did that because now those entities must be incorporated within the template. In this particular case, simply removing entity_id is likely to negatively affect the Template Sensor.
I have the following binary sensor which indicates whether there was any motion on any of my motion sensors:
binary_sensor:
- platform: template
sensors:
housewide_movement:
friendly_name: House-wide movement
device_class: motion
entity_id:
- binary_sensor.kitchen_motion
- binary_sensor.livingroom_motion
- binary_sensor.recroom_motion
- binary_sensor.office_motion
- binary_sensor.garage_motion
value_template: >
{% for state in states.binary_sensor
if state.object_id.endswith('_motion')
and (state.state == 'on')
%}
{% if loop.first %}
{{ true }}
{% endif %}
{% endfor %}
If I have to remove the entity_id section, it’ll trigger on all binary_sensor updates instead of only the ones that matter. That’s unfortunate. I think I will have to replace this with an automation that manually updates the sensor when one of the applicable sensors is tripped.
I kind of liked the idea of being able to use an entity’s state in a template sensor, but not have it necessarily cause the state of the sensor to update. Like, I might want to use the value of sensor.time in a template sensor, but not necessarily have it update every minute.
Oh well, can’t please everybody. I’m probably an edge case.
I put it there because that’s what all the examples in the documentation said to do.
I guess it comes back to my initial question, which is how would I know which seven entity_ids failed? If the warning messages told me that, I could start to answer those other questions.
In the end, I think I found seven templates which didn’t seem to need an entity_id, and everything seems to be OK after commenting them out. At least, no more warnings in the log. But I don’t really feel like I’ve learned anything, and I can’t help but wonder whether the other ten entity_id lines in my configuration.yaml are going to cause a future problem.
The warning is telling you that the field is deprecated, not that the sensors failed. The field is not being used currently. So you can tell that the sensors ‘failed’ if they aren’t updating properly.
Are those 10 other entity_id fields in template sensors of any kind? If yes, then they should be removed when prompted.
taking out the entity_id I understand… but why was it in at first then and what changes after taking it out…?