The motion sensor seems to depend on the firmware version. I have two: one on 1.08 which doesn’t expose a motion sensor, and one on 1.18 which does. Unfortunately, I haven’t found a way to do a firmware update without a real Ring base station.
3 Likes
Is it possible to use multiple keypads in a system?
Absolutely. There’s nothing that would restrict the number you can use.
Well, I guess you’re limited to 253 zwave devices in a network, so if you need more than that you’ll need a second controller. 
1 Like
I now have 3 - 2 x v1 and 1 x v2.
As I mentioned before if you are in the UK travis Perkins online have the v1 for £15 delivered. Although they are not as nice as the v2, for that price you can get 3 for the price of one v2 
I have 1.18, the sensor is exposed but status never changes (is always ‘clear’).
Hi, I’ve just installed a V1 keypad and I’m using Sleevezipper’s blueprint, which seems to work great.
I was just wondering if there’s an easy way to change which mode the buttons on the keypad activate?
Specifically, I’d prefer to use the “Home” button to activate Alarmo’s “Custom Bypass” mode.
Thanks in anticipation.
There’s no easy way to do that, and it’s an unusual enough requirement that I’m not sure I want to add the option to configure it to the UI. That said, the changes to do so aren’t too bad.
You’ll want to copy the blueprint to your config/blueprints folder, and change the references to arming home to arming custom bypass. It looks like that would be:
- On lines 77 and 113, change
armed_hometoarmed_custom_bypass - Make the block starting on line 139 look like:
sequence:
- choose:
- conditions:
condition: template
value_template: "{{ trigger.event.data.event_data is not none }}"
sequence:
- service: alarmo.arm
target:
entity_id: !input alarm
data:
code: "{{ trigger.event.data.event_data }}"
mode: custom
default:
- service: alarmo.arm
target:
entity_id: !input alarm
data:
mode: custom
1 Like
Much appreciated,
I know it’s a bit niche, and not worth changing the UI.
So, I tried as you suggested, and it didn’t want to work.
I’ve got next to no knowledge or experience of coding, but I’m trying…
I made a few changes to your suggested code which eventually worked:
Lines 77 & 78:
to: armed_custom_bypass
id: alarm_armed_custom_bypass
Line 113:
- armed_custom_bypass
Starting at line 138:
sequence:
- choose:
- conditions:
condition: template
value_template: '{{ trigger.event.data.event_data is not none }}'
sequence:
- service: alarm_control_panel.alarm_arm_custom_bypass
target:
entity_id: !input 'alarm'
data:
code: '{{ trigger.event.data.event_data }}'
default:
- service: alarm_control_panel.alarm_arm_custom_bypass
target:
entity_id: !input 'alarm'
There may be coding errors in here which are obvious to those who know what they are doing, but it seems to work for me.
I wouldn’t have had a clue where to start without your help.
Thanks again…
Just a small contribution. If you’re looking for a chime whenever a door opens, you can trigger one by tying the sensor opening event to:
{"command_class":135,"endpoint":0,"property":96,"property_key":9,"value":100}
“value”: 100 is 100% volume. Adjust to your liking.
There may be a cleaner way to do it, but it works great for me.
2 Likes
Is there a way to configure the keypad’s motion sensor to have a delay?
My keypad sends motion detected and motion clear events too quickly, about 4 times a second, which causes the z-wave network to hang and the keypad becomes unresponsive. In ZWaveJS2MQTT I can disable the motion sensor all together and all is well except that it loses the motion sensor functionality and proximity display.
Does anyone feel like the zwave connection is spotty on the v2 keypads? I have a pretty robust network with quite a few devices. Everything seems bulletproof except for these keypads. They frequently show the red signal loss symbol. I tried looking for a firmware update, but it looks like they expect you to update these through the ring hub.
Just curious if anyone else experiences this. Aside from the signal (which is a pretty big deal), these have been fantastic.
3 Likes
Take a look at my post just above. I had the exact same issue with the red signal light coming on frequently - I couldn’t reliably use the keypads to arm/disarm the system.
I noticed these keypads sends motion clear events extremely quickly, it would send a motion detected and motion clear events a few times a second which I think causes the z-wave communication failures. I’ve disabled the proximity detection in the z-wave device config which has made the keypads reliable. Unfortunately it loses the ability to use as a motion sensor and flash the current state as you walk by it.
If there is a way to increase the dwell time for the keypad to report a motion clear event I suspect the motion sensor can be used and still be reliable, but I don’t see any config options in ZWaveJS2MQTT for this keypad.
So for now I just have it disabled and so far it’s been reliable.
A few days ago, I started to reply to your post wondering if my connectivity issues were the same. When you said they were unresponsive, I didn’t know if they froze or disconnected from the network. In any case, I’m a dummy. Thanks for taking the time to respond.
I see what you mean about all of the traffic. Looking through the logs, I see tons of send and receive activities classified as motion. Three of these keypads were installed less than a week ago. In that time, they’ve sent and received about 6000 packets in total, lol. Thats wild. I’m guessing the hub is rate limiting the device? I’ll disable motion and hope something develops that allows us to limit this.
Experimenting a bit, it looks like there’s two undocumented configuration parameters, both 1 byte, 25 and 26. On my keypad with firmware 1.18, 25 is read-only and always returns 10. But 26 is read-write, and appears to control the motion sensor timeout. Setting parameter 26 (size 1 byte) to 60 gives a timeout of about 1 minute, so I’m guessing it’s a timeout in seconds.
So, try setting parameter 26 as a 1 byte signed value and see if it works for you.
1 Like
I’ll give it a shot and report back. Thanks!
Edit:
It does seem to limit the motion sensor reporting to a maximum of once every 60 seconds. The device still lights up whenever it detects motion, but it adheres to the max reporting parameter. So, that’s good.
Is it normal to see a lot of dropped RX packets with these devices? I don’t know enough about this to say, but none of my other devices show that number growing as quickly.
I don’t see significant numbers of dropped RX packets on either of mine. I’m afraid I don’t have any great insight into what might be causing that. If you’re seeing lots of network traffic, I guess collisions are inevitable. Turning down the motion sensor reporting frequency certainly won’t hurt. I’d also look in the logs for any other devices that are being unreasonably chatty. A quiet network is usually a happy network.
I figured it out. Had one of the keypads in two groups. One for the hub and one for a repeater. Was trying to figure out why it kept losing signal and assigned it to a repeater to see what would happen. Answer… more problems.
How do you access these undocumented parameters?
Awesome, that custom parameter change works! I’ll monitor the reliability over the next couple days and report back.
No idea how you discovered the undocumented parameters, but thank you for all the great work!
Edit: After 3 days of use, the keypads have been solid with the motion timeout at 60s!
1 Like