Piston to turn on light when doorbell is pressed at night and turn it off 2 mins later

#1

1) Give a description of the problem
I have attempted to create a piston to turn on a light 10 seconds after my Ring Doorbell is pressed when it is between sunset and sunrise and then turn it off 2 mins later. A copy of the piston is shown below.

2) What is the expected behaviour?
The light should come on 10 seconds after the doorbeel is pressed (assuming that it is between 30 mins before Sunset and 30 mins after sunrise). The light should stay on for 2 mins and then shut off.

3) What is happening/not happening?
Everything happens correctly, except the light does not shut off. I have moved the wait and off statements around trying to get them to function correctly with no success.

4) Post a Green Snapshot of the pistonimage

image
image.png1178Ă—635 14.1 KB

5) Attach logs after turning logging level to Full
(PASTE YOUR LOGS HERE THEN HIGHLIGHT ALL OF THE LOGS AND CLICK ON THE </> ICON TO FORMAT THEM CORRECTLY)

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.

#2

Sorry I didn’t post the logs. Here they are:
10/23/2019, 7:55:15 AM +95ms
+0ms â•”Received event [Home].time = 1571831716502 with a delay of -1408ms
+168ms â•‘RunTime Analysis CS > 63ms > PS > 88ms > PE > 17ms > CE
+171ms â•‘Runtime (37336 bytes) successfully initialized in 88ms (v0.3.110.20191009) (170ms)
+172ms â•‘â•”Execution stage started
+174ms â•‘â•šExecution stage complete. (1ms)
+175ms â•šEvent processed successfully (175ms)
10/23/2019, 7:53:37 AM +151ms
+2ms â•”Received event [Front Door].button = default with a delay of 57ms
+72ms â•‘RunTime Analysis CS > 18ms > PS > 41ms > PE > 13ms > CE
+75ms â•‘Runtime (37328 bytes) successfully initialized in 41ms (v0.3.110.20191009) (73ms)
+76ms â•‘â•”Execution stage started
+111ms ║║Comparison (time) 28417231 is_between (time) 1571871300000 … (time) 1571831400000 = true (9ms)
+113ms â•‘â•‘Time restriction check passed
+115ms â•‘â•‘Condition #3 evaluated true (35ms)
+116ms â•‘â•‘Condition group #1 evaluated true (state did not change) (37ms)
+120ms â•‘â•‘Comparison (enum) default gets (string) pushed = false (1ms)
+121ms ║║Cancelling condition #2’s schedules…
+122ms â•‘â•‘Condition #2 evaluated false (5ms)
+123ms ║║Cancelling condition #1’s schedules…
+124ms â•‘â•‘Condition group #1 evaluated false (state changed) (7ms)
+131ms â•‘â•šExecution stage complete. (55ms)
+132ms â•šEvent processed successfully (132ms)
10/23/2019, 7:53:16 AM +109ms
+1ms â•”Received event [Home].time = 1571831597512 with a delay of -1403ms
+348ms â•‘RunTime Analysis CS > 56ms > PS > 278ms > PE > 13ms > CE
+350ms â•‘Runtime (37332 bytes) successfully initialized in 278ms (v0.3.110.20191009) (349ms)
+351ms â•‘â•”Execution stage started
+379ms â•‘â•‘Executed physical command [Foyer Light].on() (16ms)
+381ms â•‘â•‘Executed [Foyer Light].on (18ms)
+385ms ║║Cancelling statement #7’s schedules…
+390ms â•‘â•‘Executed virtual command [Foyer Light].wait (0ms)
+392ms â•‘â•‘Requesting a wake up for Wed, Oct 23 2019 @ 7:55:16 AM EDT (in 120.0s)
+401ms â•‘â•šExecution stage complete. (49ms)
+403ms â•‘Setting up scheduled job for Wed, Oct 23 2019 @ 7:55:16 AM EDT (in 119.991s)
+411ms â•šEvent processed successfully (411ms)
10/23/2019, 7:53:07 AM +379ms
+2ms â•”Received event [Front Door].button = pushed with a delay of 54ms
+74ms â•‘RunTime Analysis CS > 19ms > PS > 42ms > PE > 13ms > CE
+76ms â•‘Runtime (37333 bytes) successfully initialized in 42ms (v0.3.110.20191009) (74ms)
+77ms â•‘â•”Execution stage started
+109ms ║║Comparison (time) 28387461 is_between (time) 1571871300000 … (time) 1571831400000 = true (9ms)
+110ms â•‘â•‘Time restriction check passed
+112ms â•‘â•‘Condition #3 evaluated true (30ms)
+113ms ║║Cancelling condition #1’s schedules…
+114ms â•‘â•‘Condition group #1 evaluated true (state changed) (33ms)
+120ms â•‘â•‘Comparison (enum) pushed gets (string) pushed = true (3ms)
+122ms ║║Cancelling condition #2’s schedules…
+123ms â•‘â•‘Condition #2 evaluated true (8ms)
+124ms â•‘â•‘Condition group #1 evaluated true (state did not change) (9ms)
+126ms ║║Cancelling statement #4’s schedules…
+131ms â•‘â•‘Executed virtual command [Foyer Light].wait (1ms)
+132ms â•‘â•‘Requesting a wake up for Wed, Oct 23 2019 @ 7:53:17 AM EDT (in 10.0s)
+140ms â•‘â•šExecution stage complete. (63ms)
+142ms â•‘Setting up scheduled job for Wed, Oct 23 2019 @ 7:53:17 AM EDT (in 9.992s)
+153ms â•šEvent processed successfully (152ms)

#3

There are many options here. You can set TCP (Task Cancellation Policy) to Never at your second WITH.

#4

Sorry, I meant Task Cancellation Policy.

#5

this guys knows, and its how I always handle things like this, works perfectly for me

#6

Thanks - I am still on the early part of the learning curve with WebCoRE. I’m not sure what these changes actually did, but they fixed the issue and the piston not works as desired. Thanks for your support.

#7

If you do a google search, you will get a better explanation than I can give but in summary it prevents any changes to the trigger during the current execution causing the current run to stop and restart.

#8

All of us here are learning :smile:
I will try to explain why the TCP works (as I understand it)…
The 2 minute wait that you have gives the pressed doorbell button time to reset to not-pressed. The doorbell button is your trigger for the piston (see the orange lightening bolt next to it). When the state of your trigger changes (back to not-pressed), it causes the piston to halt where it is and start running from the top again. That happens before your Turn off command. So now your doorbell button is NOT pressed and the THEN statements do not get executed.

With the TCP set the Never, the piston completes execution even though the trigger is reset. And then the OFF command is executed.

#9

If my answer worked for you, please check the solution box. Thanks.

#10

Thanks Pantheon - that explanation makes sense. I guess I didn’t realize that the state of the button was being continually evaluated and in essence the “if” statement is being continually evaluated to determine if the “then” actions should proceed. My thinking was that once the button was pressed and the “if” condition was satisfied that all the “then” actions would proceed. I guess if I had made the wait longer than 10 seconds before the light turned on, it might also have a chance to reset and it wouldn’t even turn the light on. As much as things change with these systems, would it make sense to also set the TCP for the first “With” to “Never” as well?

#11

Many of us here do just that. There are reasons why you would not want to do that. Do a quick search in this forum and you will find plenty of information about both.

#12

I knew someone would be able to explain it better than me… thanks for that.

#13

That makes sense and now that I understand what it is doing and what it is called (Task Cancellation Policy (TCP)). I will do some further searching to better understand how and when to make various settings.

This was my first piston and I wanted to start with something simple, so I started with something easy like turning a light on when the doorbell is pressed. It was so simple and worked so well that I started to add more intelligence, so making sure it would only come on when it was dark and having it wait 10 seconds before turning on the light to make it look more like someone is home. All of that worked so well that I went for the final step on turning off the light and given the success in the other modifications, I couldn’t figure out why this one wouldn’t work. I guess I found the limits of my current knowledge. Time to go expand those limits.

#14

It’s quite fun, right? Welcome to the party!!

#15

Yeah - I spent a long time trying to get this automation to work in SmartThings with no success. The Smart Lighting app will allow the button to turn the lights on when it’s dark out, but it won’t turn the lights off, unless you set the button to toggle and then you would have to ring the doorbell again to turn the lights off. Then I tried a custom automation, it would allow the lights to turn off after 2 mins, but the sunset and sunrise times don’t work in the custom automations, so this made it happen all of the time. WebCoRE was almost as easy as the automations in the SmartThings app and it actually worked. I may be staying at this party for a while, thanks for the hearty welcome.[