As a guy who’s written code for a living for 35+ years, I appreciate the “mother of all rules” post on the wiki and the discussions here which use groups for reduce lines of code.
But I’ve not seen too much on doing systematic coordination/orchestration of automation events and design patterns of logic for same. So, I offer the following.
This starts with my particular use case involving a Light in my kitchen. There’s a switch in the room to control the light, as well as a motion sensor which can trigger the light. The light can also be triggered when the front door opens after dark (using Astro binding). (Kitchen lies just off stairwell from front door, so the light is turned on for a “welcome home”/safety purpose.)
So I’m cheap, and I want the light to go out quickly if not needed. I put timers in for the front door opens rule to automatically turn out the light. Especially needed when someone goes OUT after dark to make sure the light goes off since there are no other events available to trigger the OFF.
So light should go OFF if (a) manually switched, (b) motion detector goes CLOSED , or © a previously set timer expires and turns it off.
The main failure scenario was when someone was already in the kitchen, having tripped the motion detector and thus turning ON the light, then someone arrived home after dark, opened the front door and thus setup an automatic OFF timer. So in a few minutes, the light in the kitchen would go off even though the room was in use.
In essence, I needed to intercept the timer-triggered OFF command at execution time and invalidate it under some condition (namely the motion detector being OPEN).
I did this by creating a second item as a PROXY for the light switch and directing all sendCommands to the PROXY where they could be intercepted.
My solution looks like this (with logging removed for brevity).
(Like others in this forum, I don’t like re-using timers and do a lot of checking for timer-existence and clean-up/re-creation.)
First the PROXY intercept rules themselves (I intercept ON for symmetry):
rule "PXY_1: sw_LIGHT_Kitchen_PROXY changed to ON"
when
Item sw_LIGHT_Kitchen_PROXY changed to ON
then
var new_state=ON
//straight passthru for now
sendCommand(sw_LIGHT_Kitchen,new_state)
end
rule "PXY_2 : when mo_MOTION_Kitchen has not reset to CLOSED, intercept the OFF command"
when
Item sw_LIGHT_Kitchen_PROXY changed to OFF
then
var new_state=OFF
if (mo_MOTION_Kitchen.state == CLOSED){
new_state=OFF
} else {
if (tim_L_K_timerOFF != null) {
new_state=ON
tim_L_K_timerOFF.cancel()
tim_L_K_timerOFF=null
postUpdate(sw_LIGHT_Kitchen_PROXY,ON)
tim_L_K_timerOFF=createTimer(now.plusSeconds(10)) [|
sendCommand(sw_LIGHT_Kitchen_PROXY, OFF)
} else {
new_state=OFF
postUpdate(sw_LIGHT_Kitchen_PROXY,OFF)
}
}
sendCommand(sw_LIGHT_Kitchen,new_state)
end
PXY_2 intercepts the OFF command and only passes it thru to control the real light IF the motion detector is closed. Otherwise it requeues a timer on a tight loop.
The front door rule looks like this:
rule "FDC: front door CLOSES in KITCHEN.rules file"
when
Item co_CONTACT_SENSOR changed from OPEN to CLOSED
then
if (LOGICAL_NIGHT == 1 ) {
if (tim_L_K_timerON != null) {
tim_L_K_timerON.cancel()
tim_L_K_timerON=null
}
tim_L_K_timerON=createTimer(now.plusSeconds(3)) [|
sendCommand(sw_LIGHT_Kitchen_PROXY, ON) ]
// this is really only to handle making sure light gets turned off when people LEAVE
//if entering people go into the kitchen it will trip the motion sensor in rule MO_1
//that will cause this timer to be canceled
tim_L_K_timerOFF=createTimer(now.plusSeconds(120)) [|
sendCommand(sw_LIGHT_Kitchen_PROXY, OFF) ]
}
end
The motion sensor rules look like this:
rule "MO_1: Events when motion in room trips"
when
Item mo_MOTION_Kitchen changed to OPEN
then
if (sw_LIGHT_Kitchen.state == OFF) {
//if light was off, cancel any extant timers and turn it on due due to motion
if (tim_L_K_motionON != null) {
logDebug("KITCHEN","MO_1 : extant KITCHEN motion ON timer being checked/created..")
tim_L_K_motionON.cancel()
tim_L_K_motionON=null
}
tim_L_K_motionON=createTimer(now.plusSeconds(1)) [|
sendCommand(sw_LIGHT_Kitchen_PROXY,ON) ]
}
//make sure to kill any extant OFF timer
if (tim_L_K_timerOFF != null) {
tim_L_K_timerOFF.cancel()
tim_L_K_timerOFF=null
}
end
rule "MO_2 : events when mo_MOTION_Kitchen changed from OPEN to CLOSED"
when
Item mo_MOTION_Kitchen changed from OPEN to CLOSED or
Item mo_MOTION_Kitchen changed from Uninitialized to CLOSED
then
if (tim_L_K_timerOFF != null) {
tim_L_K_timerOFF.cancel()
tim_L_K_timerOFF=null
}
if (sw_LIGHT_Kitchen.state == ON) {
tim_L_K_timerOFF=createTimer(now.plusSeconds(10)) [|
sendCommand(sw_LIGHT_Kitchen_PROXY, OFF) ]
} else {
//LIGHT IS OFF when motion sensor resets -- likely due to manual operation or initialization so clean up any extant OFF timer
//NO-OP
}
end
Problem solved.
However, like Bob, I usually try to structure my code so a timer doesn’t need to be rescheduled, either creating a new one or using a Time trigger on another rule and a flag to enable/disable the logic.