I'm having problems with a scheduled lock code rule

Let me explain my goal first so everything is understood:

I am using GcalSearch to poll a Google Calendar. GcalSearch polls my calendar every day at 6AM, and when the housekeeper is coming that day, it automatically enables a ping based presence device and enables her lock code, and then notifiy me that these tasks have been done. Then at a time determined by the calendar info, the presence device is disabled and the code deleted from the lock, supposed to be followed by another confirmation notification.

So far all of this works perfectly, except the code activation and deletion parts, which I would say work SOMETIMES. It seems for whatever reason, the operation doesn't always complete properly, leaving the code unchanged (either awaiting activation or deletion). It seems often if I manually try to apply the code, it will work fine.

Here's an example of it working perfectly:

Then other times, the code does not set, or delete. The device page will show the pending change, but it never occurs:

So here's my question. Is it possible to add a wait state to this rule, where it waits for confirmation that the code was successfully accepted or deleted by the lock, BEFORE sending the confirmation notification. And, if the it hangs for 3 minutes without confirmation, try again until success is achieved??

Here's what I have been able to come up with. If I understand correctly, this should repeat the code entry or code removal action every 30 seconds until the lock confirms that the action has happened, and then it will stop repeating and notify me that it worked. Does everything look right?

I'll admit I have not dipped my toe into locks, so please keep your expectations low :slight_smile: And my use of these options in RM is also limited... But hey, let's not let that stop me from contributing....

Looking at the documentation (not a common occurence for me):

I suspect your repeat will not do what you expect, since the wait will hold it up waiting for potentially an event that may not happen. You may want to include some kind of timeout in the wait for event action.

There are likely other things worth changing, but don't want to get too far ahead of this key element.

Yes. Originally I had the wait and stop after the repeat, but then the action simply repeated forever without stopping. So I moved the wait and stop in, thinking it will restart everything within the REPEAT bracket should repeat every 30 seconds, even if the wait event didn't finish. My hope is that the repeat simply ignores whether the wait finishes or not and simply repeats anyway..

If the action is successful, it should only wait about a second or two anyway before the wait is satisfied and the rule moves on.

My first time trying the Repeat function in Rule Machine so I guess we get to experiment a bit.

Ok so I can confirm that the repeat works correctly. The wait does not stall the repeat and hang, the wait timer is simply reset every 30 seconds when the actions are repeated.

1 Like

Yup, this is confirmed to work exactly how I wanted. If the lock doesn't respond, it tries again every 30 seconds. Once the lock responds and confirms the change, the wait is satisfied so the repeat is ended and the message is sent. If there is no confirmation, the whole thing just repeats again with another attempt to apply the code change and then another wait for confirmation.

2 Likes

Now I just need to figure out why my ZWave is still lagging so bad and then all this effort will just be for emergency rather than a hack to fix what shouldn't be an issue anyway.

Thanks for your updates on this, this is exactly what I am trying to do. Just to confirm, you were able to get this work work accurately with the code you posted in the screen grab? No issues?

1 Like

Yes it works exactly as intended. I think the code posted above worked fine, but just in case here's today's version which definitely works:

"Enable: Desiree (Ping)" is enabling a wifi presence device on Hubitat for a particular phone. The rest is enabling or disabling the lock code, getting confirmation of that action, and then messaging me after the lock code action was confirmed.

1 Like

Awesome, I just ran it today and it seems to work so far. Waiting for it to delete the codes at 7:30. I don't have an IF function on mine, just a condition for M-F at a certain time.. don't think I need the "Exit Rule".

I have this running for scheduling employee access codes to the shop. Also installed Reliable Locks to make sure the door lock status is always accurate.

Love the fact that I can have this rule send me notifications when the codes are added and removed. Really appreciate the help on this! RM has a bit of a learning curve.

you may want to do a count or just do maybe 5 reps retrying .. if your batteries go dead in the lock or in drops offline this will repeat forever.

I originally did the repeat part because I was having ZWave issues and communication with the lock was unreliable (ghosts in the machine). Even then, it never took more than 3-4 repeats to achieve success and stop the rule. I never actually considered the possibility of it running all day long... But even if it did that would mean that the lock didn't ever respond, so maybe it would not effect it's batteries at all? I dunno..

That makes sense.. in my usage, the trigger is any change of state of the a particular virtual switch. The IF is just to capture the switch state. IF on, do this (enable lock code). ELSE, do that (disable lock code).. Since the switch only has two states, a simple IF and ELSE covers all possible switch positions, which makes it super simple to cover both enable and disable functions into a single rule.

The Exit Rule in the first half is just because by that point, the rule has completed its task, so there's no real point having Hubitat process the remainder of the rule which only applies to the contrary switch position.

I think like @a.mcdear said, if it has to keep repeating, then it would mean that the lock isn't responding anyway. Occasionally we can have communication issues with anything wireless, so I would rather the ping continue until the lock responded vs ending up quitting the attempts and being locked out when it went back online.

That said, it would be great if there were some functionality to repeat every 20 seconds for 5 minutes, and then only once every 5 minutes after that until the lock responded. :thinking:

Blowing my mind with the possibilities here. I didn't quite understand how the google calendar trigger event was working but now it makes complete sense! Literally ANYTHING can trigger an event to program a code or delete it... as long as we can send some sort of event information into habitat.. we can make a rule to do force an action.

Brilliant! I've been thinking so small this whole time.. lol

1 Like

I use the GCal Search integration for this functionality.

With this, I can easily automate anything based off keyword searches from my Google Calendar, Gmail, or Google Tasks. Put in a keyword, it creates a virtual switch or allows you to control other switches using data from those sources I mentioned above.

In my example, on days where there's a calendar event containing the word Desiree (the name of our housekeeper), it flips a virtual switch to ON and automatically activates her lock code and wifi presence device for her phone an hour before she arrives. And then an hour after she leaves, it flips the virtual switch OFF which deletes the codes and deactivates the wifi device so I'm not unnecessarily pinging a device that isn't here every minute for no reason.

But yeah, the possibilities are endless. I have about 20 GCal triggers at the moment to automate various things (vacation mode, babysitter lock codes, notifications for Amazon package deliveries, grocery lists, disabling my own presence devices when I'm on business travel, etc.) I'm sure there are ways to use it that I haven't even thought of yet. The possibilities are vast...

2 Likes