Another 'Wait' issue

[mstevenson78]

1) Give a description of the problem
Morning all,

I, like others, am struggling with the ‘wait’ command. I have a piston that manages the porch light, it turns it on at 15% at sunset and off at 11:30pm.

I also have a trigger in there that if the Ring doorbell detects motion between sunset and sunrise, the brightness is set to 100% for 2 minutes, then it reverts back to its original setting (so 15% between sunset and 11:30pm, and off between 11:30pm and sunrise).

This issue I am having is that the light is going back to 15% as soon as the Ring doorbell is sending a motion=inactive which is about 30 seconds after sending a motion=active.

After reading through the forum, I did find info regarding the Task Cancellation Policy, which I have now set on the with statement that contains the wait command, but it doesn’t appear to have made any difference.

I have also tweak the motion detection from ‘is active’ to ‘changes to active’ but again with no success.

Any help would be much appreciated.

Thanks,

Mark

2) What is the expected behavior?

I hoped the wait command would effectively pause the piston for 2 minutes with the light on 100% before running again.

3) What is happening/not happening?

The piston is firing again when the motion=inactive is sent from the doorbell and resetting the light to 15% before the 2 minute wait has completed.

4) Post a Green Snapshot of the piston

(

)

5) Attach any logs

(4/24/2018, 9:02:37 PM +208ms
+1ms	╔Received event [Home].time = 1524600157565 with a delay of -357ms
+205ms	║RunTime Analysis CS > 17ms > PS > 49ms > PE > 139ms > CE
+208ms	║Runtime (39649 bytes) successfully initialized in 49ms (v0.3.104.20180323) (206ms)
+209ms	║╔Execution stage started
+235ms	║║Comparison (string) on is (string) off = false (2ms)
+237ms	║║Cancelling condition #19's schedules...
+238ms	║║Condition #19 evaluated false (7ms)
+239ms	║║Cancelling condition #14's schedules...
+240ms	║║Condition group #14 evaluated false (state changed) (9ms)
+243ms	║║Cancelling statement #15's schedules...
+254ms	║║Skipped execution of physical command [Porch].setLevel([15]) because it would make no change to the device. (6ms)
+255ms	║║Executed [Porch].setLevel (7ms)
+259ms	║╚Execution stage complete. (49ms)
+260ms	╚Event processed successfully (260ms)
4/24/2018, 9:01:07 PM +126ms
+1ms	╔Received event [Leam Rd].motion = inactive with a delay of 92ms
+158ms	║RunTime Analysis CS > 11ms > PS > 32ms > PE > 114ms > CE
+160ms	║Runtime (39640 bytes) successfully initialized in 32ms (v0.3.104.20180323) (158ms)
+161ms	║╔Execution stage started
+214ms	║║Comparison (time) 75667292 is_between (time) 1524597540000 .. (time) 84600000 = true (8ms)
+215ms	║║Time restriction check passed
+216ms	║║Condition #4 evaluated true (50ms)
+217ms	║║Condition group #1 evaluated true (state did not change) (51ms)
+219ms	║║Cancelling statement #2's schedules...
+235ms	║║Executed physical command [Porch].setLevel([15]) (11ms)
+236ms	║║Executed [Porch].setLevel (13ms)
+242ms	║║Comparison (enum) inactive changes_to (string) active = false (0ms)
+244ms	║║Cancelling condition #6's schedules...
+244ms	║║Condition #6 evaluated false (5ms)
+245ms	║║Cancelling condition #5's schedules...
+246ms	║║Condition group #5 evaluated false (state changed) (7ms)
+249ms	║╚Execution stage complete. (88ms)
+250ms	║Setting up scheduled job for Tue, Apr 24 2018 @ 9:02:37 PM BST (in 90.19s)
+260ms	╚Event processed successfully (259ms)
4/24/2018, 9:00:37 PM +276ms
+1ms	╔Received event [Leam Rd].motion = active with a delay of 62ms
+161ms	║RunTime Analysis CS > 12ms > PS > 32ms > PE > 116ms > CE
+163ms	║Runtime (39647 bytes) successfully initialized in 32ms (v0.3.104.20180323) (161ms)
+164ms	║╔Execution stage started
+215ms	║║Comparison (time) 75637446 is_between (time) 1524597540000 .. (time) 84600000 = true (8ms)
+216ms	║║Time restriction check passed
+218ms	║║Condition #4 evaluated true (48ms)
+219ms	║║Condition group #1 evaluated true (state did not change) (50ms)
+221ms	║║Cancelling statement #2's schedules...
+232ms	║║Skipped execution of physical command [Porch].setLevel([15]) because it would make no change to the device. (7ms)
+232ms	║║Executed [Porch].setLevel (7ms)
+239ms	║║Comparison (enum) active changes_to (string) active = true (0ms)
+241ms	║║Cancelling condition #6's schedules...
+241ms	║║Condition #6 evaluated true (5ms)
+254ms	║║Comparison (time) 75637518 is_between (time) 1524597540000 .. (time) 1524545400000 = true (8ms)
+255ms	║║Time restriction check passed
+256ms	║║Condition #7 evaluated true (14ms)
+257ms	║║Cancelling condition #5's schedules...
+258ms	║║Condition group #5 evaluated true (state changed) (23ms)
+260ms	║║Cancelling statement #10's schedules...
+269ms	║║Executed virtual command [Porch].setVariable (3ms)
+284ms	║║Executed physical command [Porch].setLevel([100]) (12ms)
+285ms	║║Executed [Porch].setLevel (14ms)
+288ms	║║Executed virtual command [Porch].wait (1ms)
+289ms	║║Requesting a wake up for Tue, Apr 24 2018 @ 9:02:37 PM BST (in 120.0s)
+293ms	║╚Execution stage complete. (129ms)
+294ms	║Setting up scheduled job for Tue, Apr 24 2018 @ 9:02:37 PM BST (in 119.995s)
+302ms	╚Event processed successfully (302ms))

REMOVE BELOW AFTER READING

[TN_Oldman]

I’m reading this on my phone so little difficult. 1st thing I notice is you have 2 time ‘if’ conditions that are essentially the same. Except one also includes motion.

So without looking at everything else it seems to me when it detects motion it does the brighter setting in that “if” then when motion ends it does the settings in the other “if”

Only time period they do not conflict in from 11:31 pm to 15 past sunrise.

I had a hard time following the rest of your piston. I am not very good at Webcore so I have a hard time following some pistons logic.

[Bry]

I did a quick read. The first thing that hit me is your 2nd IF has a nested IF, which is generally not advisable.

I think it’s reverting because the 1st IF turn-on event is conditional, not a trigger. You could try changing it to a trigger, or do something with a variable to define when the light is supposed to be a full brightness.

[mstevenson78]

ndition #4 evaluated true (50ms)

Hi,

Thanks for coming back to me. After looking again at the script, the nested if wasn’t actually required so I have removed it.

I still have the issue though where the wait isn’t actually waiting. When the script runs, the first if checks if the light needs to be on or not. It will then hit the second if and checks if there has been motion or not. Those parts are working fine.

What I want it to do next though is if motion is detected, turn the light to 100% for 2 minutes. After the two minutes is up, it can run through the piston again, and the first if will dictate if the light should be on or not (hence removing the nested if).

What I am seeing though is the wait is not pausing the piston, so when the doorbell sends a motion=inactive, the script is running again and the light is being set in accordance with the first if. This is what I want it to do, but only after the 2 minutes wait.

So I guess the first thing to check is that my interpretation of the wait command is correct; should it stop everything else running while the wait ticks down. Second thing to check is my understanding of the Task Cancellation Policy; by setting that to none, should this mean even when the motion=inactive trigger comes through, should it prevent that from overriding the wait?

Below is my new piston and the logs (ignore the times set for the light to come on, I have modified those so I can test it in daylight)

4/25/2018, 2:49:24 PM +152ms
+0ms	╔Received event [Home].time = 1524664164812 with a delay of -661ms
+152ms	║RunTime Analysis CS > 14ms > PS > 45ms > PE > 94ms > CE
+154ms	║Runtime (38518 bytes) successfully initialized in 45ms (v0.3.104.20180323) (153ms)
+155ms	║╔Execution stage started
+171ms	║╚Execution stage complete. (16ms)
+172ms	╚Event processed successfully (172ms)
4/25/2018, 2:47:54 PM +93ms
+1ms	╔Received event [Leam Rd].motion = inactive with a delay of 54ms
+161ms	║RunTime Analysis CS > 13ms > PS > 39ms > PE > 109ms > CE
+164ms	║Runtime (38510 bytes) successfully initialized in 39ms (v0.3.104.20180323) (161ms)
+165ms	║╔Execution stage started
+214ms	║║Comparison (time) 53274263 is_between (time) 1524631680000 .. (time) 84600000 = true (7ms)
+215ms	║║Time restriction check passed
+217ms	║║Condition #4 evaluated true (47ms)
+218ms	║║Condition group #1 evaluated true (state did not change) (49ms)
+220ms	║║Cancelling statement #2's schedules...
+237ms	║║Executed physical command [Porch].setLevel([15]) (13ms)
+238ms	║║Executed [Porch].setLevel (14ms)
+244ms	║║Comparison (enum) inactive changes_to (string) active = false (0ms)
+246ms	║║Cancelling condition #6's schedules...
+247ms	║║Condition #6 evaluated false (5ms)
+247ms	║║Cancelling condition #5's schedules...
+248ms	║║Condition group #5 evaluated false (state changed) (7ms)
+251ms	║╚Execution stage complete. (87ms)
+253ms	║Setting up scheduled job for Wed, Apr 25 2018 @ 2:49:24 PM BST (in 90.467s)
+263ms	╚Event processed successfully (262ms)
4/25/2018, 2:47:24 PM +538ms
+2ms	╔Received event [Leam Rd].motion = active with a delay of 59ms
+159ms	║RunTime Analysis CS > 13ms > PS > 37ms > PE > 109ms > CE
+162ms	║Runtime (38515 bytes) successfully initialized in 37ms (v0.3.104.20180323) (159ms)
+162ms	║╔Execution stage started
+210ms	║║Comparison (time) 53244706 is_between (time) 1524631680000 .. (time) 84600000 = true (7ms)
+211ms	║║Time restriction check passed
+213ms	║║Condition #4 evaluated true (46ms)
+214ms	║║Condition group #1 evaluated true (state did not change) (46ms)
+216ms	║║Cancelling statement #2's schedules...
+226ms	║║Skipped execution of physical command [Porch].setLevel([15]) because it would make no change to the device. (5ms)
+226ms	║║Executed [Porch].setLevel (7ms)
+232ms	║║Comparison (enum) active changes_to (string) active = true (0ms)
+234ms	║║Cancelling condition #6's schedules...
+234ms	║║Condition #6 evaluated true (5ms)
+245ms	║║Comparison (time) 53244773 is_between (time) 1524631680000 .. (time) 1524684060000 = true (7ms)
+246ms	║║Time restriction check passed
+248ms	║║Condition #7 evaluated true (12ms)
+249ms	║║Cancelling condition #5's schedules...
+249ms	║║Condition group #5 evaluated true (state changed) (20ms)
+251ms	║║Cancelling statement #10's schedules...
+269ms	║║Executed physical command [Porch].setLevel([100]) (14ms)
+269ms	║║Executed [Porch].setLevel (15ms)
+272ms	║║Executed virtual command [Porch].wait (0ms)
+273ms	║║Requesting a wake up for Wed, Apr 25 2018 @ 2:49:24 PM BST (in 120.0s)
+277ms	║╚Execution stage complete. (115ms)
+279ms	║Setting up scheduled job for Wed, Apr 25 2018 @ 2:49:24 PM BST (in 119.996s)
+288ms	╚Event processed successfully (288ms)

[bobbles]

You haven’t got a turn off after the wait 2 minutes.

[TN_Oldman]

stop everything else running while the wait ticks down

I don’t believe this is true. I had a mailbox piston with a wait in it. The piston would continue to evaluate while in the wait time. Let me find the thread I posted about it. Someone shared info that explained it better there.

[TN_Oldman]

See this thread, it was what was linked to in my thread. It made sense to me after that.

Second Half of Piston Not Firing - Solved

Waits combined with triggers can get tricky. The way your piston is written, this is what happens: One of your presence sensors arrives (changes to present), so your condition evaluates true. Your piston has a wait for 5 minutes, so it sets a wake-up time for itself 5 minutes in the future. After 5 minutes, your piston wakes up and executes from the top. Since your presence sensor has been present for some time, the “changes to present” no longer evaluates true and your piston skips completin…

[WCmore]

Here is how I would do it:

(Lines 57-64 are likely not needed, but they are there to make sure the light is off during the day)

[michicago]

I tried to trim it down to a minimum number of statements for you. Basically this does 3 discrete things:

Turns the lights on at 15% before sunset.

If motion is detected between sunset and sunrise (with offsets), then it stores the current switch status in variables, turns the lights on at 100% for 2 minutes, then sets the bulbs back to their previous state.

Turns the lights off at 11:30pm.

[mstevenson78]

Thanks all!

Michicago, your solution has done the trick and it is now working perfectly. The one thing I still don’t fully understand is why your wait works and mine didn’t?

The other valuable lesson I learnt here is that I hadn’t set the on or off triggers properly which is why the light was either not coming on at the right time or not going off at the right time.

This completes my first ever piston! Roll on the next one

Thanks again everyone for your help, you’ll all no doubt be hearing from me again as I embark on my next one!

Mark

[michicago]

The one thing I still don’t fully understand is why your wait works and mine didn’t?

Hard to say without a really long analysis on the logs, because of two reasons:

1. You had two discrete IF conditions that could both evaluate true on a single piston run and create some conflicting information being sent to your device.

2. Your trigger wasn’t at the top of the piston. In theory this shouldn’t matter, but in practice I’ve seen a lot of pistons (my own and others on here) return ‘false’ evaluations when they should be ‘true’ if the trigger isn’t the first line of the piston. It has even happened where “If condition and trigger, then do xxx” doesn’t work right, but simply making it “If trigger and condition, then do xxx” works right every time.

I’ve had the best luck with pistons that are written in a way that they send one command given a certain set of criteria. Anytime there are multiple conditions met, things get real ugly, real fast, lol.