Unlocking door when someone comes home & walks in front of the Ring doorbell

Rrands1 · 2019-12-18 03:19:51 UTC

1) Give a description of the problem
lock is not unlocking when I get home & walk in range of the Ring doorbell camera

2) What is the expected behaviour?
When my cell comes in range of the WiFi & joins the network (or I come in range of the geofence app), I want a timer to start (for 2 minutes) that waits for motion in front of the Ring camera, and if detected, will unlock the door. If it times out without motion in front of the door, then the door stays locked.

3) What is happening/not happening?
Presence detection works fine, however I am not sure how to write the statements to wait the two minutes for motion in front of the Ring doorbell. I have attached the current piston & logs. The door does not unlock with this as-is.

**4) Post a Green Snapshot of the piston

5) Attach logs after turning logging level to Full
12/17/2019, 7:19:47 PM +169ms
+0ms ╔Received event [Front Doorbell].motion = inactive with a delay of 76ms
+140ms ║RunTime Analysis CS > 44ms > PS > 41ms > PE > 56ms > CE
+143ms ║Runtime (42246 bytes) successfully initialized in 41ms (v0.3.110.20191009) (142ms)
+144ms ║╔Execution stage started
+161ms ║║Condition #5 evaluated false (13ms)
+162ms ║║Condition group #1 evaluated false (state did not change) (15ms)
+203ms ║║Duration 133331895ms for was_not >= 600000ms threshold = true
+204ms ║║Comparison (enum) not present was_not (string) present = true (34ms)
+205ms ║║Condition #27 evaluated true (40ms)
+206ms ║║Condition group #26 evaluated true (state did not change) (42ms)
+214ms ║║Comparison (enum) off is (string) on = false (1ms)
+216ms ║║Condition #29 evaluated false (8ms)
+217ms ║║Condition group #28 evaluated false (state did not change) (9ms)
+219ms ║╚Execution stage complete. (75ms)
+220ms ╚Event processed successfully (219ms)
12/17/2019, 7:19:07 PM +501ms
+1ms ╔Received event [Front Doorbell].motion = active with a delay of 83ms
+121ms ║RunTime Analysis CS > 23ms > PS > 45ms > PE > 53ms > CE
+123ms ║Runtime (42244 bytes) successfully initialized in 45ms (v0.3.110.20191009) (121ms)
+124ms ║╔Execution stage started
+143ms ║║Condition #5 evaluated false (15ms)
+144ms ║║Condition group #1 evaluated false (state did not change) (16ms)
+176ms ║║Duration 133292200ms for was_not >= 600000ms threshold = true
+177ms ║║Comparison (enum) not present was_not (string) present = true (27ms)
+178ms ║║Condition #27 evaluated true (32ms)
+179ms ║║Condition group #26 evaluated true (state did not change) (33ms)
+188ms ║║Comparison (enum) off is (string) on = false (2ms)
+189ms ║║Condition #29 evaluated false (8ms)
+190ms ║║Condition group #28 evaluated false (state did not change) (9ms)
+192ms ║╚Execution stage complete. (68ms)
+193ms ╚Event processed successfully (194ms)
12/17/2019, 3:25:10 PM +114ms
+1ms ╔Received event [Front Doorbell].motion = inactive with a delay of 66ms
+126ms ║RunTime Analysis CS > 26ms > PS > 50ms > PE > 50ms > CE
+129ms ║Runtime (42246 bytes) successfully initialized in 50ms (v0.3.110.20191009) (127ms)
+130ms ║╔Execution stage started
+147ms ║║Condition #5 evaluated false (14ms)
+148ms ║║Condition group #1 evaluated false (state did not change) (15ms)
+180ms ║║Duration 119254817ms for was_not >= 600000ms threshold = true
+181ms ║║Comparison (enum) not present was_not (string) present = true (26ms)
+182ms ║║Condition #27 evaluated true (31ms)
+183ms ║║Condition group #26 evaluated true (state did not change) (33ms)
+192ms ║║Comparison (enum) off is (string) on = false (2ms)
+193ms ║║Condition #29 evaluated false (8ms)
+194ms ║║Condition group #28 evaluated false (state did not change) (9ms)
+196ms ║╚Execution stage complete. (67ms)
+197ms ╚Event processed successfully (197ms)
12/17/2019, 3:24:30 PM +182ms
+1ms ╔Received event [Front Doorbell].motion = active with a delay of 78ms
+122ms ║RunTime Analysis CS > 22ms > PS > 34ms > PE > 65ms > CE
+124ms ║Runtime (42244 bytes) successfully initialized in 34ms (v0.3.110.20191009) (122ms)
+125ms ║╔Execution stage started
+144ms ║║Condition #5 evaluated false (14ms)
+145ms ║║Condition group #1 evaluated false (state did not change) (16ms)
+174ms ║║Duration 119214879ms for was_not >= 600000ms threshold = true
+175ms ║║Comparison (enum) not present was_not (string) present = true (21ms)
+176ms ║║Condition #27 evaluated true (28ms)
+177ms ║║Condition group #26 evaluated true (state did not change) (30ms)
+185ms ║║Comparison (enum) off is (string) on = false (1ms)
+187ms ║║Condition #29 evaluated false (8ms)
+188ms ║║Condition group #28 evaluated false (state did not change) (9ms)
+190ms ║╚Execution stage complete. (64ms)
+191ms ╚Event processed successfully (191ms)
12/17/2019, 3:12:06 PM +210ms
+1ms ╔Received event [Front Doorbell].motion = inactive with a delay of 91ms
+118ms ║RunTime Analysis CS > 22ms > PS > 43ms > PE > 53ms > CE
+120ms ║Runtime (42246 bytes) successfully initialized in 43ms (v0.3.110.20191009) (118ms)
+121ms ║╔Execution stage started
+139ms ║║Condition #5 evaluated false (14ms)
+140ms ║║Condition group #1 evaluated false (state did not change) (15ms)
+211ms ║║Duration 118470944ms for was_not >= 600000ms threshold = true
+212ms ║║Comparison (enum) not present was_not (string) present = true (65ms)
+213ms ║║Condition #27 evaluated true (71ms)
+214ms ║║Condition group #26 evaluated true (state did not change) (72ms)
+223ms ║║Comparison (enum) off is (string) on = false (2ms)
+224ms ║║Condition #29 evaluated false (8ms)
+225ms ║║Condition group #28 evaluated false (state did not change) (9ms)
+227ms ║╚Execution stage complete. (106ms)
+228ms ╚Event processed successfully (228ms)

Mebejedi · 2019-12-18 04:46:09 UTC

My Arrival piston has a similar function: If X, followed within 10 minutes by Y. For the life of me, I can’t remember how I found the function. You could import my code, strip it down, and put in your coding.

Basically, the announcements prime themselves when someone arrives. Once they close the door, the announcement starts. If I arrive, it starts playing the Star Wars intro. If they take longer than 10 minutes to get in (unlikely), then it doesn’t play the announcement. In your case, it could relock the door (though I wouldn’t trust a piston to do that, but that’s just me.)

And in the future, you should probably do a green screenshot instead of red. It anonymizes your personal info.

Mebejedi · 2019-12-18 05:11:14 UTC

You’re in luck. I figured it out. I would recommend making a copy of your piston to mess with, because this command is very touchy to get right, and you may get frustrated and want to start over.

Deleted - Correct procedure is here: Unlocking door when someone comes home & walks in front of the Ring doorbell

Rrands1 · 2019-12-18 05:15:30 UTC

you are fantastic - thank you so much - putting it in a new piston to test now!

re: green -vs- red - I put in the red one b/c otherwise the sensor names were hard to follow - I didn’t see where posting the actual names of the devices was an issue unless I am missing something?

Mebejedi · 2019-12-18 05:22:55 UTC

Deleted - Correct procedure is here: Unlocking door when someone comes home & walks in front of the Ring doorbell

As to the RED/GREEN, if you have personal information such as a PUSH NOTIFICATION command to a cell number, the RED will show the cell number. You don’t have that in this piston, but it’s things like that that can get out onto the internet if you’re not careful.

WCmore · 2019-12-18 05:35:20 UTC

Both of you are right. A green snapshot is the safest, and a good habit… but in this case, I can see how the red was more helpful without showing anything other than your name.

For what it’s worth, I would crop off the top of the red snapshot or block out the red import code. In the wrong hands, that can be abused. (only the green import code is safe to share)

Rrands1 · 2019-12-18 05:45:54 UTC

so I am following your steps, but when I change it to “followed by”, it sets it to 1 minute and then I can’t change that to anything else… Any thoughts there?

Mebejedi · 2019-12-18 06:09:47 UTC

Deleted - Correct procedure is here: Unlocking door when someone comes home & walks in front of the Ring doorbell

Rrands1 · 2019-12-18 06:31:43 UTC

thank you for the help here - I feel like I am so close, but it’s giving me fits (as you mentioned!)…

I do as you show above, but it leaves the “followed by 1 minute” bit above the new 5 minute entry, like so:

i can’t seem to delete the 1 minute one, and wonder if that’s going to mess up the piston? Are we maybe missing something for a step here? I have tried converting the statement to a new group, adding in different orders, etc, but can’t seem to get it right! Very frustrating!

Rrands1 · 2019-12-18 06:42:15 UTC

OK - I got it in (haven’t tested it yet though) - I ended up creating two new “IF groups”, one right after the other (so they are nested), and then adding the Time/Light on check as an AND, then changing the second group to a “Followed by” and adding the motion check (it put it in as 1 minute, but then when I clicked on it afterwards, I could change the time to 5 minutes…) Here’s what it looks like:

Think that will work?

Mebejedi · 2019-12-18 07:22:06 UTC

It might?

I’m messing with mine to see how it works. I got it right ONCE, and never again.

Mebejedi · 2019-12-18 07:28:12 UTC

Deleted - Correct procedure is here: Unlocking door when someone comes home & walks in front of the Ring doorbell

Mebejedi · 2019-12-18 07:50:19 UTC

OK…finally figured it out. (For real this time)

Create your first condition. Then below that, click the next ADD A NEW CONDITION and create a second condition. They’ll be joined by an AND. (This actually makes more sense, since it IS a modified AND statement. We’re just adding a wait for the second part…kinda like waiting for the other shoe to drop.)

Click on the AND, and change it to FOLLOWED BY

Then click on the second condition under the AND, and you’ll get the settings menu you want.

This worked consistently several times in a row…easier than I thought it would be. Apparently it was already expecting two statements to combine. If you only have one statement, it forces you to make another in a different manner.

Rrands1 · 2019-12-27 18:15:42 UTC

UPDATED issue - got the statement in the right order, but it is not firing correctly

1) Give a description of the problem
lock is not unlocking when I get home & walk in range of the Ring doorbell camera

2) What is the expected behaviour?
When my cell comes in range of the WiFi & joins the network (or I come in range of the geofence app), I want a timer to start (for 5 minutes) that waits for motion in front of the Ring camera, and if detected, will send me a text. If it times out without motion in front of the door, then the door stays locked.

3) What is happening/not happening?
Presence detection works fine, however the piston is not evaluating the “did my device get on WiFi” correctly, and so does not process the THEN statement to send the text.

I have set the execution policy to always execute, however it seems that while initially the IF statement (if my cell gets on WiFi, and was “not present” for at least 1 second) evaluates as TRUE, when I subsequently trigger the camera’s motion sensor, it is re-evaluating the ‘IF my cell get’s on wifi’, and since that did not change again, it is not processing further.

Please help!

**4) Post a Green Snapshot of the piston

5) Logs

12/27/2019, 10:39:04 AM +465ms
+2ms ╔Received event [Front Doorbell].motion = active with a delay of 66ms
+83ms ║RunTime Analysis CS > 18ms > PS > 50ms > PE > 15ms > CE
+85ms ║Runtime (38627 bytes) successfully initialized in 50ms (v0.3.110.20191009) (83ms)
+86ms ║╔Execution stage started
+97ms ║║Condition #4 evaluated false (6ms)
+98ms ║║Condition group #3 evaluated false (state did not change) (7ms)
+99ms ║║Cancelling statement #2’s schedules…
+100ms ║║Condition group #2 evaluated false (state did not change) (10ms)
+101ms ║║Condition group #1 evaluated false (state did not change) (11ms)
+103ms ║╚Execution stage complete. (17ms)
+104ms ╚Event processed successfully (104ms)
12/27/2019, 10:38:08 AM +192ms
+1ms ╔Received event [_RandyHome-WiFi].presence = present with a delay of 71ms
+144ms ║RunTime Analysis CS > 58ms > PS > 76ms > PE > 9ms > CE
+146ms ║Runtime (38629 bytes) successfully initialized in 76ms (v0.3.110.20191009) (145ms)
+147ms ║╔Execution stage started
+156ms ║║Comparison (enum) present changes_to (string) present = false (0ms)
+157ms ║║Cancelling condition #4’s schedules…
+158ms ║║Condition #4 evaluated false (5ms)
+159ms ║║Cancelling condition #3’s schedules…
+160ms ║║Condition group #3 evaluated false (state changed) (8ms)
+161ms ║║Cancelling statement #2’s schedules…
+162ms ║║Condition group #2 evaluated false (state did not change) (10ms)
+163ms ║║Condition group #1 evaluated false (state did not change) (12ms)
+165ms ║╚Execution stage complete. (18ms)
+166ms ╚Event processed successfully (166ms)

WCmore · 2019-12-27 19:50:31 UTC

I have never had solid reliability using “followed by” conditions…

I would create two mini-pistons for this project:

Piston #1:

(This tiny block can be added to your “main” presence piston)

If Sensor's presence changes to present
Then 
    With location   (TCP set to Never)
    Set global newlyArrived to 'true'
    Wait 5 minutes
    Set global newlyArrived to 'false'
END IF

Piston #2:

IF Sensor's motion changes to active
Then
    IF global newlyArrived is 'true'
        Then do cool stuff
    END IF
END IF

Of course, I have to add my disclaimer here:
I often use programming to lock the house, but due to the nature of SmartHomes, I try to discourage using programming to unlock the house.

If a client really insists on it, I will add many more conditional checks to make doubly sure that the door should be unlocked.

Mebejedi · 2019-12-28 19:13:10 UTC

I have an @ARRIVAL global variable that changes how my door announcements work. If a presense sensor is detected, @ARRIVAL=Yes and It plays my arrival announcements with the door closing (“Welcome home”).

If @ARRIVAL=No, then regular door announcements are made (“The door is open/closed”.) As @WCmore has pointed out, this works well as two different pistons. Another possibility that came to mind might be to click on OPTIONS and select SHOW RESTRICTIONS. This will add an ONLY WHEN line to your piston, and you can add your presence sensor there. (You can see the @ARRIVAL global variable in my pic)

That said, I would change LESS THAN 1 SECOND to AT LEAST 1 SECOND (or perhaps 5 seconds…not sure how that would affect the piston)