How unavailability affects group logic - making automations resilient to unavailable devices

Configuration
1

I’m updating automations using the new purpose-based triggers. In a situation where I check the state of multiple sensors and I want to make the automation resilient to unavailability, what is the best approach?

Lets say I have multiple motion sensors on my driveway. I assign a label ‘driveway’ to the sensors, then check labelled sensors for occupancy. If I understand correctly, a trigger for all sensors unoccupied will fail if one becomes unavailable. So I trigger by checking occupancy (any, unoccupied), then add a condition to check for (occupancy - any, occupied) inside a not block. Is that the optimal approach? Basically a conditional Not-Any is better than All when checking the state of multiple sensors?

2

In my opinion, the logic for avoiding deadlocks caused by the possibility that a sensor might become unavailable is:

If no sensors are occupied, then the user is absent; if even one sensor is occupied, then the user is present.
If you do the opposite (if all sensors are unoccupied, then the user is absent), a single unreachable sensor would always return a true result.

3

A binary-sensor Group helper might be worth looking at as it seems to cover your scenario.

4

I don’t think that occupancy sensors can be combined as a group helper. In addition, my goal here is to replace a working and resilient automation with something that takes advantage of the new methodology for automations. The main advantage that I can see is that adding and removing sensors shouldn’t require any updates to the automation, and building in resilience to missing sensors should be easier. If I understand correctly, a sensor group helper would have to be updated when sensors are added.

So I think my current solution, which follows the logic of @Idaho947, is probably the way to do it. The main point is that any trigger that relies on all sensors attaining a specific state is not resilient to unavailability, so better to trigger on any sensor entering that state and then make a conditional check, which in my case is described by ‘not any sensor in group is on’ rather than ‘all sensors in group are off’.

6

What it is that you are saying doesn’t work?
I have multiple groups of the form:

binary_sensor:
  - platform: group
    unique_id: sensor_group_living
    name: "Sensor Group Living"
    device_class: occupancy
    entities:
      - binary_sensor.entry_door_contact
      - binary_sensor.living_main_ir_occupancy

Where I combine various combinations of:

  • Door contact sensors.
  • IR presence detectors.
  • Radar occupancy detectors.

NOTE: I only add contact sensors for doors that are normally closed - so an open door indicates presence.

I think automations have continued to work correctly (need to explicitly test) even when some batteries have died - albeit only with the active sensors (with good batteries) in the group.

7

Ah, yes, now I see the helper group settings - not sure what I did in the UI to not see this. And yes, the group logic should also work, provided I manually set up the entities.