Rule Machine & Security Keypad Help

Partial is the other arm mode that this keypad has. It doesn't have armHome and armNight like some other keypads. You have to choose which one it arms. So, partial is the function defined in the keypad. You have Armed, Partial and Disarmed.

The delayExpire is the time (in epoch) that the delay currently in use will expire. It should be equal to the current date/time. You can convert to real human time here:
https://www.freeformatter.com/epoch-timestamp-to-date-converter.html

That's the site I use to convert from Epoch time to readable time. (epoch time is the number of MS since Jan 1, 1970 00:00:00:0000.)

1 Like

I'm think the solution is to rethink my original premise.

Lock / status of the house changes don't affect the keypad. So no circular rules.
Keypad always in resting state of "partial".
If you hit off, it unlocks lock / turns off alarm, then goes back to partial.
If you hit on, it could lock the door, then go back to partial.

Possibly panic could mean arm away (after system arms, hubitat turns off the panic and sets it back to parital). That would work as long as no one screws with the volume on the device. ... but there are plenty of other ways to set arm away in hubitat like presence or I have a button by the door I can hit on the way out.

You're going to run into trouble using the panic with the native driver. I don't think that is exposed anywhere for you to "use".

Good point, would have to use WATO or similar to watch for the attribute change.

The other option is back to responding to the keypad changes only if the keypad is active. But I see issues with that as well, as it takes about 30 seconds to go inactive. Might be able to get around that... but likely best to keep it simple and only control the lock at this point with off and on.

Time to test some rules, and then possibly find a spot in a drawer :slight_smile:

Thanks again

The motion sensor on the keypad is VERY ineffective. Gives false actives all the time depending on what is happening. In fact, I've seen it go active because it picks up itself shaking due to a beep command.

My pleasure. Honestly, if I were you, I'd go to my landlord and ask about swapping the front of the lock too. If you're always good with your rent and a good tenant, they might let you.

LOL, that's lovely. I'd have to cover the motion sensor anyway to get that idea to work... it still goes active on button press with the sensor covered. It's a hacky idea, but I'll likely still try it for "fun", then give up, and go back to the simple.

1 Like

I know you're headed down a path with the keypad, but honestly I would consider a different method. Especially in apartment buildings with so many people close by, I wouldn't like the idea of entering my code in the open every time I enter.

I have a keypad lock, but I'm in a house, so it's quite a different situation. I've been using this rule for my wife and I, together with two simple triggers to prevent unintended auto unlocks once we're in the house. The rule is triggered by three elements.

  1. The Hubitat mobile app presence
  2. My WiFi presence (an IFTTT function of my Deco M5 router)
  3. A motion detector outside my front door.

Prevent unintended auto unlock

Resume auto unlock when either of us leaves the location. This accidental auto unlock I found is only an issue if the auto unlock doesn't work and we enter the code to get in, lock the door, but then afterward the conditions are met and the door unlocks again. So far this has not been an issue, but it was in my previous setup that used different triggers, so I just added it as insurance.

True, and probably would have been the best way. I've been operating under do what I want and apologize after (like switching out the thermostat). The keypad is hung in the apt building hall with scotch tabs (not worried about anyone taking it or screwing with it, I know my 3 neighbors). A lot of what I'm doing is more fun than necessary. I don't even really think I need an alarm knowing my apt neighbors... its pretty rural here.

Interesting... If I'm getting this right, you have 2 virtual switches that come on, one with motion by the door, the other when your router sees you are present. Then as a third the mobile presence app.

If all three are on (your phone has connected to wifi, the app has noticed you are home, and the door motion sensor goes active), it unlocks the door for you. Then it shuts off the virtual switches so it doesn't retrigger (such as someone walks by the motion sensor while you are still on the wifi, wouldn't trigger because that wifi switch is now off even though you are still on the wifi).

If you're going to use presence, why have the keypad at all?

Almost. I found that on/off of the switches can be schetchy to rely on. They may turn on if someone it at my front door and my phone disconnects, then reconnects to WiFi. With my previous presence detection (HomeKit), it was working well, but if my phone went dead while in the house, when it turned on again while charging, the front door would unlock. Has not been an issue with the Hubitat app.

I use a pause for the rules when the door opens to prevent this. Then as long as the door is closed, when one of use leave the area, the rules resume.
[Edit] Refined the pause and resume triggers so we don't pause and unpause each others unlock by presence rules.

1 Like

Not sure @SmartHomePrimer usage, but the keypad was my thought for having someone else (family) be able to enter without putting crap on their phones. Gave someone a key (mother, older) and the thought of the alarm kept her away because she was afraid it would go off on her (which has some benefits)... If I gave her a keycode at least the alarm would disarm without her having to know anything. If she can get the keypad to unlock the door, she is good.

I've had some trouble with mobile presence before (such as I found with life 360 if I drove by my house the doors would unlock), so I had to put in delays, etc... but the presence with the motion sensor at the door is interesting.

Still want the keypad though, if I can get it working.

Also, I was thinking a keypad in case somehow the deadbolt locks and I don't have my keys / phone. Its hard to get locked out with keys, because you can't set the deadbolt without them. But pretty easy once you have a "brain" that (due to my bad rules) locks the lock on its own.

What is the purpose of both connected to wifi and the mobile app presence?

This is my reason for having both keypad and presence. Presence is a convenience, not a requirement. This gives a backup method as well if presence should fail. If it's not just you and a spouse for example, then I agree with changing the entire lock (if you can't get your external keypad to work properly).

I too had issues with early implementations. This is why I use three conditions, two of which require I be right in front of the door.

What is your method of shutting off the alarm with a keypad lock?
Unless it has a tamper function, and you are using it, wouldn't someone picking the lock to unlock it also turn off the alarm?

Or are the two unrelated - so you unlock the lock, then use the inside keypad after to disarm?

For my parents at least, it was easier to give them a copy of the hard key for my keypad locks than trying to teach them to use the keypad. We're talking two people in their 70's who don't even have smartphones. So, I wasn't even thinking of other folks who need access.

1 Like

I use this method with my keypad lock. I'm assuming the technique would be similar with a regular keypad. So if a presence rule is true, the alarm disables. If a valid code is entered, the alarm disables. If it's not one of the aforementioned, the alarm will sound. At the moment these are separate triggers, but I need to start using the IF-Then statement more to reduce the number of separate rules and triggers I have that are no longer necessary.

Thanks, make sense. Unlocking the door manually won't turn off the alarm, unless one of you are present (or just arrived depending on how you have it set up).

1 Like

Correct. We have to individually (updated the rules above) leave the geofence to activate our unlock rules, then we have to be back inside the geofence, our individual phones must connect to the router WiFi, and the motion sensor must detect someone standing in front of the door.

In practice, I've seen a few seconds delay when I arrive at the door by foot and zero delay when pulling up to the house in the car. I'm not sure why, but the router WiFi doesn't connect to our phones as fast when we arrive on foot, vs by car. Just the way it seems to work.

With @Ryan780's help, I think my keypads are now working. Just some finishing touches on the rules. The fix was to stop trying to have them show the correct hubitat state.

SO, now, I'd like to see if I can implement something similar to you @SmartHomePrimer. Although it is flaky like Ryan said, I'd like to try out the motion sensor on the keypad. I find it only notices true motion when you are inches from it. So I think it might work with a hand wave. Not sure how many false positives it will get until I try it out.

I don't have a way to report if a device is connected to wifi.

I'm hoping for your thoughts on why this won't work.

The idea would be "while the mobile app says I'm present (cancel if I leave range), and once I've been present for 30 seconds (to avoid if I drive by), allow motion on the keypad to open the door." Once the door is opened the rule is paused until I leave range again.

It's possible someone else might trigger motion during that time period while I'm in range but haven't gotten to my door yet... but I think I'm ok with that part.