I want to trigger automation on state changes for every entity identified by a common label. In essence something like this:
triggers:
- trigger: state
label_id: critical_sensors
to: on
Right now the alternative is to list all the entities manually, like:
triggers:
- trigger: state
entity_id:
- binary_sensor.oven_overpowering
- binary_sensor.kitchen_overheating
- binary_sensor.pump_overcurrent
# etc.
to: on
This is really verbose and also very hard to maintain, as the automation needs manual changes every time a sensor is added/removed.
Instead we could simply assign a label to a sensor, and the automation would apply to it automatically.
Agreed that this would be nice to have it available in the automation GUI. There is a work around you can use for now with a template sensor. I have one to tell me if one of any input booleans is on.
The problem with this is that it requires a separate template helper and is very verbose.
Also it gets stuck when you remove or add the label to some entity.
So I think my WTH is still a good idea, to make it simple and reliable to use for everyone.
The way to do it so to to that logic inside a template binary sensor. Then do the automation with a trigger on that binary sensor becoming true.
I have this EXACT setup for the exact reason you have :).
It works very reliably.
Ah I somehow missed all the replies lol
I have the count and the actual sensor names as attributes to the binary sensor so you can extract that data in your automation
To solve the issue you describe, unfortunately there is currently no event when labels are changed but you could add a template trigger to that binary sensor that reloads your binary sensor on âtemplate reloadâ. You do need to remember to do it manually but itâs worth it I think.
I imagine you generally donât add that label to sensors you want to monitor too often (at all?) so itâs not a big deal.
I agree your proposal would solve things much more simply but Iâve found I use this pattern a lot. A portion of the logic lives in some template sensors, and the automation logic is kind of separate. For complicated automations I also move a lot of it in scripts.
So my general HA pattern has ended up being: mixing of complicated state: template sensors. Triggering and coordination of what happens as separate actions â automation. The actual actions (if non-trivial) â scripts.
Also a relatively heavy use of jinja templates esp in dashboards to avoid code duplication.
This tends to work well as general design pattern for my install.
Your PR would have removed the need for a separate template sensor, allowing to just use a template trigger in the automation.
But that would still be too verbose in my opinion. I want a simple option of choosing a label in the UI and it all working by itself. I would rather not have to write a complex template every time.
So although I support merging your PR, as it can be used for all sorts of complex patterns, I think this WTH is still a good idea, to have a nice and simple interface for the common case of just wanting to select a label.
Iâm not sure I agree. I think your PR was rejected, because of the reluctance of the HA devs to support a complex template usage in automation triggers. This is the opposite of that, it provides a nice UI interface to something that otherwise would be very complex to do. But we will see.
my last post before it was closed was âif this was a separate trigger, would it get approvedâ and the discussion was locked. That tells you all you need to know.
I assumed the GitHub actions was an automatic Bot, and that perhaps notifications for Frenk were off when he closed it which looked like it was before the last comment.
In any case, it looked like a good contribution, especially with the option to make it separate. Sucks to just have conversation just shut down. Kinda demotivating. But again, I have to wonder if it was lost as an artifact of automated actions. Youâd know better than I.
Itâs not a fix to this request (which I think should still be implemented) but you can do some things by creating helper Groups of certain types of entities, and then use the group as the entity in the trigger for an automation.
When creating a binary sensor group the popup docs say:
âIf âall entitiesâ is enabled, the groupâs state is on only if all members are on. If âall entitiesâ is disabled, the groupâs state is on if any member is on.â
So you can have it trigger on any or all grouped sensors firing.