Piston stopped scheduling jobs


#1

1) Give a description of the problem
We have this piston that manages some lights based on the time of day and when the location mode is ‘Home’ . We use “time happens at” triggers to schedule the piston to trigger at specified times but lately it’s stopped scheduling the piston. It has scheduled in the past (see logs), but today I noticed it hadn’t been scheduled over the last week or so. I clicked the “Test” button to force it to run and then it suddenly scheduled the piston for tonight. I don’t know what’s causing it to schedule (or not).

2) What is the expected behaviour?
Piston should always be scheduled for the next specified time.

3) What is happening/not happening?
Piston somtimes being scheduled.

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

5) Attach logs after turning logging level to Full
Here’s the log of the last time it successfully scheduled the next job and the very next morning when it stopped scheduling. I have more logs of both cases and can post more if needed

6/17/2022, 5:59:59 AM +311ms
+1ms ╔Received event [Yellowstone].time = 1655463600000 with a delay of -689ms
+66ms ║RunTime Analysis CS > 23ms > PS > 5ms > PE > 37ms > CE
+68ms ║Runtime (40938 bytes) successfully initialized in 5ms (v0.3.113.20210203) (66ms)
+69ms ║╔Execution stage started
+76ms ║║Comparison (string) :55ebcd683ac0a65120c39c0c0f151780: changes_to (string) :ce3d849178225762883d5a9ac15106be: = false (0ms)
+78ms ║║Condition #2 evaluated false (4ms)
+79ms ║║Condition group #1 evaluated false (state did not change) (5ms)
+85ms ║║Comparison (string) :55ebcd683ac0a65120c39c0c0f151780: is (string) :ce3d849178225762883d5a9ac15106be: = false (1ms)
+86ms ║║Condition #9 evaluated false (5ms)
+87ms ║║Condition group #7 evaluated false (state did not change) (6ms)
+92ms ║║Comparison (string) :55ebcd683ac0a65120c39c0c0f151780: is (string) :ce3d849178225762883d5a9ac15106be: = false (1ms)
+93ms ║║Condition #11 evaluated false (5ms)
+94ms ║║Condition group #8 evaluated false (state did not change) (6ms)
+96ms ║╚Execution stage complete. (27ms)
+105ms ╚Event processed successfully (105ms)
6/16/2022, 9:59:59 PM +251ms
+0ms ╔Received event [Yellowstone].time = 1655434800000 with a delay of -750ms
+222ms ║RunTime Analysis CS > 54ms > PS > 8ms > PE > 160ms > CE
+225ms ║Runtime (40940 bytes) successfully initialized in 8ms (v0.3.113.20210203) (224ms)
+227ms ║╔Execution stage started
+237ms ║║Comparison (string) :55ebcd683ac0a65120c39c0c0f151780: changes_to (string) :ce3d849178225762883d5a9ac15106be: = false (1ms)
+239ms ║║Condition #2 evaluated false (5ms)
+241ms ║║Condition group #1 evaluated false (state did not change) (8ms)
+252ms ║║Comparison (string) :55ebcd683ac0a65120c39c0c0f151780: is (string) :ce3d849178225762883d5a9ac15106be: = false (3ms)
+254ms ║║Condition #9 evaluated false (8ms)
+255ms ║║Condition group #7 evaluated false (state did not change) (9ms)
+263ms ║║Comparison (string) :55ebcd683ac0a65120c39c0c0f151780: is (string) :ce3d849178225762883d5a9ac15106be: = false (3ms)
+265ms ║║Condition #11 evaluated false (8ms)
+267ms ║║Condition group #8 evaluated false (state did not change) (10ms)
+272ms ║╚Execution stage complete. (46ms)
+275ms ║Setting up scheduled job for Fri, Jun 17 2022 @ 6:00:00 AM CDT (in 28800s)
+282ms ╚Event processed successfully (282ms)

#2

I would suggest breaking out the IF and Else If into its own If statement and just make sure that the Mode conditions are not subscribed so it doesn’t trigger on mode changes even though it will still evaluate false.

Try it out for a few days and observe if it schedules properly


#3

It works something like this:

When your piston is first started up it will have a delve through your code to find out when it needs to run automatically and it will see that it needs to run at 6am and 10pm. Those are one offs though. From then on it needs to evaluate the time happens daily conditions to create new schedules.

Your time happens daily conditions are the second lines in and groups. If your location is not home those first lines evaluate as false which means the and is false. There is now no need for the piston to look at the second condition so by default it doesn’t bother and so the time happens daily lines aren’t evaluated.

There is a piston setting which tells webCoRE to evaluate all the conditions regardless. That will probably help you.

However it is arguably even better to rearrange the piston so that trigger events always result in the triggers being evaluated without relying on changing that setting.

So that means if the piston is fired at 6am you need it to execute the time happens daily at 6am trigger. If you flip the order of the conditions in the and then it is job done.

Likewise for the time happens daily at 10pm trigger and any other triggers. Your only other trigger is the location changes to home and you are OK with that as it will always be executed.


#4

Thanks for your reply, I’ll got it a shot!
Orangebucket also had some good suggestions, so fingers crossed! I’ll report back in a few days.


#5

Consistent with above advice:


#6

Thank you! That’s exactly what I needed and confirms comments above, excellent!