Really trying to avoid the individual listing of entities wherever possible as this work compounds when it needs to be applied over numerous automatons.
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:
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?
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.
You should try it then
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.
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.
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.
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?
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.
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)
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.