Automation Trigger When Any Entity Attribute In Group Changes

Configuration
, , ,
1

Hi,

I am trying to get an automation to fire whenever any entity within a group (eg. any switch in group.living_room) changes a state or attribute.

So far, anything that I have tried only seems to fire the automation when the global state of the group changes (i.e. group.living_room changes to on)

Any help would be greatly received!

2

I could be wrong, but I don’t think that’s possible with groups. You’d have to make the trigger of the automation something like this:

  trigger:
  - platform: state
    entity_id:
    - switch.switch1
    - switch.switch2
    - switch.switch3
    ...

This will trigger each time one of the states (or state attributes) of any of those switches changes.

3

Thanks!

Really trying to avoid the individual listing of entities wherever possible as this work compounds when it needs to be applied over numerous automatons.

Can it be templated?

4

Well, you could create an input_boolean and then make an automation like this…then you could use the state of the input_boolean changing to trigger the other automation:

- alias: Toggle input boolean
  trigger:
  - platform: state
    entity_id:
    - switch.switch1
    - switch.switch2
    - switch.switch3
    ...
  action:
  - service: input_boolean.toggle
    entity_id: input_boolean.foo_bar

Trigger for the other automation(s):

  trigger:
  - platform: state
    entity_id: input_boolean.foo_bar

This way you only need to update the “toggle input_boolean” automation with new entity IDs.

2 Likes
5

I also don’t know if this is possible with “normal” automations. With AppDaemon for example this is doable. But may I ask you the use case for this?

1 Like
6

Look at my workaround above :wink:

1 Like
7

Yes I saw this, nice workaround by the way! I just thought, it’s still two places you need to change when you add another entity to a group and not only one place. Maybe this workaround is sufficient for OP, but who knows.

8

True! Mine is not a perfect solution by any means.

Either way, AppDaemon may indeed work better for OP. I have no experience with that, but it definitely sounds interesting.

9

You should try it then :stuck_out_tongue:
I love it, once you are used to it, I find it easier to create automations. Also code reusability and the ability to create complex automations (which are hard to do with “normal” automations, are hard to maintain or not even possible) are some major advantages in my opinion.
I don’t have any “normal” automation, my automation.yaml is empty.

10

Not sure if i like that idea because anyone can still flip the boolean which would unsync the boolean from the state of the switches. Also, input booleans inherently suppress on->on events so you’d be in the same boat as the group.

11

The boolean doesn’t need to reflect the state of the switches, it just needs to change state (input_boolean.toggle) upon any state/state attribute change of the switches in question in order to trigger other automations with a state trigger of that boolean.

Perhaps I misunderstood what you said though.

12

Nope, i didn’t notice the toggle. But It still can be edited by a user.

Either way, a way around that would be to use custom events:

- alias: Living Room Events
  trigger:
  - platform: state
    entity_id:
    - switch.switch1
    - switch.switch2
    - switch.switch3
    ...
  action:
    - event: event_light_state_changed
      event_data:
        group: livingroom

and trigger off it

- alias: Capture LivingRoom Event
  trigger:
    - platform: event
      event_type: event_light_state_changed
      event_data:
        group: livingroom
  action:
    - service: notify.notify
      data_template:
        message: "{{ trigger.event.data.group | Title }} switch event"
2 Likes
13

Not sure if being edited by a user is a concern, but yes, that is still a possibility.

Interesting! I’ll have to read about custom events.

14

It’s buried in script docs. Not much to read tbh. Docs are lacking

15

Yeah I’ll take a look! I suppose my automations are pretty simple so I haven’t found a need (yet) for a more advanced tool.

1 Like
16

Ah yeah I’ve seen that before. It’s definitely a brief description.

17

So,

Replying to one of the questions above, there are several use cases that I would like to use this sort of trigger for. Two of the main ones are:

A trigger to run an sql entity update for a dynamic history card that shows the last n number of switch trigger events for a particular group

A trigger that updates light kelvin values within a group based on the circadian daylight sensor

There has to be a clean(ish) way that this can be done just purely using templating and groups without the need for custom sensors or listing of individual entities?

18

No, there’s not. This is because the templates needs hard coded names in order to create listeners. Templates are only executed when the listeners callback is fired. If you have a template without listeners there’s nothing to fire the template. It’s a catch 22.

19

I have an additional question: If using a group / multiple entities for the trigger (eg. state changes of entities of the same type) => is there a way of getting the “triggering” entity? Or do I need to create a trigger per entity (not favorable)

20

If you are using multiple entities, yes. But getting that information depends on the trigger type. For a state trigger its: trigger.to_state.entity_id.

If you are using a group, no.