Yes, because when you turned on switch 1 the piston entered WAIT A. The piston hadn’t reached IF B to evaluate it.
If WAIT A was say 10 seconds things should be different. Or indeed if there wasn’t a WAIT A. That way IF B would be reached.
Yes, when switch 2 fired the piston executed and immediately hit IF A and the trigger evaluated as false so WAIT A was cancelled.
Evaluation is everything.
Here is another example where things don’t work as people might think:
if
Door Sensor contact changes to open
then
if Time is between sunset and sunrise
then
with
Hall Light
do
turn on
wait 10 minutes
turn off
end with
end if
end if
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.
I am not trying to be argumentative, but your second sentence is not true either… In this simple piston:
If Switch 1 turns on, then the piston runs top to bottom… BUT… if Switch 1 turns off during the WAIT, the piston cancels, and does not finish after the WAIT.
That’s what I was questioning above. If the state of the device changes, whether expected or not, then the wait is cancelled and execution starts at the top of the piston again. Yes?
If a subscribed device’s attributes CHANGES, then the piston starts over at the top. Whether the WAIT is cancelled or not, is not an easy answer. Both Yes and No examples are above.
Makes me want to avoid WAITS and TCP altogether. But sometimes, I just cannot build a better solution. Ugh!
I wouldn’t avoid WAITs… They can really add ingenuity to our SmartHomes…
What I sometimes do is use a couple of Simulated Switched and a basic structure piston to play around with various logics and timings…
Using log to console, it makes it real easy to see what was executed, and what was bypassed.
43:54 = Switch1 manually turned on
44:25 = Programmatic logic
46:11 = Switch1 manually turned off
46:16 = Switch2 manually turned off
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.
This is really weird… Is this because of second nested IF ???
I’m not home Wcmore as you know so I can’t test it my self but let me ask you this example:
IF motion sensor x changes to active
Then
With RGB do turn ON
Wait 10 minutes
With RGB do turn OFF
Then do this do that (in the same IF block)
This supposed to wait 10 minutes and keep going after… correct?
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)
Guess my testing isn’t thorough enough. I’m now consistently seeing the pistons not (re)scheduling the wake up and then waking up anyway and doing nothing. I’ve now no idea how anything works.
I’ve had some sleep and coffee now, and I re-read this. This logic adds an additional dimension to the thought process when designing pistons.
I think you have a better grasp than most… It is just really hard to say a single sentence that is 100% accurate…
IE: Nearly every “rule” has exceptions to the rule…
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.
Can you point me to some resource/documentation which describes the effect of setting TCP on the ‘if’ v/s ‘with’?
I’m playing around with this piston and experimenting with applying the TCP on the ‘if’ v/s ‘with’. The scheduled wait is cancelled when I apply it to the ‘if’ but I’m not sure I understand why.
EDIT:
I suppose this whole post discusses the nuances of TCP so my question is kinda redundant. I also found this post (How TCP is set to NEVER - when WAIT is not working in your piston) which is exactly what I’m doing. I’ll play around with it for now.
EDIT2:
Ok, didn’t work and then I read through the discussion after that which explained why. I should read first and then experiment instead of just muddling through with trial and error 
Ok, the reason I asked is because when I added TCP to the if-block nothing seemed to happen so I wasn’t sure what that does. I’m able to get the light to turn off after a delay by adding the TCP to the with block. Now I’m trying to add an exception if someone interacted with it physically in any form. Any suggestions for how to go about that?
I tried this:
but doesn’t do exactly what I’m looking for. The light does turn off after the delay but physically interacting with the switch and using that to cancel all pending tasks explicitly does nothing. Furthermore, the light turning off triggers the physical interaction if-condition.
9/9/2020, 6:37:14 PM +774ms
+2ms ╔Received event [Passage Light (Hallway)].switch = off with a delay of 87ms
+99ms ║RunTime Analysis CS > 20ms > PS > 45ms > PE > 34ms > CE
+102ms ║Runtime (42568 bytes) successfully initialized in 45ms (v0.3.110.20191009) (99ms)
+102ms ║╔Execution stage started
+114ms ║║Condition #3 evaluated false (7ms)
+123ms ║║Comparison (enum) inactive is (string) active = false (1ms)
+125ms ║║Condition #10 evaluated false (10ms)
+126ms ║║Cancelling statement #9's schedules...
+127ms ║║Cancelling condition #9's schedules...
+127ms ║║Condition group #9 evaluated false (state changed) (12ms)
+128ms ║║Cancelling condition #18's schedules...
+129ms ║║Condition group #18 evaluated false (state changed) (23ms)
+130ms ║║Cancelling condition #2's schedules...
+131ms ║║Condition group #2 evaluated false (state changed) (24ms)
+135ms ║║Comparison (enum) off changes = true (1ms)
+136ms ║║Cancelling condition #23's schedules...
+137ms ║║Condition #23 evaluated true (4ms)
+138ms ║║Cancelling condition #22's schedules...
+139ms ║║Condition group #22 evaluated true (state changed) (5ms)
+140ms ║║Cancelling statement #24's schedules...
+144ms ║║Executed virtual command [Passage Light (Hallway)].cancelTasks (1ms)
+146ms ║╚Execution stage complete. (44ms)
+147ms ╚Event processed successfully (147ms)
9/9/2020, 6:37:09 PM +94ms
+1ms ╔Received event [Home].time = 1599698230174 with a delay of -1080ms
+82ms ║RunTime Analysis CS > 16ms > PS > 33ms > PE > 33ms > CE
+85ms ║Runtime (42563 bytes) successfully initialized in 33ms (v0.3.110.20191009) (84ms)
+86ms ║╔Execution stage started
+92ms ║║Cancelling condition #9's schedules...
+93ms ║║Cancelling condition #18's schedules...
+94ms ║║Cancelling condition #2's schedules...
+116ms ║║Executed physical command [Passage Light (Hallway)].off() (16ms)
+117ms ║║Executed virtual command [Passage Light (Hallway)].setSwitch (17ms)
+125ms ║║Condition #23 evaluated false (6ms)
+126ms ║║Condition group #22 evaluated false (state did not change) (7ms)
+128ms ║╚Execution stage complete. (43ms)
+129ms ╚Event processed successfully (129ms)
9/9/2020, 6:36:16 PM +114ms
+1ms ╔Received event [Passage Light (Hallway)].switch = on with a delay of 52ms
+87ms ║RunTime Analysis CS > 18ms > PS > 32ms > PE > 38ms > CE
+89ms ║Runtime (42570 bytes) successfully initialized in 32ms (v0.3.110.20191009) (88ms)
+90ms ║╔Execution stage started
+101ms ║║Condition #3 evaluated false (6ms)
+112ms ║║Comparison (enum) inactive is (string) active = false (2ms)
+113ms ║║Condition #10 evaluated false (10ms)
+114ms ║║Cancelling statement #9's schedules...
+116ms ║║Condition group #9 evaluated false (state did not change) (12ms)
+117ms ║║Condition group #18 evaluated false (state did not change) (21ms)
+117ms ║║Condition group #2 evaluated false (state did not change) (23ms)
+122ms ║║Comparison (enum) on changes = false (0ms)
+123ms ║║Condition #23 evaluated false (3ms)
+124ms ║║Condition group #22 evaluated false (state did not change) (4ms)
+127ms ║╚Execution stage complete. (36ms)
+128ms ║Setting up scheduled job for Wed, Sep 9 2020 @ 6:37:10 PM MDT (in 53.933s)
+140ms ╚Event processed successfully (140ms)
9/9/2020, 6:36:12 PM +637ms
+1ms ╔Received event [Front Door].contact = closed with a delay of 84ms
+100ms ║RunTime Analysis CS > 21ms > PS > 46ms > PE > 33ms > CE
+102ms ║Runtime (42556 bytes) successfully initialized in 46ms (v0.3.110.20191009) (100ms)
+103ms ║╔Execution stage started
+109ms ║║Comparison (enum) closed changes_to (string) open = false (1ms)
+110ms ║║Condition #3 evaluated false (4ms)
+119ms ║║Comparison (enum) inactive is (string) active = false (1ms)
+120ms ║║Condition #10 evaluated false (9ms)
+121ms ║║Cancelling statement #9's schedules...
+122ms ║║Condition group #9 evaluated false (state did not change) (10ms)
+122ms ║║Condition group #18 evaluated false (state did not change) (16ms)
+123ms ║║Condition group #2 evaluated false (state did not change) (17ms)
+131ms ║║Cancelling condition #23's schedules...
+132ms ║║Condition #23 evaluated false (6ms)
+132ms ║║Cancelling condition #22's schedules...
+133ms ║║Condition group #22 evaluated false (state changed) (8ms)
+135ms ║╚Execution stage complete. (33ms)
+136ms ║Setting up scheduled job for Wed, Sep 9 2020 @ 6:37:10 PM MDT (in 57.401s)
+146ms ╚Event processed successfully (146ms)
9/9/2020, 6:36:10 PM +241ms
+2ms ╔Received event [Passage Light (Hallway)].switch = on with a delay of 88ms
+120ms ║RunTime Analysis CS > 25ms > PS > 52ms > PE > 43ms > CE
+123ms ║Runtime (42562 bytes) successfully initialized in 52ms (v0.3.110.20191009) (119ms)
+123ms ║╔Execution stage started
+135ms ║║Cancelling condition #3's schedules...
+136ms ║║Condition #3 evaluated false (9ms)
+146ms ║║Comparison (enum) inactive is (string) active = false (1ms)
+147ms ║║Condition #10 evaluated false (9ms)
+148ms ║║Cancelling statement #9's schedules...
+149ms ║║Condition group #9 evaluated false (state did not change) (12ms)
+150ms ║║Cancelling condition #18's schedules...
+151ms ║║Condition group #18 evaluated false (state changed) (24ms)
+152ms ║║Cancelling condition #2's schedules...
+152ms ║║Condition group #2 evaluated false (state changed) (25ms)
+156ms ║║Comparison (enum) on changes = true (0ms)
+157ms ║║Condition #23 evaluated true (3ms)
+158ms ║║Condition group #22 evaluated true (state did not change) (4ms)
+160ms ║║Cancelling statement #24's schedules...
+162ms ║║Executed virtual command [Passage Light (Hallway)].cancelTasks (1ms)
+168ms ║╚Execution stage complete. (45ms)
+169ms ╚Event processed successfully (169ms)
9/9/2020, 6:36:09 PM +917ms
+1ms ╔Received event [Front Door].contact = open with a delay of 69ms
+90ms ║RunTime Analysis CS > 19ms > PS > 39ms > PE > 33ms > CE
+93ms ║Runtime (42556 bytes) successfully initialized in 39ms (v0.3.110.20191009) (91ms)
+94ms ║╔Execution stage started
+101ms ║║Comparison (enum) open changes_to (string) open = true (1ms)
+102ms ║║Cancelling condition #3's schedules...
+103ms ║║Condition #3 evaluated true (5ms)
+104ms ║║Cancelling condition #18's schedules...
+105ms ║║Condition group #18 evaluated true (state changed) (6ms)
+137ms ║║Comparison (enum) off is (string) off = true (1ms)
+139ms ║║Comparison (enum) off is (string) off = true (1ms)
+141ms ║║Comparison (enum) off is (string) off = true (1ms)
+143ms ║║Comparison (enum) off is (string) off = true (1ms)
+145ms ║║Comparison (enum) off is (string) off = true (1ms)
+147ms ║║Comparison (enum) off is (string) off = true (1ms)
+149ms ║║Condition #19 evaluated true (44ms)
+190ms ║║Comparison (time) 66970067 is_not_between (time) 1599700680000 .. (time) 1599654960000 = true (9ms)
+191ms ║║Time restriction check passed
+192ms ║║Condition #21 evaluated true (42ms)
+193ms ║║Cancelling condition #2's schedules...
+194ms ║║Condition group #2 evaluated true (state changed) (97ms)
+196ms ║║Cancelling statement #4's schedules...
+251ms ║║Executed physical command [Passage Light (Hallway)].setLevel([50]) (52ms)
+252ms ║║Executed [Passage Light (Hallway)].setLevel (54ms)
+255ms ║║Executed virtual command [Passage Light (Hallway)].wait (1ms)
+256ms ║║Requesting a wake up for Wed, Sep 9 2020 @ 6:37:10 PM MDT (in 60.0s)
+260ms ║╚Execution stage complete. (166ms)
+261ms ║Setting up scheduled job for Wed, Sep 9 2020 @ 6:37:10 PM MDT (in 59.997s)
+274ms ╚Event processed successfully (274ms)You will need to check that BEFORE forcing the TCP…
… or add a new conditional block after the TCP block.
Otherwise, it will just keep on chugging along.
The best thread I have seen on this topic, actually uses the default TCP :
motion-based-light-except-when-manually-turned-on.
Just be aware that in the first post, there are two pistons.
Make sure you start with the right one.