That does look correct.
And confirm in Devices, when you select Ring Alarm Keypad G2, under Current States, you have an entry for the attribute lockCodes with you like codes listed. When you enter the lock code, and press arm, arm-partial, or disarm, the device should show lastCodeName associated with the code entered, and securityKeypad are set to the appropriate state. Also, when I said refresh, I was wrong, I meant, "Get Codes" option to pull the current list of codes, followed by a browser refresh. I find that sometimes the updates don't get pulled in. If you confirmed your codes are listed under lock code, and lastCodeName is being set correct, then double check your sensor. If any of the sensor are tripped, the unit will not arm.
I actually just ran into this issue tonight. My system was not arming and I checked my back door. I opened and closed it, then I got an intrusion alert for back door that I cleared in HSM. Then they keypad started working again.
I was experiencing this null object error as well... Though this issue appears to have been fixed in 2.2.5.124.
There is another regression which has been introduced. When using Delay Armed-Away, if during arming period, you choose to cancel by entering your code and selecting disarm - HSM disarms and the blue disarmed button illuminates. Then at the end of the original arming period the keypad transitions back to armed (red), even though HSM indicates disarmed. Keypad and HSM are now out of sync and you are not able to successfully do the disarm from the keypad. The only remedy appears to be, at the keypad, enter code and start Arm-away again and let the arming sequence complete.
There are still issue using the keypad to activate home.
I've managed to get home in the keypad to activate night, which is fine for me, and a use a rule to reflect the change back to the keypad.
What about allowing the keypad to be addressed without using HSM and exposing all of the events and actions via the device driver? My particular use case does not need to involve HSM but I couldn't figure out how to use arm/disarm events directly from the keypad so I had to use HSM and basically build my own alarm integration. For instance the only way to tell if the "arm home" command has been sent (and to tell the keypad it is in arm home mode) is to use HSM rather than addressing the keypad directly. This would also allow ring keypads to be used for other things besides strictly security...
My keypad seems to function just fine these day, when it communicates that is. For me, they issue is that it is constantly losing connectivity to the hub. I have 4 500 series smart switches right next to the keypad, yet it acts like there is a weak signal, with the radio light glowing red. I wonder if my keypad is defective, or if it's something about the way it pairs to the HE hub. It simply refuses to mesh at all, linking directly to the hub which is 1 floor away, on the opposite side of the house.
Hi, any news regarding the activation of home allarm from the keypad? The home button(the upper in the middle I mean) seems not turn red when I push it to activate the arm mode. Many thanks
This is going back a bit but what I was trying to do is use two Ring keypads as auxiliary keypads to my alarm system, which is not integrated with HSM but is addressable via HE and a device driver. I could never correctly and consistently read whether the keypad had sent an arm or disarm command, and I could't reliably change whether the keypad itself thought the system was armed or not. In other words if the alarm system was armed I needed to change the current status of each ring keypad to indicate that the system was armed, and likewise for disarmed. I finally just used HSM and it all started syncing correctly, but then I had to write a bunch of integration rules between the alarm panel and HSM to create my own integration, so to speak. It ended up working in the end but it was more complicated than it needed to be. However it does have the advantage that the security system functions completely independently if something happens to HE, while still allowing enough integration to do things like automatically arm the system when the mode changes to "night."
I also had this problem until I found this thread and the Rule Machine-based solution that @damianm posted a little bit earlier. Now, the Home button turns red after I arm night.
I wonder how much of the problem is really related to the capabilities. I have discovered my keypad refuses to relay off of any of the nearby 500 nor 700 series devices. It insists on a direct link to the hub, and so I get communication issues constantly. If it would just hop off any of the 11 smart dimmers/switches nearby, I am sure mine would be reliable. But as it is, I can command it just fine, but most time I use it to arm/disarm, it just fails and after two or three tries I get the red signal indicator.
I wonder if this is the root of the issue for others. It certainly is for me. When I bring the keypad net to the hub, it is flawless.
@armand, there may be a mix of both. I also see the red signal indicator a lot, but not as often as you seem to see it. I wonder if there's something in the Zwave security protocol that prevents relaying via non-secure devices.
That said, the fact that the 'Armed Home' button doesn't turn red unless you call 'armHome()' from a rule when you're trying to arm it for the night, while the disarmed and Arm Away buttons do, doesn't seem to have anything to do with connectivity.
Also, if you set the night (or home) delay in HSM to something else than '0,' you get an exception logged. That has nothing to do with connectivity:
2021-08-03 11:58:40.133 errorjava.lang.IllegalArgumentException: Name cannot be null. on line 136 (method armNight)
or, when arming home instead of night:
2021-08-03 14:28:36.943 errorjava.lang.IllegalArgumentException: Name cannot be null. on line 178 (method armHome)
This happens during the delay, and the red line (progress bar) under the buttons stays on until you disarm, draining the battery. Interestingly, calling armHome() actually addressed this problem for me, because it turns out that turning on the button light also turns off the progress bar.
It addressed the problem I was having with the keypad, which was that the 'Armed Home' button didn't light up after arming. I went ahead and also added 'ArmedHome' as a trigger for the same action, which helped (I have use for both Arm Home and Arm Night).
