Piston with fade stopped updating part way through fade

#1

1) Give a description of the problem
I have a piston that fades in just before sunset so the living room is lit for our dog (she’s a snowflake), but I noticed today that the fade got to 16% and then stopped for both bulbs.

Oddly, the piston gives a countdown of 6+ hours until triggering again, which is odd because it shouldn’t be active for more than 30 minutes while it fades in.

image
image.png828×66 3.74 KB

2) What is the expected behavior?
Should fade from 0 to 100% in 30 minutes, starting 30 minutes from sunset, but only if the lights are not already on.

3) What is happening/not happening?
Fade stops part way through. Seems that the reschedule maybe gets confused.

4) Post a Green Snapshot of the pistonimage

image
image.png1178×650 70.9 KB

5) Attach any logs (From ST IDE and by turning logging level to Full)
I didn’t have logging set to Full when the fade began, and the restriction prevents it from retrying. I’ll have to fiddle with it tonight to see if I can change the trigger to another time to force it to run with logging set to Full.

From WebCoRE I see a lot of re-attempts to run the Piston and it fails because my lights are already on (one of my restrictions).

12/20/2017, 5:26:48 PM +830ms
+109ms	║Piston execution aborted due to restrictions in effect
12/20/2017, 4:24:45 PM +304ms
+100ms	║Piston execution aborted due to restrictions in effect
12/20/2017, 4:08:42 PM +473ms
+99ms	║Piston execution aborted due to restrictions in effect
12/20/2017, 4:08:34 PM +110ms
+106ms	║Piston execution aborted due to restrictions in effect
12/20/2017, 4:02:16 PM +216ms
+111ms	║Piston execution aborted due to restrictions in effect
12/20/2017, 4:02:06 PM +945ms
+116ms	║Piston execution aborted due to restrictions in effect
12/20/2017, 3:56:34 PM +537ms
+10152ms	║Piston waited at a semaphore for 10018ms
+10173ms	║Piston execution aborted due to restrictions in effect
12/20/2017, 3:56:34 PM +412ms
+134ms	║Piston execution aborted due to restrictions in effect

From the device history in ST, though, I can see that the Piston triggered the fade from 0% (at 3:50pm) to 16% (at 3:54pm) and after that it just stopped.

#2

As soon as your lights are turned on, your “and lights are not on” restriction prevents the piston from continuing. At each step in the fade, the piston sets a wake-up time and runs to set a new level for the lights… which includes checking your restrictions again.

#3

Is the whole Piston re-evaluated, or just the restrictions? Maybe it’s just the “only when” on the execute? If I move those in the “only when” to the “if” will that be more reliable? Just curious if the whole “if” block will be re-evaluated again so I’d need another condition in the “if” block to handle when it’s less than at 100% level as opposed to just “on.”

#4

Without full logs it’s hard to tell, but that’s how it reads from what you posted.

I’d try changing from restrictions to just an IF statement and see if that works better.

#5

Will do… thanks for the input

#6

and I’ll enable full logging

#7

I think I figured it out… I was using the “Time” virtual device, and not Date & Time, but comparing to ${sunset} which is Date & Time…

I also changed the “Time is after…” to a “Date & Time happens daily at…”