Automatically Lock Door X minutes after door last opened

[dcd722]

1) Give a description of the problem
I have a Yale Lock and a Open/Close contact. I’d like a piston that automatically locks the door X minutes after the last time the door is opened OR X minutes after the door is unlocked but not opened. We’ll use 15 for now.

2) What is the expected behaviour?
Door is unlocked, I open and close the door. Once door is closed, 15 minute timer starts. Door locks. OR I unlock, open and close door. After 3 minutes, I open and close door again…15 minutes after that the door locks

3) What is happening/not happening?
Door is locking 15 minutes after the first open/close

**4) Post a Green Snapshot of the piston![image|45x37]

5) Attach logs after turning logging level to Full
(For the Log/Test, I set the time to 1 minute instead of 15). I unlocked the door, opened it, closed it, then opened it again 30 seconds after I unlocked it. I would expect/want the condition to cancel and restart the timer and then lock 1 minute later

9/15/2021, 8:22:47 AM +572ms
+5ms ╔Received event [Front Door Lock].lock = locked with a delay of 29ms, canQueue: true, calledMyself: false
+16ms ║RunTime initialize > 15 LockT > 1ms > rtDT > 1ms > pistonT > 0ms (first state access 13 6 9)
+19ms ║Runtime (8915 bytes) successfully initialized in 1ms (v0.3.113.20210703_HE)
+20ms ║╔Execution stage started
+27ms ║║Comparison (enum) locked changes = true (0ms)
+28ms ║║Condition #6 evaluated true (5ms)
+29ms ║║Condition group #5 evaluated true (state did not change) (7ms)
+36ms ║║Comparison (enum) locked is (string) locked = true (1ms)
+37ms ║║Cancelling condition #9's schedules...
+38ms ║║Condition #9 evaluated true (8ms)
+40ms ║║Cancelling condition #8's schedules...
+41ms ║║Condition group #8 evaluated true (state changed) (10ms)
+42ms ║║Cancelling statement #10's schedules...
+48ms ║║Executed virtual command setVariable (2ms)
+57ms ║║Comparison (boolean) false stays (boolean) true = false (2ms)
+60ms ║║Cancelling any timed trigger schedule stays result false cancel timers for condition 23
+60ms ║║Cancelling statement #23's schedules...
+61ms ║║Cancelling condition #23's schedules...
+62ms ║║Condition #23 evaluated false (12ms)
+63ms ║║Cancelling condition #22's schedules...
+65ms ║║Condition group #22 evaluated false (state changed) (14ms)
+69ms ║╚Execution stage complete. (49ms)
+71ms ╚Event processed successfully (68ms)
9/15/2021, 8:22:44 AM +254ms
+7ms ╔Received event [10628].time = 1631708564175 with a delay of 79ms, canQueue: true, calledMyself: false
+20ms ║RunTime initialize > 19 LockT > 1ms > rtDT > 2ms > pistonT > 1ms (first state access 16 8 11)
+23ms ║Runtime (8927 bytes) successfully initialized in 2ms (v0.3.113.20210703_HE)
+29ms ║╔Execution stage started
+42ms ║║Cancelling condition #23's schedules...
+43ms ║║Condition #23 evaluated true (2ms)
+44ms ║║Cancelling condition #22's schedules...
+46ms ║║Condition group #22 evaluated true (state changed) (5ms)
+47ms ║║Cancelling statement #24's schedules...
+91ms ║║Executed physical command [Front Door Lock].lock() (29ms)
+92ms ║║Executed [Front Door Lock].lock (41ms)
+98ms ║╚Execution stage complete. (68ms)
+102ms ╚Event processed successfully (98ms)
9/15/2021, 8:21:43 AM +958ms
+4ms ╔Received event [Front Door Lock].lock = unlocked with a delay of 35ms, canQueue: true, calledMyself: false
+134ms ║RunTime initialize > 133 LockT > 1ms > rtDT > 121ms > pistonT > 120ms (first state access 11 5 128)
+137ms ║Runtime (8879 bytes) successfully initialized in 121ms (v0.3.113.20210703_HE)
+138ms ║╔Execution stage started
+147ms ║║Comparison (enum) unlocked changes = true (1ms)
+148ms ║║Cancelling condition #6's schedules...
+150ms ║║Condition #6 evaluated true (7ms)
+151ms ║║Cancelling condition #5's schedules...
+152ms ║║Condition group #5 evaluated true (state changed) (10ms)
+160ms ║║Comparison (enum) unlocked is (string) locked = false (2ms)
+162ms ║║Cancelling condition #9's schedules...
+164ms ║║Condition #9 evaluated false (9ms)
+165ms ║║Cancelling condition #8's schedules...
+167ms ║║Condition group #8 evaluated false (state changed) (13ms)
+175ms ║║Comparison (enum) unlocked is (string) unlocked = true (2ms)
+176ms ║║Cancelling condition #14's schedules...
+177ms ║║Condition #14 evaluated true (9ms)
+184ms ║║Comparison (enum) closed is (string) closed = true (1ms)
+185ms ║║Condition #15 evaluated true (7ms)
+187ms ║║Cancelling condition #12's schedules...
+188ms ║║Condition group #12 evaluated true (state changed) (20ms)
+190ms ║║Cancelling statement #16's schedules...
+198ms ║║Executed virtual command setVariable (2ms)
+212ms ║║Comparison (boolean) true stays (boolean) true = true (4ms)
+216ms ║║Adding a timed trigger schedule stays result true scheduling timer for condition 23
+222ms ║║Condition #23 evaluated false (19ms)
+223ms ║║Condition group #22 evaluated false (state did not change) (21ms)
+227ms ║╚Execution stage complete. (89ms)
+246ms ║Setting up scheduled job for Wed, Sep 15 2021 @ 8:22:44 AM EDT (in 60015ms)
+248ms ╚Event processed successfully (245ms)

[Eric182]

Not going to address your immediate concern, but you can do this with Rboys smart app. Something to look at in the future when WebCoRE longer works.

[RELEASE] Lock User Management (LUM)

[dcd722]

I was actually using that when I was on SmartThings buy I’ve moved over to Hubitat (which unless I’m mistaken Rboys doesn’t support)

[E_Sch]

Your nesting is hurting you as things being tracked don’t always get executed (so they don’t always get tracked)

So a few things:

You want all the if xxx changes to execute every time so that the state of the condition is tracked

• this could be separate if statements that do nothing (but get the rest of the piston to run).

• above will help you un-nest the xxx is now and stays statement

Similar for the stays you have it nest that it does not run over the statement every time.

so you end up with

If lock changes

if contact changes

if lock is locked …

if {variable} is now and stays true for {} mins

Note - they are no longer nested

[eibyer]

Try this one I use for my door/lock, you can remove stuff you don’t need on line 77 down.

[dcd722]

Definitely a better written script than mine, thanks but it still doesn’t seem to do what I’m looking for.

If I set the ‘wait’ to 1 minute and unlock the door, it will always unlock 60 seconds later, even if I open it.

What I want is ‘wait’ 1 minute, but if I open the door and interrupt, the timer restarts when the door returns to the closed position.

So unlock the door, wait 30 seconds, open and close the door, door should lock in 60 seconds but instead locks in 30

[eibyer]

Hmm strange, did you pause your other piston first? I just tried it again with virtual contact and lock and it worked for me.

I changed the wait to 30 secs for testing.
Unlocked lock, timer starts and relocks.
Unlocked the lock, timer starts, I open the door, timer stops. Closed the door, timer restarts at 30.

[dcd722]

Well well well…what a surprise, it turns out when the batteries in your contact sensor are dead, stuff that relies on the contact sensor doesn’t work! I guess I need to add more logging…

[guxdude]

Maybe try a cancel all pending tasks each time you run to reset? Have to look a little deeper to be sure. Problem is, it will run every time the door open/closes or lock lock/unlock so you have to put the cancel pending tasks in the right place.