2 Occupancy Sensors as trigger

My idea in the bathroom:
Sensor 1: Toilet + sink (“Bad oben sensor”)
Sensor 2: Shower (“Dusche Sensor”)

When I enter the bathroom, sensor 1 comes on and with it LED 1,2,3 at the top of the bathroom comes on.
As soon as 3min. no more occupancy is detected and the light goes out.

But when “Dusche Sensor” sees me and the door is locked, music comes on and the light becomes brighter.

As soon as both detectors can no longer see me, the lights and the music should turn off.

My current problem:

  1. Light goes off after I shower for more than 3 minutes - so I turn off the standard bathroom automation for that time.

  2. As soon as I finish showering, the light goes off because the sensor in the shower can no longer see me.

Do you have any idea how I can get around this?

alias: dusche
description: ""
trigger:
  - type: occupied
    platform: device
    device_id: 2fdca58cff3e53d54eef2f69afb44b87
    entity_id: 8a168d8d176b92e1179912ca498c50c8
    domain: binary_sensor
condition:
  - type: is_not_open
    condition: device
    device_id: 13700abc17ee9982d8d24464687d1874
    entity_id: eaef95ef3f735411a4f68862f13da0e9
    domain: binary_sensor
action:
  - service: automation.turn_off
    target:
      entity_id:
        - automation.bad_oben_nachts
        - automation.bad_oben_tag_licht
    data:
      stop_actions: true
  - service: media_player.media_play
    target:
      entity_id:
        - media_player.hey_siri_bad_oben
    data: {}
  - service: light.turn_on
    metadata: {}
    data: {}
    target:
      entity_id:
        - light.bad_oben_led_1
        - light.bad_oben_led_2
        - light.bad_oben_led_3
  - wait_for_trigger:
      - platform: state
        entity_id:
          - binary_sensor.dusche_sensor_occupancy
        to: "off"
        for:
          hours: 0
          minutes: 5
          seconds: 0
      - platform: state
        entity_id:
          - binary_sensor.bad_oben_sensor_occupancy
        to: "off"
        for:
          hours: 0
          minutes: 5
          seconds: 0
  - service: light.turn_off
    target:
      entity_id:
        - light.bad_oben_led_1
        - light.bad_oben_led_2
        - light.bad_oben_led_3
    data: {}
  - service: media_player.media_stop
    target:
      entity_id:
        - media_player.hey_siri_bad_oben
    data: {}
  - service: automation.turn_on
    target:
      entity_id:
        - automation.bad_oben_nachts
        - automation.bad_oben_tag_licht
    data: {}
mode: single

this code is, unfortunately quite fragile. for those of us in cs we’d call it spaghetti.

if you or someone figure it out, great… if not i’m happy to help, but my advice would start off with “let’s start over and do this ‘right’…” which most folks who aren’t into programming wouldn’t want to do…

so holler if you want to go down that road. it means starting over a bit, but on the flip side, if you often do complicated automation, it’ll help you do those well and more reliably…

Why not group the sensors using a helper? When grouped if one is on it acts like all are on. You can also increase the occupancy timeout so the shower sensor allows you to transition to another area.

My bathroom is a complicated layout for sensors so I use 3 grouped like I described.

1 Like

i believe he actively wants the lights, locks and music to be have different depending on the different states of the sensors, as well as the order of them triggering versus each other (see the “wait for events” in the code).

he’s kinda trying to do a state machine without actually keeping state.

You don’t have to use the group sensor for everything in the automation. States in a group will simply be on and off.

Grouping easily solves these issues.

  1. Light goes off after I shower for more than 3 minutes - so I turn off the standard bathroom automation for that time.
    As long as the shower see motion the other light will stay on. No time setting needed.

  2. As soon as I finish showering, the light goes off because the sensor in the shower can no longer see me.
    With a small change to occupancy timeout on the shower sensor, as he transitions to the other area, sensor 2 will pick up his movement and keep the lights on.

Do you see it different?

1 Like

This is what I’d do:

4 state triggers:

  • bad_oben to state ‘on’
  • dusche to state ‘on’
  • bad_oben to state ‘off’ for 5 minutes
  • dusche to state ‘off’ for 5 minutes

No conditions

1 action with choose, and 3 options under that:

  • 2 conditions: bad_oben ‘on’ and dusche ‘off’
    • 2 actions: turn on the 3 lights to medium brightness, and stop the music
  • 1 condition: dusche ‘on’
    • 2 actions: turn lights to high brightness, and play music
  • 2 conditions: bad_oben ‘off’ and dusche ‘off’
    • 2 actions: turn off all lights, stop the music
1 Like

i’m conceptually aligned with @mekaneck. he’s defined a 3 state machine (so far, but i’m not exactly sure if the op actually has more than 3 or not).

essentially he should define the N different places he could be. 1) toilet. 2) shower. 3) gone…full stop. (i’m not clear if he actually has another which is “in bath area after shower”… but the principle holds. define the states.) to make it super clear, he could potentially actually create a helper sensor entity where he maintains that state.

and he should define the sensor conditions corresponding to each. (which rick did in his outdents… or you could do those and set the state varaible/sensor.

finally define the state of the music and lights he wishes for each state… to be pedantic he could do that as triggers on the helper entity for clean readable abstraction. but more tighter code, can do it as rick did under each condition set.

if i’m teaching someone to code, i’d have them be pedantic to teach them to think and code more cleanly… so that’s why my preferred answer is to essentially start over.

1 Like

I wasn’t arguing the 3 state machine, but rather suggesting that group helper would create a binary sensor to simplify this (occupied vs not occupied) maintaining the state in the toilet /sink when he is in the shower.

to make it super clear, he could potentially actually create a helper sensor entity where he maintains that state.

Hey sorry for my late response - the way you described mekaneck sounds very good! I will try it out tomorrow soon.
It is only a 3 “state machine”.

Didn’t understand any of that, but unless this is a vanity project why are you trying to do all this in one automation? Two sensors, two automations.

1 Like

I cannot create 2 automations because they are combined with each other.
When I am leaving the shower and dry off I still want to hear my music, which is only playing when the shower sensor is occupied.