thanks for the suggestion. under my device details i see the securinClusters with what looks to be the same code string as in your post that is linked.
are we supposed to put in our lock code + Away/home in order to initiate arming of the system?
There's a slider button in the keypad's device details page for "Enable set alarm without code". If that's on, you can just press away/home without a pin. if it's off, you'll need to enter your code and then the away/home.
If you arm HSM using the device page menu, does your keypad change state and announce "home and armed" or whatever? if so, what happens when you enter your pin and then the blue X (upper left) disarm button ?
I'm trying to get a Ring Keypad to unlock an electric gate lock (controlled by a ZEN17 universal relay) when a code is punched into the keypad. The only way I've been able to accomplish this in RM is by using the custom attribute "lastCodeName = " as the trigger/action and then manually typing in the code(s) I want to use within the rule. This is okay, per se, but I want to be able to just use the lockCodes, that way I can add them via Lock Code Manager for all my locks (3 Yale Zigbee door locks and 2 gate locks) and have it work since it's an approved lock code on the device - I don't want to have to go into the RM rule each time and add additional codes (e.g. "IF (Side Gate Keypad lastCodeName = 1111) OR IF (Side Gate Keypad lastCodeName = 2222) OR IF (Side Gate Keypad lastCodeName = 3333) THEN"). Does anyone know what I could be doing wrong?
To this point, the driver didn't have a streamlined approach to your use case -- primary focus is on serving HSM (and similar Apps).
However, I see the merit of having a generic "code validation" interface, which I added this afternoon in my fork -- PR raised to integrate in the main stream as well: add "validCode" attribute and "validateCheck" preference in Ring Alarm Keypad g2 by dkilgore90 · Pull Request #58 · bptworld/Hubitat · GitHub
Using this new update, you can use Lock Code Manager to set, enable, and disable valid codes for the keypad, then trigger your rule simply on the new attribute validCode == "true". Note there is also a new preference to validate codes when submitting via the "check mark", which you may need to enable -- wasn't sure which button you're using for code submission for your use case.
3 Likes
That's incredible! It works great now, and the RM coding is super clean now (always a plus!). Thanks so much for adding that functionality so quickly, @dkilgore90!
1 Like
Hey guys I wanted to bring something to your attention.
It looks like this driver is in some way creating extra events for HSM related state changes. I am honestly not really sure how to explain it other then to state what my rule is doing and what the result is when the keypad is running.
This all started because I am trying to trigger rules on HSM status changes. Part of the action is to write some states to variables after certain HSM events occur. I have been talking with @bravenel because i saw some things that pointed to HSM/RM issues on my dev hub that didn't have a keypad. Now that those issues have been fixed and my dev hub works great, Once I enabled the rule to work on my prod hub i still experienced a issue with the rule running twice when it was only triggered once. After removing the Keypad from HSM it worked fine. I also tested this a few times with the Built in driver and that seems to work fine as well. I like the added features we have in this driver, but extra events may make it very difficult to use HSM to trigger anything. If i watch HSM it looks like it HSM cycles through the delay period and the immediately restarts it. That can possibly explain why the Rule never sees it go to armed away and the required expression go false
Here is the live Logging that shows what the rule did. Keep in mind this is from click on the HSM button to Arm/Away.
What it looks like is happening is when the button is pressed HSM changes to Arming away as it should and then 60 seconds later triggers Armed Away. Then for some reason it again is triggered into Armed away 60 seconds later. This triggers the rule to run again and because it logs some values and then turns devices off the second run tell logs the value to OFF. This is a problem when the disarm action runs and the value is not as expected.
Here is the Rule from RM incase you want to look at it.
late response but just worked with the system today again. even though my settings seemed to match the expected appearance of a working keypad pairing (secureInclusters data being present, healthy z wave connection, etc...) i decided to remove it again and repair it with smartstart. Once i did this it started working as expected both with the security code + mode button. and also with the one touch mode button arming methods for HSM.
Thanks again for the suggestion!
Is there any way this driver could be ported to work on the Ring V1 Keypad? The V1 keypad is really pretty sweet too and it would be nice to get a bit more functionality from it.
Saw something like that a few years ago playing around with another keypad - finally traced it down to having both the keypad and HSM running delayed exits. Believe the sequence went something like (been a while so don’t hold me to this being exact):
- Arm keypad
- Keypad sent Arming message
- Delay Expired Keypad sent Armed message
- HSM saw Armed message and started its delay by sending Arming message
- Delay Expired HSM sent Armed message
Solution at the time was to only have one of the know about the delay.
May not be your issue, but thought I’d throw it out there just in case.
Sorry, I don't use RM or HSM. I wrote my own versions of both apps. Event Engine and Safety Net (SN isn't available yet).
Yea.. I remember reading about that as a possible cause as well. What is strange is the Built in driver works fine. Only this community one seems to have this problem. I never set the delay inside of the keypad driver, and only in HSM. Another points is that i just validated this has nothing to do with delay as I test this with my Armed/Home, and its settings that don't have a delay. The community driver just seems to be sending the events twice. Screen shot below
That leads me to believe the driver is just sending it twice.
@bptworld This really has nothing to do with RM, but with the behavior of the keypad while it interacts with HSM. Generating erroneous events will lead to bad behaviors for anything trying to trigger off that event. This could make your community driver useless for anyone that uses HSM. It is great you are writing your own apps, but you may want to clarify for folks if your driver won't support the built in ones. I mean frankly I wouldn't recommend it at this point for anyone using HSM based on that response. It also just dawned on me that this also explains why for a while now I have been getting double notifications from HSM whenever it's status changes.
It's a 'Community' driver, anyone is welcome to take a look and submit a pull request (as many have).
ok well i am looking at it actually, I haven't done much with modifying drivers so I trying to understand the structure.
Think I may have found what is needed to correct the issue. I will setup a pull request once i have had time to validate a few more things.
Do you have more than one keypad using this driver? If so, it's the expected behavior- that's how the driver works on purpose to keep keypads in sync. So to assume you have multiple keypads--
As a hack, I used the and stays that way inside the trigger. I have mine set to 1 second, but it looks like that wouldn't work for yours since it's a full minute apart.
I have the keypad driver set to 1 second for armAwayDelay and armHomeDelay. Inside HSM I have Delay arming Armed-Away = 20 and all the Delay intrusions = 30,
You might be able to play with those numbers.
I have one keypad. I also only have one armed state that uses delays. The others do not. Disarmed should never have a delay.
Keep in mind the built in driver works fine. I found what I believe are redundant calls when the buttons are used. I am testing it now and will submit the pull request when done doing my own testing.
The act of keeping the keypads in sync shouldn't be done in the device driver, but in the application managing the keypads. In my case that is HSM, or as bptworld has indicated Saftey Net. If Saftey Net is not doing that and putting that in the driver like i said above that is a good distinction to make so we know who should use the driver or not.
Every time i thought i was getting closer I found something else that was a it of a issue. I think today i found the silver bullet though. There were two things that I noticed.
- There were redundent calls in the physical button press section of the code. It was send a command to HSM to update it's status and then calling the section of code that were the alarm commands. This ultimately led to redundent actions the hub was having to deal with.
- There was a issue with how the delay code is handled in that it wasn't handling the a particular state properly. This caused it to submit the command event to HSM again just after updating the state on the Keypad.
A bit more testing but will submit the pull request soon if testing goes well
1 Like
I have submitted the pull request with my edits. Every time I found a way to fix one concern another would pop up.
New version...
1.2.3 - 07/31/22 - remove Redundant calls causing multiple events in HSM. Added Additional Logging. @mavrrick58
1 Like
