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:
Light goes off after I shower for more than 3 minutes - so I turn off the standard bathroom automation for that time.
As soon as I finish showering, the light goes off because the sensor in the shower can no longer see me.
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.
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.
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.
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.
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.
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.
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.