I have an automation that tries to notify when an E-INK tag reboots. I monitor for state change to FIRSTBOOT. It successfully notified me today, but why did {{ trigger.entity_id }} in the message show a different sensor? The tag rebooting had entity_id sensor.oepl_kaffe_wakeup_reason and the notification said sensor.ap_systime. https://dpaste.org/rKSqa
#Wrong trigger.entity_id in notification
1 messages · Page 1 of 1 (latest)
I think this is because in your template trigger you are iterating over the whole state.sensor list - my guess is that ap_systime is listed first in that object?
Aha. That might be it. Not sure how to check but that sounds like a good theory. Any ideas how I can make it show the right sensor?
If you do a state based trigger to FIRSTBOOT and add all the e-ink tags individually that would definitely work, but if there a large number of them, or it changes often that'll get annoying fast.
I don't think trigger.entity_id will work in this kind of arrangement, you might have to re-loop through the entities to find the one that triggered it..
You can avoid using the for loop by using this template
{{
states.sensor
| selectattr('entity_id', 'search', '^sensor.oepl.*_wakeup_reason$')
| selectattr('state', 'eq', 'FIRSTBOOT')
| list
| count > 0
}}```
However, in both cases it will only work for the first entity matching that search in the wanted state.
The same applies for your template, because if there are two your template will return truetrue
In your case it could be that it was triggered because it changed from truetrue to true so the entity which caused the template to render True was actually an entity which worked correctly
To achieve what you want, you need a template entity with the count of the number of entities for which this applies, and then an attribute which lists the entities
Ah, thanks. Sounds like the sane option is to set the entities manually. It's only about 10 of them.
Then trigger on a state change of that template entity and compare the from_state with the to_state to see which entity caused the change
Thanks for the help.
Good luck!
You could actually avoid the > 0 comparison couldn't you? as that's baked into template trigger's response to numbers