I have an issue that seemed to happen after I upgraded from 0.114 to 0.117. Maybe I missed the breaking change somewhere, but I can’t figure this out for the life of me.
I have a group of alert entities that I use for an automation. Basically, the alert entity can only use the notification entities to send messages, but I needed it to play a sound over my Google Home’s as well. So I created an automation that uses a group of alert entities to do the sounds.
Since upgrading to 0.117 the group of alert entities no longer resets to the “off” state when the alert(s) that tripped it goes back to “idle”. If I check the alert entities, they are all in an “idle” state, but the group remains “on”. This messes up my automation. The sound keeps playing.
Does anyone else use a group of alert entities? Has anyone else seen this issue? If so, have you found a solution?
Groups really only know on/off for generic types. Some special groups exists for person and notify, but for all unknown types, it will expect a state of “on” or “off”.
Alerts have 3 states. On, Off, Idle. It won’t know how to parse this group.
Not sure what would have changed to break this. Did alerts get a new state?
Either way, you should just make a template binary sensor.
binary_sensor:
- platform: template
sensors:
alert_group:
friendly_name: "Alerts"
value_template: >-
{{ not is_state('alert.alert_1', 'on''')
and not is_state('alert.alert_2', 'on')
and not is_state('alert.alert_3', 'on') }}
This will treat OFF and IDLE as “not on”. The template sensor will only be on if any of the alerts are in the on state.
This worked out great. Just strange on how they stopped working. I’m guessing they changed groups to recognize an explicit “off” state now instead of a blanket non-“on” state. Not really sure if that’s classified as a bug, but that is definitely a breaking change that should be documented. If they did, I can’t find it.