Properly Scaling Automations When You Have Hundreds of Devices & Thousands of Entities

[real glade]

A little context

• 100+ wired motion sensors connected to an Elk M1 alarm panel
• 100+ water leak sensors tied to alarm panel
• 12+ smoke/carbon detectors tied to alarm panel
• 100+ z-wave light switches
• 15+ Unifi cameras
• etc.

Question - I do not want to create thousands of automations and looking to leverage labels/triggers to group devices/entities. Thus, could you experts review this automation.yaml to see if I'm headed the correct direction? Basically this should be a generic "turn the light on" automation for any motion sensor in my home - or at least that's the goal.

[wary moon]

triggers:
  - trigger: event
    event_type: state_changed

That's a recipe for failure and frustration. An "open" state changed Event trigger will fire on every state and attribute change of every entity and will quickly saturate your max. Combined with the conditions, you've just created a really bad version of a State trigger. So, for now, just use a State trigger.

Just FYI, triggers are currently being expanded to include more "purpose-specific" options for targeting triggers. Motion sensors are not yet included as part of the preview available in Labs. Once they are, that will likely be the better way to define the kind of trigger you are looking for.

[random vigil]

Would this allow you to define an automation once for all dimmers (say) because the dimmer “knows” what light(s) it should control? This is one thing that drives me mad with automations: I have dozens that are similar. And yes blueprints help but it’s only a partial solution to reducing/eliminating duplication.

[rancid basin]

Yeah - this is basically how I have mine set up, just grouping controllers and controllees by label. Every controller has a single label, controlled entities can have multiple to allow for different groupings
As drew mentioned though, using a state trigger is a much more robust way of doing it
I would also bundle all relevant actions into a single automation (e.g. turn on, turn off, and change dimming for lights) rather than have separate automations for each - as I find that much easier to keep track of

[real glade]

@wary moon @rancid basin so if I’m understanding correctly, I should use state triggers but I can not yet because motion sensors are not yet supported?

Is there a creative way to “make” my wired motion sensors “look” like a support state trigger?

Or is there any alternative besides creating hundreds of “if motion X is violated then turn on light X”?

[rancid basin]

State triggers work fine with motion sensors, it's the device triggers which don't yet work.

[wary moon]

Or is there any alternative besides creating hundreds of “if motion X is violated then turn on light X”?

The example you showed only covered 1 sensor entity, so this might not be 100% what you are looking for, but I think you're looking for something like the following:

alias: "Global: Label-Linked Lighting (Optimized Speed)
triggers:
  - trigger: state
    entity_id:
      - sensor.elkm1_zone
      - sensor.some_zone
      - sensor.some_other_zone
condition:
  - "{{ trigger.to_state.state not in ['unknown','unavailable'] and trigger.from_state.state not in ['unknown','unavailable'] }}"
actions:
  - variables:
      all_labels: "{{labels(trigger.entity_id)}}"
      target_label: "{{ all_labels|reject('eq','elk_zones')|first|default('none', true) }}"
      action_type: "{{'on' if trigger.to_state.attributes.physical_status == 'open' else 'off')}}"
  - condition: template
    value_template: "{{target_label != 'none'}}"
  - action: homeassistant.turn_{{action_type}}
    target:
      entity_id: "{{ label_entities(target_label)|reject('eq', sensor)|list }}"
mode: parallel
max: 100

[rancid basin]

except replace the condition with not_to and not_from unknown/unavailable

[wary moon]

@rancid basin My thinking was that adding not_to would limit triggers to state changes, and OP's original seems to indicate that the attribute change may need to be monitored as well... it's hard to tell without actual seeing the breakdown of the state obj.

[real glade]

@wary moon @rancid basin - To recap, I have hundreds of motions sensors throughout my large home. I also have a lot of z-wave light switches. I also have dozens of mmWave sensors that detect movement, lumens/brightness, etc.).

I could create an automation (e.g. when the game room motion sensor (sensor.elkm1_zone_001 detects movement, turn on the light ). Obvious I would then need an automation when that light might turn off based on time of day, lumens, movement from wired motion sensor or mmWave sensor, etc.)

But I don't want to create and/or manage hundreds of automations. I really want to assign a wired motion sensor, an mmWave sensor, and a z-wave light switch together (via label or something) so I can create 1 generic automation for when to turn any light on based on any motion... and perhaps another generic automation to handle when the light should be turned off.

As an example, I pasted a screenshot of the sensor.elkm1_zone_001 motion sensor when there is no movement.

I pasted another example when it detects motion

[rancid basin]

Yes. You can do this. It's really not hard, you even have a good handle on how exactly to do it. What is the issue you are struggling with?

[real glade]

In my original post (that was using state_changed events and labels), you or someone said that was a bad idea... I assume from a performance standpoint or something? What I was attempting to do is label my motion sensors, my mmWave sensors, and z-wave light switches so that I could create a generic "turn on any light" but the feedback I got was not to attempt this using my example YAML above.

[rancid basin]

Yes, you were told to use a state trigger rather than an event trigger

[real glade]

so what exactly do I need to change in that YAML?

@wary moon said that motion sensors state triggers are not yet supported.

[rancid basin]

no he didn't - state triggers are fully supported because it's literally just watching the state of an entity. the new device based "purpose" triggers are a different thing entirely

[real glade]

His quote "Motion sensors are not yet included as part of the preview available in Labs. Once they are, that will likely be the better way to define the kind of trigger you are looking for."

If it is supported, what exactly do I need to change in my original YAML?

[rancid basin]

that depends on what you want to do exactly - like looking at your original code you are checking a particular attribute is changing from not open to open - presumably that's limited to one particular type of sensor though and you've now mentioned 3 different sensors you want to use

[rancid basin]

I already corrected you on that misinterpretation of what he said 8 hours ago

[real glade]

I have over 100 wired motion sensors. They are all exactly the same device but 1 is in the kitchen, 1 in the pantry, 1 in the living room, 1 in the gym, etc. For now let's not worry about mmWave sensors (I have dozens but they are all the same device - just located in different areas of the house).

What I'm trying to do is create a single generic "turn on the light" automation. If motion is detected in the kitchen, turn on the kitchen light. If motion is detected in the master bathroom, turn on that light. Etc. I could write an automation for each motion sensor and what light switch it should "turn on" but I'm trying to use labels and assign my rooms/areas by lable such that when a motion sensor goes off in room X, then turn on the light in room X.

[rancid basin]

Anyway, it's midnight and I have not got the energy to type out yaml on my phone

[real glade]

Appreciate the help... good night. Apparently I need to read up on the difference between an event trigger and a state trigger...

[rancid basin]

So the simple way to do it is as Drew showed you, just list every sensor in a single state trigger and run it off that. Not great, but it's better than 100 different automations and you only have to do it once. If it is something you foresee changing frequently, you can still label them and then use the template editor in developer tools to spit out the list for you to copy into the automation

You can do it a more dynamically with a template helper - along the lines of {{ label_entities('motion_sensors') | expand | selectattr('state', 'eq', 'on') | list | count }} - this gives you the number of motion sensors that are on as a state. I would personally make this template in yaml rather than the ui, so you can also set an attribute to be the entity_id of the last changed sensor, but you can also work out which sensor has changed last in the automation itself as you can sort the label_entities by last_changed with a bit of template magic
Then your automation is just triggered by the state of that template helper (i.e. will trigger whenever the total number of motion sensors currently on changes), and then you either turn off or on a light or whatever you want to do
I would have your 3 types of sensors act as differently labelled triggers and keep everything inside one automation with a Choose block as I find that easier to follow than multiple automation files.

[lusty seal]

I made a blueprint designed for the KLIPPBOK water sensor but it works for any device with the same category (I have Tuya water sensors too) that makes a notification if ANY sensor got wet with pertinant info (what sensor and when) that has to be cleared and an optional companion app push. This would let you just click through and bulk add your 100 water sensors. You could easily modify it. https://community.home-assistant.io/t/ikea-klippbok-e2493-leak-sensor-matter/978617

You don't even have to change anything except rename the automation to just "Leak sensor" and you're done.