I have an automation, which fires when any of my two existing alerts change state. In the action part it checks, if all (of my two) existing alerts are “idle” (then do one thing) or not (then do another thing).
Works fine.
But how do I do this with templates, so every time I create a new alert it will be taken into account by this automation without the need to manually customize it here?
What you can do is create a group of alert entities that is dynamically updated, and use this group in your automation.
You can create an automation that calls the service: group.set to create a dynamic group.
I played around a bit and came up with this solution:
alias: Alarmzustand_ermitteln v2
description: |-
Templates fire only, if they change form false to true.
Therefore a 2nd template with inverted logic
trigger:
- platform: template
value_template: "{{ states.alert | selectattr('state','ne','idle') | list | count > 0 }}"
- platform: template
value_template: "{{ states.alert | selectattr('state','ne','idle') | list | count == 0 }}"
condition: []
action:
- if:
- condition: template
value_template: >-
{{ states.alert | selectattr('state','ne','idle') | list | count == 0 }}
then:
- service: input_boolean.turn_off
data: {}
target:
entity_id: input_boolean.alarm
else:
- service: input_boolean.turn_on
data: {}
target:
entity_id: input_boolean.alarm
mode: single
The 1st Trigger-Template always fires, when the first alert leaves the idle-state. (The automation doesn’t need to run, when further alerts leave idle).
No, as I understand it, any member of the group that is triggered will have the group being triggered.
This is an example of an automation that dynamically creates a group of PIR sensors, and when I use this group as trigger in an automation it is triggered when any PIR sensor is triggered:
- id: 'xxxxxxxxxxxxxx'
alias: SYS - Dynamically define Group of PIR sensors
description: ''
trigger:
- platform: time_pattern
hours: /12
condition: []
action:
- service: group.set
data:
object_id: all_pir_sensors
entities: |
{{
states.binary_sensor
| selectattr('entity_id', 'match', '.*pir')
| map(attribute='entity_id')
| list
}}
mode: single
Note that this works only when in every PIR binary_sensorentity_id the string “pir” is present, and that is what I always do.
In this example the group is updated every 12 hours.
True but only for the first group member that changes to on (or whatever state the group interprets as ‘enabled’ which is why I asked if the Group integration supports alert entities). If a second group member changes to on, the group’s state remains unchanged (it’s still on). That means a group used in a State Trigger will be triggered by the first member that changes to on but not for subsequent members changing to on.
I understand, but isn’t this what the OP wants?
He wants an alert as long as any of the alert entities is alerting?
When all alert entities are reverted back to no_alert the group will also go to no_alert.
Thanks for your input and your discussion. I‘m still new to HA and its concepts. I can learn a lot of your exampels. Especially the tip with {{ trigger.id }} was great.
You’re welcome, and I still learn a lot as well while looking into the questions posted in this forum.
Like was discussed between Taras and me, can you please check whether the alert entities are supported by the Group integration?
The first step to do this is entering the following code in the Developer Tools → TEMPLATE → Template editor:
If it returns a list of your alert entities this might indicate that it will also be possible to create the discussed dynamic group of the alert entities.
There’s no advantage yet because it remains to be seen whether a legacy group supports alert entities (if you look at the screenshot I posted above, alert isn’t in the list). You’ll need to try to create a legacy group of alert entities and see how the resulting group entity behaves.
If it works, then the advantage is that it can contain a subset of your alert entities (i.e. only the ones containing “critical_alert”) as opposed to all of your “alert” entities. However, if you don’t need a subset, then the current technique you’re using is fine.
