Here is another example where things don’t work as people might think:
Door Sensor contact changes to open
if Time is between sunset and sunrise
wait 10 minutes
So during the night, if the door opens the light comes on and ten minutes later it turns off.
The door being closed does not stop the light being turned off on a delay. Not only is the Time restriction not reached to be reevaluated but it probably wouldn’t have changed anyway. Only the parent condition affects TCP.
The only way the delay doesn’t complete is if the door opens for a second time during the wait and it is now after sunrise.
Something really odd is happening at the moment. If I had run your piston this morning (as I did my own several times), the switch changing back to off would not have cancelled the wait, it would have woken up and completed. That is not happening. However neither is it being cancelled. It is waking up and not doing anything. That just doesn’t happen.
Just a reminder: The last ~20 posts have been focused on TCP kept at the default setting. The better we understand that, the better we know when changing to “Never” may help
In reference to this piston:
It cancels because whenever Switch1’s switch changes (in either direction), the entire piston runs top to bottom, and executes anything not blocked by conditions. In this case, when the switch turns off, it checks line 18, determines it is false, and then cancels the previous WAIT. (unless TCP is set to Never, of course)
Well, if the trigger was a bulb changing to on, then yes, it would continue after the WAIT, as long as the switch was not changed during that WAIT.
But with a motion sensor… I dunno. If it follows the same logic as the switch trigger, then theoretically: IF the motion stayed ACTIVE for the entire WAIT, then yes, it should continue on afterwards… That being said, motion sensors may often go inactive briefly… even when you are still in the room… If that happens even once during the WAIT, then the piston will re-evaluate the motion sensor, and cancel out the previous scheduled wakeup. (which can, of course, by bypassed with TCP)
Oh I don’t mind being proved wrong over the nested IF example, even though I am pretty confident that I have tested it on at least three different occasions over the last month or two and it behaved differently. It still doesn’t claim to have cancelled the scheduled wakeup.
What is confusing me is that even with the simple one level IF THEN WAIT I am now seeing different behaviour to that I have seen for several months. Timer events that are supposed to be cancelled are suddenly firing the piston which then does nothing.
It is like the piston now doesn’t know there is a wake up scheduled so it neither cancels it nor reschedules it, but neither does it know what to do with it when it turns up.