Dynamic entity list in automation

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?

alias: Alarmzustand_ermitteln
description: ""
trigger:
  - platform: state
    entity_id:
      - alert.simple_power_outage_freezer_critical_alert
      - alert.simple_power_outage_server_critical_alert
condition: []
action:
  - if:
      - condition: and
        conditions:
          - condition: state
            entity_id: alert.simple_power_outage_freezer_critical_alert
            state: idle
          - condition: state
            entity_id: alert.simple_power_outage_server_critical_alert
            state: idle
    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

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.

How can the automation determine which member of the group was responsible for triggering the automation? Or is that not needed for this application?


EDIT

I can’t find any mention of alert entities in the Group integration’s documentation. Are they actually supported, but undocumented?

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).

{{ states.alert | selectattr('state','ne','idle') | list | count > 0 }}

But I need the automation running, when the last alert is going back to idle. Therefore is the 2nd trigger template:

{{ states.alert | selectattr('state','ne','idle') | list | count == 0 }}

In the action part I use again the template, that checks if there are any alerts not idling to decide, to put the input_boolean.alarm true or false

If you are interested, you can reduce it to this:

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 }}"
    id: 'on'
  - platform: template
    value_template: "{{ states.alert | selectattr('state','ne','idle') | list | count == 0 }}"
    id: 'off'
condition: []
action:
  - service: 'input_boolean.turn_{{ trigger.id }}'
    data: {}
    target:
      entity_id: input_boolean.alarm
mode: single
1 Like

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_sensor entity_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.

Possibly. However there’s still the unanswered question about whether or not Home Assistant’s Group integration supports alert entities.

I cannot test this since I do not have alert entities.
Maybe the OP can do some tests?
At least this does not give any errors:

I thought that because you suggested to group them, you knew they were supported by the Group integration (despite being undocumented).

True but neither does this:

{{ states.foo | list }}

In other words, it won’t report an error even if the domain doesn’t exist.

Anyway, anderl1969 found a neat way to solve the problem.

Absolutely!
Still, it would be interesting to know whether it would work with this dynamic group as well.

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:

{{
  states.alert
    | selectattr('entity_id', 'match', '.*_critical_alert')
    | map(attribute='entity_id')
    | list
}}

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.

The output is this:

['alert.simple_power_outage_test_critical_alert', 'alert.simple_power_outage_freezer_critical_alert', 'alert.simple_power_outage_server_critical_alert']

Although I haven’t really dealt with groups yet, it looks like it will work. But what is the advantage over my approach?

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.