No schedule canceling on condition not met

[kunjila88]

1) Give a description of the problem
If condition is not met anymore, wait doesn’t reset, scheduling is not canceled

2) What is the expected behaviour?
If the temperaure setpoint is sucessfully changed on first try, scheduling should be canceled

3) What is happening/not happening?
Very short on the intended function: My thermostat is naughty, doesn’t like to receive commands sometimes so in order to make sure the heating setpoint is changed, after first command, wait for 60s, send PUSH notification and try again, for 3 times. 2 set of comands each day.

No matter if setpoint chage was succesful after first, second or third try … the code will execute no matter the conditions and all 3 PUSH notifications will be received.

TCP set to on condition state. Why is scheduling after 60s not canceled if the condition is not fulfilled anymore? Could be because of every (TOD) triggers?

I can solve this on many different ways but I’m scratching my head over why this doesn’t work.

**4) Post a Green Snapshot of the piston!

5) Attach logs after turning logging level to Full
29.3.2022, 22:53:01 +113ms
+1ms ╔Received event [Mitt hjem].time = 1648587182274 with a delay of -1161ms
+64ms ║RunTime Analysis CS > 44ms > PS > 5ms > PE > 15ms > CE
+66ms ║Runtime (41997 bytes) successfully initialized in 5ms (v0.3.114.20220203) (65ms)
+67ms ║╔Execution stage started
+96ms ║║Executed virtual command [Bad 2 Thermostat].sendPushNotification (12ms)
+100ms ║╚Execution stage complete. (33ms)
+102ms ║Setting up scheduled job for Wed, Mar 30 2022 @ 8:12:00 PM CEST (in 76738s), with 1 more job pending
+257ms ╚Event processed successfully (257ms)
29.3.2022, 22:52:02 +102ms
+1ms ╔Received event [Mitt hjem].time = 1648587123693 with a delay of -1591ms
+62ms ║RunTime Analysis CS > 32ms > PS > 5ms > PE > 24ms > CE
+64ms ║Runtime (41997 bytes) successfully initialized in 5ms (v0.3.114.20220203) (63ms)
+65ms ║╔Execution stage started
+95ms ║║Executed virtual command [Bad 2 Thermostat].sendPushNotification (11ms)
+165ms ║║Executed physical command [Bad 2 Thermostat].quickSetHeat([24.0]) (66ms)
+166ms ║║Executed [Bad 2 Thermostat].quickSetHeat (68ms)
+170ms ║║Executed virtual command [Bad 2 Thermostat].wait (0ms)
+171ms ║║Requesting a wake up for Tue, Mar 29 2022 @ 10:53:02 PM CEST (in 60.0s)
+178ms ║╚Execution stage complete. (113ms)
+180ms ║Setting up scheduled job for Tue, Mar 29 2022 @ 10:53:02 PM CEST (in 59s), with 2 more jobs pending
+225ms ╚Event processed successfully (224ms)
29.3.2022, 22:51:02 +70ms
+1ms ╔Received event [Mitt hjem].time = 1648587063389 with a delay of -1319ms
+44ms ║RunTime Analysis CS > 19ms > PS > 7ms > PE > 18ms > CE
+47ms ║Runtime (41997 bytes) successfully initialized in 7ms (v0.3.114.20220203) (45ms)
+48ms ║╔Execution stage started
+110ms ║║Executed virtual command [Bad 2 Thermostat].sendPushNotification (12ms)
+1615ms ║║Executed physical command [Bad 2 Thermostat].quickSetHeat([24.0]) (1500ms)
+1616ms ║║Executed [Bad 2 Thermostat].quickSetHeat (1502ms)
+1620ms ║║Executed virtual command [Bad 2 Thermostat].wait (0ms)
+1622ms ║║Requesting a wake up for Tue, Mar 29 2022 @ 10:52:03 PM CEST (in 60.0s)
+1645ms ║╚Execution stage complete. (1596ms)
+1647ms ║Setting up scheduled job for Tue, Mar 29 2022 @ 10:52:03 PM CEST (in 59s), with 2 more jobs pending
+1654ms ╚Event processed successfully (1654ms)
29.3.2022, 22:49:59 +42ms
+1ms ╔Received event [Mitt hjem].time = 1648587000000 with a delay of -958ms
+93ms ║RunTime Analysis CS > 42ms > PS > 6ms > PE > 45ms > CE
+96ms ║Runtime (41996 bytes) successfully initialized in 6ms (v0.3.114.20220203) (94ms)
+98ms ║╔Execution stage started
+123ms ║║Comparison (decimal) 20.0 is_different_than (integer) 24 = true (2ms)
+125ms ║║Condition #6 evaluated true (11ms)
+126ms ║║Condition group #5 evaluated true (state did not change) (13ms)
+128ms ║║Cancelling statement #7’s schedules…
+4340ms ║║Executed physical command [Bad 2 Thermostat].quickSetHeat([24.0]) (4208ms)
+4341ms ║║Executed [Bad 2 Thermostat].quickSetHeat (4210ms)
+4345ms ║║Executed virtual command [Bad 2 Thermostat].wait (1ms)
+4347ms ║║Requesting a wake up for Tue, Mar 29 2022 @ 10:51:03 PM CEST (in 60.0s)
+4377ms ║╚Execution stage complete. (4280ms)
+4379ms ║Setting up scheduled job for Tue, Mar 29 2022 @ 10:51:03 PM CEST (in 59s), with 2 more jobs pending
+4416ms ╚Event processed successfully (4416ms)

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.

[WCmore]

When I want to wait - and then recheck the status of something, I usually add an indented Conditional IF inside… (after the wait)

Normally, we do not want the entire set of IFs to be checked again.
(I realize you only have one level here, but the logic remains)

---

Turning on Trace, and setting Log Level to Full will show you exactly what is checked upon returning from the wait. (Notice that "Condition #6" is only checked during the initial run)

[kunjila88]

Thanks,

Sure, if you add several more IF’s every time you try to set again/send push it works well, also works well with exit function … but I thought this as a more elegant solution, but really can’t see why it’s not working. Am I missing something, doing something wrong or there is some unexpected behaviour here?

Oh well, time for bed, getting close to midnight here … continuing tomorrow

[eibyer]

Not sure if you have Advanced Statements enabled, maybe try a While or Repeat loop with an exit after a specified number of attempts.

[orangebucket]

TCP set to on condition state. Why is scheduling after 60s not canceled if the condition is not fulfilled anymore? Could be because of every (TOD) triggers?

Yes and no. It is more that TCP doesn’t work like you need it to.

TCP takes effect when a new instance of the piston evaluates a condition and finds the result has changed since it was last evaluated by a previous instance. Your piston only evaluates the condition when the every block is fired.

Nothing magical happens at the end of a wait. All that happens is a new piston starts up and either immediately exits if the ‘scheduled task’ was cancelled, or fast forwards to where an earlier one left off.

The mechanism in play is that a long wait (over five seconds is always long) causes a timer to be set and the piston to exit (this is called a ‘scheduled task’). If the piston is fired during this waiting period it will run again from scratch and TCP might decide the ‘scheduled task’ is no longer needed. If there isn’t a long wait in progress or the piston doesn’t get fired then TCP isn’t a factor.

I’d suggest exploiting TCP really isn’t the best solution in this case.

[kunjila88]

Sure, I tried with While already, it’s working just fine, however I don’t want to repeat same push notification each time

As mentioned Exit works fine as well

[kunjila88]

TCP takes effect when a new instance of the piston evaluates a condition and finds the result has changed since it was last evaluated by a previous instance. Your piston only evaluates the condition when the every block is fired.

By new instance of a piston you mean new execution (running through entire code)?
So evaluation happens only when the evry is triggered, and since there aren’t any triggers in the meantime to re-evaluate again, the scheduled task doesn’t cancel, right? I tried now taking away the every (TOD) activation, only used if/then part and executed the pistopn with test, same issue still present

Nothing magical happens at the end of a wait. All that happens is a new piston starts up and either immediately exits if the ‘scheduled task’ was cancelled, or fast forwards to where an earlier one left off.

Not sure if I follow here. At the end of wait no new evaluation is performed and the code continues since the task is not canceled, you don’t start the new piston from the beginning, but continuing where you left of (I use synchronous)

The mechanism in play is that a long wait (over five seconds is always long) causes a timer to be set and the piston to exit (this is called a ‘scheduled task’). If the piston is fired during this waiting period it will run again from scratch and TCP might decide the ‘scheduled task’ is no longer needed. If there isn’t a long wait in progress or the piston doesn’t get fired then TCP isn’t a factor.

I think this last part kinda confirms what I wrote/asked upsatairs?
Longer wait will exit the execution and continue where it left off after the time elapses if no re-evaluation with false result is done during the waiting period?

This also explaines why my previous code with turning off lights after 30s of no motion worked as intended. The execution is re-triggered if the motion is detected again and re-evaluated which cancels the scheduled task/wait.

As you implied, when you use every, it triggers on TOD (in my case), there are no device triggers and therefore wait is not suitable in this case if you want TCP to kick in

Thank you very much for explanation. I hope I understand this wait better now

[kunjila88]

For the record, here is the piston that works flawlessly.

I used If nesting to avoid evalating too many statements if not neccessary. I wanted to avoid Exit since the piston is in auto and Exit 0 (null) still gives me some error in the log, although it does execute!