Piston Assitance for Timers after an event fires

#1

So I have looked at the examples posted and built a few but cant seem to figure out how to get this scenario to work. I am sure I just cant see the forest through the trees at this point.

Upon Presence changing to “Present” Garage door “Opens”, 5 Min later, Door is to CLOSE. I cant figure out how to add the timer to wait 5 min upon the task execution only. I do not have distinct door sensors to reference, so no-way to know the door is open. I just need it to know that it ran this routine N minutes ago and just issue the close command.

Garage doors are Liftmaster using the MyQ Lite SmartApp to integrate. Any insight or direction would be greatly appreciated

#2

IMG_0864
IMG_0864.JPG640×839 105 KB

#3

image
image.png1178×565 49.3 KB

#4

You can scrunch all those actions into the same with.

#5

image
image.png1178×496 44.7 KB

#6

Bingo!

#7

The live test will be tonight when i pull in, I paused my original CORE piston and this one is now active :slight_smile:

Really appreciate the clarity offered.

#8

Of course. That is why we are here. Let me know how it goes. If you haven’t already then logging to full incase something doesn’t work and we can check out the logs

#9

Worked flawlessly on first run, I am building all my other CORE Pistons now on webCoRE

woohoo

#10

Great to hear!! Best of luck with the rest of them

#11

Can I hijack this thread a bit and ask a programming questions with regards to the code here?

I will assume yes :wink:

Okay … I see the “N”. I get that this means “Never Cancel”.

What is “never cancelled”?

#12

When you delay actions in any way (by running tasks that take time - like Flash or Fade, or when using Wait) those next tasks are “scheduled” to execute after the current time-taking task finishes. By default, if the condition that triggered the execution of the current time-taking task changes, the wait is automatically canceled and the following tasks will no longer execute. The Task Cancellation Policy is in charge of that, and when manually set to Never Cancel, the condition change will allow the already scheduled tasks to continue as if nothing happened. For example, assuming the pseudo code below:

if
   motion is active
then
   wait 1 minute
   raise an alarm
end if

If the motion stops within 1 minute, the alarm is canceled (will never happen). If TCP is set to Never Cancel, then regardless of the motion stopping or not, the alarm will be raised 1 minute after motion was detected. Makes sense?

#13

So in this case … if the person arrives at noon:

  1. The door opens
  2. wait 5 minutes
  3. at 12:05 closes.

Now lets say the person leaves at 12:02 and then comes back at 12:10.

Will the following have happened:

Noon: arrives
Noon: Door opens
12:02: leaves
12:05: Door closes (Because this was “never cancel”)
12:10: arrives
12:10: Door opens
12:15: Door closes

(This is assuming there are no other events going on.)

#14

That is correct.

#15

Great!

Follow up question.

Without never cancel would the following happen?

Noon: arrives
Noon: Door opens
12:02: leaves
12:02: All other events cancelled

Hence, in theory any subsequent presence event regardless of leave or arrive would cancel the remaining events.

Do I have this right also?

#16

That is right, except a new arrival would trigger the whole open / wait / close again.

#17

Okay … allow multiple schedules.

If allow multiple schedules was used instead …

Person 1 arrives at noon. Person 2 arrives at 12:02.

Can you describe what would happen?

#18

When coupled with never cancel, the door would close 5 minutes after each arrival regardless of departures. By default, an action will automatically cancel its own pending tasks and reschedule them. That allow multiple schedules simply inhibits this behavior.

#19

Can you give examples of differences between allow multiple schedules and never cancel. I am trying to wrap my head around how they are different.

#20

image
image.png1178×531 49.2 KB

So this routine would always cancel the schedule on the “WAIT” and never shut the light off even though motion would clear on the sensor within the 5 minute wait.

I switched to:

image
image.png1178×496 43.9 KB

So now on Event instead of using an IF statement, it respects the schedule and will shut the light in the time window. I am trying to understand why one works and one does not so I can better plan my routines out. Here is the log of the second one working.

8/25/2017, 10:45:59 PM +97ms
+1ms╔Received event [Driftwood Point].time = 1503719160540 with a delay of -1444ms
+99ms║RunTime Analysis CS > 23ms > PS > 54ms > PE > 23ms > CE
+110ms║Runtime (34271 bytes) successfully initialized in 54ms (v0.2.0e5.20170812) (108ms)
+112ms║╔Execution stage started
+161ms║║Executed physical command [Pantry Pot Lights].off() (24ms)
+162ms║║Executed [Pantry Pot Lights].off (28ms)
+169ms║╚Execution stage complete. (57ms)
+178ms╚Event processed successfully (177ms)
8/25/2017, 10:43:00 PM +415ms
+1ms╔Received event [MS6 - Pantry].motion = inactive with a delay of 148ms
+80ms║RunTime Analysis CS > 18ms > PS > 40ms > PE > 23ms > CE
+92ms║Runtime (34263 bytes) successfully initialized in 40ms (v0.2.0e5.20170812) (89ms)
+93ms║╔Execution stage started
+108ms║║Cancelling statement #2’s schedules…
+116ms║║Skipped execution of physical command [Pantry Pot Lights].on([]) because it would make no change to the device. (4ms)
+117ms║║Executed [Pantry Pot Lights].on (6ms)
+123ms║║Executed virtual command [Pantry Pot Lights].wait (0ms)
+124ms║║Requesting a wake up for Fri, Aug 25 2017 @ 10:46:00 PM CDT (in 180.0s)
+133ms║╚Execution stage complete. (40ms)
+135ms║Setting up scheduled job for Fri, Aug 25 2017 @ 10:46:00 PM CDT (in 179.991s)
+149ms╚Event processed successfully (149ms)
8/25/2017, 10:41:59 PM +126ms
+1ms╔Received event [MS6 - Pantry].motion = active with a delay of 163ms
+299ms║RunTime Analysis CS > 19ms > PS > 52ms > PE > 228ms > CE
+309ms║Runtime (34255 bytes) successfully initialized in 52ms (v0.2.0e5.20170812) (307ms)
+310ms║╔Execution stage started
+347ms║║Cancelling statement #2’s schedules…
+403ms║║Executed physical command [Pantry Pot Lights].on() (34ms)
+404ms║║Executed [Pantry Pot Lights].on (37ms)
+410ms║║Executed virtual command [Pantry Pot Lights].wait (1ms)
+412ms║║Requesting a wake up for Fri, Aug 25 2017 @ 10:44:59 PM CDT (in 180.0s)
+420ms║╚Execution stage complete. (110ms)
+423ms║Setting up scheduled job for Fri, Aug 25 2017 @ 10:44:59 PM CDT (in 179.99s)
+441ms╚Event processed successfully (440ms)