Piston is waiting forever

#1

1) Give a description of the problem
A piston I have is not ever coming back after a wait command. I can see in the trace that the little timer on the side counts down to zero, then starts counting up. I’ve seen it count up to at least 20 minutes with no action.

Line 64 in the screenshot is the wait that never ends.

2) What is the expected behavior?
Motion sensor leads to temperature set point increasing on thermostat, no motion for 5 minutes straight should lead to temperature set point going back down.

3) What is happening/not happening?
Motion going active does correctly increase temperature. Motion going inactive leads to a wait of forever.

4) Post a Green Snapshot of the pistonimage

image
image.png1178×1296 121 KB

5) Attach any logs (From ST IDE and by turning logging level to Full)
Piston log after motion ends:

11/11/2017, 5:23:19 PM +723ms
+2ms ╔Received event [Dining Room Motion].motion = inactive with a delay of 743ms
+238ms ║RunTime Analysis CS > 25ms > PS > 60ms > PE > 153ms > CE
+247ms ║Runtime (43371 bytes) successfully initialized in 60ms (v0.2.0fe.20171109) (244ms)
+248ms ║╔Execution stage started
+260ms ║║Comparison (enum) inactive changes_to (string) active = false (1ms)
+261ms ║║Cancelling condition #7’s schedules…
+262ms ║║Condition #7 evaluated false (8ms)
+263ms ║║Cancelling condition #1’s schedules…
+264ms ║║Condition group #1 evaluated false (state changed) (10ms)
+270ms ║║Comparison (enum) inactive changes_to (string) inactive = true (1ms)
+271ms ║║Condition #45 evaluated true (6ms)
+275ms ║║Comparison (string) :bdfe9ed4e2f580477959f6aad70afed8: is_not (string) :903067b9f3300216dcb5059e039edcb8: = true (1ms)
+277ms ║║Condition #46 evaluated true (5ms)
+278ms ║║Condition group #44 evaluated true (state did not change) (13ms)
+280ms ║║Cancelling statement #59’s schedules…
+283ms ║║Executed virtual command setState (0ms)
+285ms ║║Cancelling statement #36’s schedules…
+290ms ║║Executed virtual command [Dining Room Thermostat].wait (0ms)
+291ms ║║Requesting a wake up for Sat, Nov 11 2017 @ 5:28:20 PM CST (in 300.0s)
+296ms ║╚Execution stage complete. (47ms)
+313ms ╚Event processed successfully (312ms)

No other logged events after this (even after waiting much more than 5 minutes) until the next time you walk into the room and get another motion = active event.
.

#2

First let’s try the “never cancel” Task Cancellation Policy for this else if. I think that the “changes to” condition will evaluate to false before your 5 minute timer completes, so the else if gets cancelled.

#3

I will certainly try it.

Desired behavior is that if there is motion again in the 5 minute window, then the temperature adjustment is cancelled and re-scheduled for 5 minutes after the motion detector goes inactive again. If I do “Never” for task cancellation, I won’t have that, right? Any other good way to get that back?

I’d also like to understand task cancellation better, then. My understanding is that the “changes to inactive” condition will only become false if there’s a “changes to active” even that happens. Is that not true? Is “changes to inactive” false after a short time just because nothing is changing anymore?

#4

That is my understanding, whereas “is inactive” will remain true. After looking at your piston more closely you may just need to change the conditions from “changes to” to “is” – the conditions should still trigger whenever the motion changes.

#5

Yep, that worked perfectly! Looks like using a “changes” trigger means not using a wait.