Rule Machine, Why So Complicated?

I'm the first to admit that I'm probably not the ideal Hubitat user. I was a Wink user forever, but I got sick of the glitches. That being said, I've been on Hubitat for about a year now, and have over 100 devices set up and mostly working okay. I just moved over the last of my items from Wink, namely four Kwikset Dead Bolt locks. ALL I WANT TO DO is set up basic rules that auto lock my garage service door and shed door after 30 minutes of unlocking. I'm not worried about other conditions like presence, door contacts or anything else. Rule machine is surprisingly the opposite of intuitive for me. How the heck do I set up a basic rule to accomplish this? I've set up a couple of dozen other rules for notifications and other things and they were relatively easy. This one, i just don't understand. Thanks.

This might help... I am using a contact sensor on the door to make sure it is closed before it is locked.

1 Like

I'm sure I'm just missing some field somewhere, but I'll take a look at yours. Thanks for the reply.

If you're not concerned about a contact sensor making sure the door is closed before locking and strictly want it based on a 30 minute timeframe only, you can go even simpler than the above rule like this.

1 Like

Here's another way to do something similar to the above:


This rule doesn't test for the door being closed first with a contact sensor, but that could easily be added if you want. What this rule does do is monitor one lock: if unlocked, it will set a timer for 30 minutes, then lock the door. If the door gets locked in the meantime, this delay gets cancelled, which you may find useful if you leave it unlocked for 29 minutes, then lock it, then unlock it again and don't want it to automatically lock in 1 minute (which is similar to what this rule would do without the "Cancel Delayed Actions" and the "cancelable" flag set on the delay, which affects all subsequent actions--and is an issue you'd face with both of the rules provided above).

As for Rule Machine itself, it's not super-intuitive, but it is intended to be an advanced tool for when you are (hopefully) familiar with the platform and find that a stock app can't do what you want. Reading the documentation is practically essential to understanding how it works, and luckily there is some good documentation with lots of examples. Here is the Community thread on the latest version (which might assume a bit of prior Rule 3.0 knowledge, but there are similar docs for those): [Released] Rule 4.0. As you've seen above, the community is also usually willing to help.

1 Like

Think where I was having problems, was I was trying to set up a delay separately before locking after 30 minutes. I see now that there is a delay option available in the action set up. Wayne's pic pointed me that way. I'll know in about 28 minutes if I got it right this time, hahaha. Thanks all.

1 Like

That also works. His action of:

Lock: Garage Door Lock --> Delayed: 0:30:00

is equivalent to (more or less what I have):

Delay: 0:30:10
Lock: Garage Door Lock

...if you only have one action after the delay. (If you have more, the other difference is that a delay on an action immediately moves to the next action in your rule, then comes back whenever and runs that action, whereas a separate Delay action like this pauses there for the delay. That doesn't matter here.)

What you'll find in either case is that a rule without "cancelable" selected and a "Cancel Delayed Actions" action like I have is that such a rule will schedule the delay/lock every time the lock is locked and will not unscheduled if the lock is unlocked and re-locked in that time period. (If you're used to webCoRE, Rule Machine has no Task Cancellation Policy. If you're not used to webCoRE, just know Rule Machine doesn't read your mind and only does exactly what you say--webCoRE tried a little, often helpful--as it might be here--but sometimes confusing.) This means you will get a build-up of scheduled locks since the only thing that will cancel them is the passing of time, which may lead to surprising results in the scenario I mentioned in my previous posts. I suggest using a "changed" trigger and canceling the delayed actions, as I did, unless you really don't think that will ever come up in your actual usage of the door (but I'd do it anyway because it's still equivalent in that case).