Another auto lock rule request, perhaps more complex

There are some other ones out here but perhaps not as complex as this one I used to have in WebCoRE. I am still pretty new to rule machine and I am stumped. Any suggestions on how to do this one would be more than welcome.

Specifically I am trying to build in 4.0 an auto lock rule which attempts to lock the door after it has been unlocked manually or digitally.
-If the door never opens after unlock it should wait 2 minutes and then attempt to lock.
-If the door does open then it should wait for it to close for 5 minutes. if it does Close then attempt to lock after a full two minute delay.
-IF after Opening, the door doesn't close for 5 minutes, it should send a notification that the door was left open.
-If after attempting to lock the door the door fails to lock then attempt to lock the door 3 more times waiting 15 seconds or so between attempts. If after three more attempts the door still doesn't lock then send a message that the door is jammed.
-Also, if the door closes and then reopens during the two minute delay before locking then the two minute Delay before locking should be stopped and retest the above conditions for open and locked states.

I am hesitant to use the Door is changed as the trigger because after the door auto locks it will trigger the rule again. Just seems inefficient. Does rule machine have a way to check a condition that specifies the state change from one value to another?

LJ

These are my 2 rules for auto locking my front door. The first one is if the lock unlocks (doesn't matter if it's digital or physical) and re-locks it if the door doesn't open within 3 minutes.

The second one deals with locking after the door has been closed:

[EDIT: Duh, forgot about your other conditions]

For this one, if I remember correctly, only certain locks support sending a "jammed" condition, so for this one, you could do something like (psuedo-code, I haven't tested this):

IF (Door Lock unlocked) THEN
    Repeat 3() times every 0:00:15 (stopable)
        Lock Door Lock
        IF(Door Lock locked) THEN
            Stop Repeating Actions
        END-IF
    END-REP
END-IF
1 Like

Thanks for examples and suggestions. The Cancel Delayed Actions command is one I was missing and I think I can see how this would accomplish the situation where the door reopens before the lock delay ends. Quite cool.

What is the scope of Cancel Delayed Actions. Does it just affect delays within that rule? Is there some way to cancel a delayed action in another rule that may be waiting?

It seems like there would be two attempts to lock the door in a normal unlock-open-close sequence, one attempt from each rule. Am I misreading that? I need to look closer. Maybe not. I will have to test this. Thanks!

LJ

1 Like

One more question. in the Contact sensor rule above, is there any reason you can think of that in the ELSE clause I shouldn't call the Auto Lock rule instead of calling Lock directly? Am I going to get in some sort of loop? The reason i ask Is I added the repeat commands discussed above directly to the Autolock rule as shown Here:

LJ

Technically, it looks like it should work. You can also add a Cancel Wait to your ELSE to reduce the timeout if the door opens.

Wouldn't the wait have already ended by the time the ELSE runs?

LJ

@corerootedxb

[Edited to update rules images after further testing]

Thank you SO much. Here are my rules. I opted to add a third trigger rule to trigger the autolock rule so that the autolock rule wouldn't recall and reevaluate itself a second time. Now the logs are nice and clean and not messed up with a bunch of skipped evaluations.



I would not have gotten here this quickly without your help and support. You are the best. This is what makes this community great.

LJ

1 Like

Glad to be of help! I got slammed with work earlier, so I couldn't get back to you but it looks like I didn't have to! Nicely done LJ! Cheers!

I'm still a bit lost on RM 4.0. Below is my rule. I just want to lock the door 5 minutes after the door is closed, but a subsequent open and closure will reset the countdown. How do i properly use wait/delay/cancel? Below is my rule (knowing that it will queue up for each opening of the door.)

Something to keep in mind is when using a changed trigger, you need to consider all changes. In your case, you need to account for the door opening as well. The door opening event needs to cancel the lock delay. Try this as an example.

@bjcowles,

I think your example may have an issue. Upon the Door Changed event, if the Door is open, there are no Delayed Actions to cancel. IF the door closes and then reopens, then there might be a Delayed Action to cancel, if this second running of the rule will actually cancel the prior running of the rule. I don't know this answer and haven't tested it. I Assume you have if this is your rule.

The question is, what is the scope of the Cancel Delayed Action? Will it cancel an action in a previous running of the rule?

LJ

While technically true, once 'Cancel Delayed Actions' is executed, I assume that instance of the rule is done. In my imagination, I liken it to a rule action sending an 'Off' command to a switch that is already off. The rule doesn't care if the switch is off (unless I tell it to care), it's sole job is just to send the command and be done with it.
A new instance is created when the door closes, and the cycle continues.

I'm sorry if the above doesn't make any sense. Articulation isn't one of my strong suits.

You explain it very clearly. However, if the Cancel Delayed Actions, only works in that instance and there are no delayed actions in the instance then it does nothing, Right? Then unnecessary. But if it does cancel the delayed actions in any instance of that rule, then it would potentially cancel any previous 5 minute timer running in that previous instance and accomplish what i think you intend.

I am probably missing something but would love to hear your thoughts.

LJ

This is what I am hoping is taking place, now that I think about it. Otherwise, I would have concurrent instances of the rule, right? I need to think about this more as I use this same logic in a lot of my lighting rules and haven't run into any problems.