WTH Trigger automation by label

Month of "What the heck?!"
1

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.

2

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.

- binary_sensor:
  - name: Peripheral Updates Available
    state: >-
      {{ (label_entities('Update Tracking') |
          expand() |
          selectattr('state', 'eq', 'on') |
          list |
          count) > 0 }}

That sensor will be on if any of the entities I’ve labeled with Update Tracking are on.

1 Like
3

Actually what I wanted is something more similar to a normal sensor, not a binary one.

- sensor:
  - name: Peripheral Updates
    state: >-
      {{ label_entities('Update Tracking') |
          expand |
          selectattr('state', 'eq', 'on') |
          list |
          count }}

And then using it in a state trigger.

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.

4

Your WTH is very similar to mine tho more popular.

5

I had a PR that was closed that would have solved this

6

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.

7

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.

8

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.

9

I know what you’re asking for, I’m just showing you that it won’t be easy to get it to happen.

10

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. :slight_smile:

11

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.

12

I don’t know GitHub very well, but do notifications turn off or get reduced after a PR is closed? Perhaps it wasn’t seen?

13

It was closed 1 day after the comment, likely because the comment was even there.

14

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.

15

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.