Looking for suggestions on how I could set this up better:
I have an iris security keypad being used as an exterior entry keypad. Just like august - the keypad is outside and my locks don't have their own keypads.
I have decided "off" on the keypad will unlock the door. "Partial" will lock the door. And "On" will lock the door and arm the system. The keypad triggers rule machine to make this happen.
Additionally, if someone manually changes the lock, rule machine will send the updated state to the keypad.
I'm currently experiencing some unintended actions due to the delay of the keypad. I can manually unlock the door with the key, walk in, manually lock it behind me, and as the status of the keypad is updated slowly from rule machine, the keypad sends commands back to Hubitat. So sometimes after manually changing the lock, the keypad will then unlock / lock behind me as I walk away from it.
I'm working on delays / conditions in my rules to try to stop the commands from coming back from the keypad if it's state was set from Hubitat and not from the keypad itself. I'll probably figure it out, but was wondering if anyone had other ideas / a different implementation that didn't cause this issue.
When you update the status of the keypad, you are going to want to disable the PB of your rule that reads the Keypad status. Otherwise you are going to get into a loop.
That was my original thought before my last try with lock codes (which I assume you saw). I was using a switch instead but same idea... but the timing was tough. How long should it stay off before accepting commands from the keypad again? Such as, I (semi quickly) unlock the door manually (triggers keypad change), close the door, and press the button on the exterior keypad to lock the door. Maybe I did it wrong, need to try again.
Going to try your suggestion first, but another possible solution is only accepting commands from the keypad when the motion sensor is active. It appears if you cover the motion sensors, it will still go active on the press of a button.
I really appreciate your following my problem and giving suggestions. Like I said, going to test yours first.
What??? You are making this a lot more complicated than you need to.
In the rule the checks for the manual changes to the lock, insert an action above whatever actions you already have setting the PB false for the rule checking the keypad's status. Then insert an action at the end to set the keypad rule's PB back to true. Done. All in the rules you already have.
Will try now. You are very likely right. My originally try and fail was probably due to me using a switch to restrict the keypad rules with a timed off on the switch versus manually turning the PB On and Off. Sometimes you just don't see the obvious.
If nothing else, at least my multi-night adventure found a bug in RM.
Unfortunately, not working. Same issue I had when I had it tied to a switch versus the private boolean.
I believe the issue is the keypad is slow to respond to changes. So, you manually change the lock a couple times in short order, the commands are sent to the keypad while the private boolean is off on the keypad rule, all good. Then the private boolean comes back on. But then the device starts responding to the commands in sequence triggering the rule.
Will post rules. But I think it is working as intended. The issue is (sometimes, not consistently) you start playing with the lock - it turns off the pb on the keypad rule. You unlock the lock, lock the lock, unlock the lock. Each sends a status change to the keypad. then it turns the keypad PB back on. The keypad is slow to accept changes, and starts responding to all the state changes and sends its current states as it is adjusting back to Hubitat triggering the rule now that the PB is back on.
For clarification - the idea is that the keypad shows off when unlocked, partial when locked, and armed when either arm away or arm stay is on. The HSM state is controlled by switches, as you'll see in the rules.
There are three rules to make changes to the status of the keypad. I might be able to combine them, but right now they are separate.
I do really appreciate you looking at this. I'm fairly competent with the system, but this has been bugging me for a while, and I've spent the last few nights trying to fix it. I really thought only responding to lock codes would be my answer! But not so much from what Bruce stated.
Maybe if I changed the third to a rule (versus a trigger), and put a "wait for" on each of them waiting for the keypad status to change to the desired state before turning off the PB. Hopefully, the wait for would cancel itself if the rule changed to false.
Edit: I tried. Best so far, but they still get out of sync at times. I played with it for maybe 10 minutes. Keypad showed the wrong state probably 3 times. The lock only adjusted itself on it's own to match the keypad once... must have timed that one just right. Usable. But don't like it.
The problem is that the keypad isn't going to be able to respond to all those commands. I would do a few things.
I would put a delay at the very beginning of the rule's actions of 5-10 seconds with a cancel on truth change. That way, if the lock changes quickly, it never bothers sending that status to the lock.
I would put a delay in between the disarm, armAway or armHome and the PB being set to true. This will allow the lock to finish whatever it is doing before the PB goes back to true.
I like that, but I don't think I'll be able to set the delay that long.
If the door is locked (keypad shows partial), you unlock the door, exit, close the door in say 2 to 3 seconds you won't be able to relock the door by pushing the "partial" button until the keypad first changes state to off. Don't want to start my work day cursing at the keypad as I wait to be able to lock the door
I did something similar with a "wait for" event. It waits for the keypad to respond before changing the PB back on. I'm concerned with putting too much of a delay here as well, to go along with my leaving example above. You could think the keypad is ready to accept a lock command after exiting the house, but in fact the PB is still off due to the delay. They keypad would change state but the corresponding rule in RM wouldn't trigger.
Thanks for the help - will play with these suggestions today and see if I can't get it working
Well, your requirements are getting longer and longer....if you wanted a lock with a keypad, why didn't you just get one. Would have solved a lot of your problems.
Same requirements as first post, but I see you are now up to speed with my frustration :).
In an apt right now, so only replaced the interior part of the lock.
Okay...it still doesn't make a whole lot of sense to me. If your landlord was okay with you mounting something on a wall outside, you would have thought they would have been okay with you changing the outside of the lock face as well, even if you had to provide them with a key. I think you need to limit your use-case in order to get reliability. Either you need to choose to lock from the lock or the keypad, not both. You aren't going to get the functionality of a keypad lock out of this setup with any reliability.
Not quite ready to throw in the towel (and the keypads in a drawer) but it is quickly becoming my preferred solution. I appreciate all your time looking into this. It's very helpful to have someone else confirm you aren't doing it wrong, and that it just isn't possible.
It's just that they Iris keypad doesn't react that fast.
Oh, btw...do you have your exit delay set to 0 for the keypad?
Having entryDelay, exitDelay, armHomeDelay and armNighDelay all set to 0 will definitely speed it up. Mine is set this way because I'm using it with HSM.
