If I'm not mistaken (I haven't had a chance to test it out):
Correct it does not work directly with HSM, nor will the HE keypad drivers work with Nyckelharpa
1 Like
I just don't have any luck with these keypads, both Iris and Xfinity. They don't respond reliably enough to use.
Here is a video showing the frustration I constantly have: https://photos.app.goo.gl/7h8ySady5KT8pGiB7
This video shows the HE saying Armed and the keypad showing the opposite, even though I armed it from the keypad! https://photos.app.goo.gl/k5oHPbZikAQjEhaR9
I have an Xfinity, an Iris V2 , and an iris V3 all happily working with the nickelHarpa app and its associated keypad driver
Response is almost instantamtaneous
I'm getting different errors with tones on v3:
[dev:773](http://192.168.11.5/logs#dev773)2020-02-13 01:11:45.071 am [error](http://192.168.11.5/device/edit/773)java.lang.NullPointerException: Cannot invoke method endsWith() on null object (beep)
Encountered this issue testing my Iris V3 and attempting to incorporate some logic from the Hubitat provided V3 driver on Github into my DH used with the Nyckelharpa app.
I concluded the issue is caused by the Device not having the "inClusters" set in the device then testing it with this code in the beep command
if (getDataValue("inClusters").endsWith("FC04"))
but did not report it or pursue it.
Since then, around Feb 6 2020, a change was made to the Hubitat Iris V3 driver code on Github removing that code in favor of a user defined setting. As of now, Feb 13, 2020, that change does not appear to be released.
If it was me encountering that error I would try the Hubitat Github DH version.
tagging @mike.maxwell
Thanks! You wouldn't happen to know a v2 driver like that hanging around would you? 
I've updated the driver to provide a preference option to manage this in 2.1.9.
2 Likes
I'm giving up on the V3 iL02 keypads as well. With the latest update I tried to use the keypads again...paired them easily.
They both seem to work fine but on one of them the lights never stay off & the batteries run down...it didn't do this before the last update.
The other one seems to be working fine for now, but I'm going back to the old 3405-L keypads as they seem to work fine.
This isn't related in any way to the driver update.
I have a V3 keypad that would run down the batteries very quickly as well from the lights never turning off, It seems to be something that happens while pairing the keypad rather than the drivers. I had noticed this on 2.1.4 and 2.1.5 both I haven't seen that issue with the v2 keypads however two of those out of my three eventually got stuck on motion active, I'm guessing repairing them would probably clear that issue but I don't use their motion sensor for anything since they have such a limited range so I haven't tried.
Thanks Mike....I had not tried these keypads in a a long time but noticed the last update had some new drivers for the V3 pads so I decided to try them again....I think these keypads need an exorcist. LOL
1 Like
No doubt about it, the Iris V3 is a very strange device. It does two things (and perhps more) that the Iris V2, and Centralite keypads do not do.
-
It requires a response to a real motion message, or it stops responding to the system or the keypad after 5 or six user generated motion messages, until it receives a valid response. However until it gets a valid response it sends a new motion message around every 5 seconds.
-
During exit delay and entry delay time periods (and perhaps longer until it receives a valid response) it sends unsolicited firmware generated motion messages, one per second or so, that look exactly like real motion messages. From my experience these messages can be ignored by the device driver.
I'm not having any of these issues with beeping or battery consumption...
V2 battery : 100
V3 battery : 100
V2 has been in use for 2 years and replaced the batteries once. V3 has been in use for 6 months and still 100% battery.
But then I also modified Mikes code for both DH which might be why.
I would be interested in viewing your code. Is it on Github?
I just found another odd bit of behavior. When the keypad is vertical the lights stay on. Normally I use my V3 device for development with my Nyckelharpa app, it sits flat on my desk and appears to work. However when vertical, normal for most users, I just discovered the lights do not shut off, but set flat and it's off in seconds (WTF).
Edit: placed vertical but upside down, it works as expected, lights shut off after a few seconds.
Edit2: switched to Stock Iris V3 driver from my Nyckelharpa Centralitex driver, did a configure, lights continued on in vertical position
Edit3: Got the lights to shut off when vertical by placing the device at the edge of my table. Can only assume the two bottom motion sensors or whatever they are, were sensing the table top. 
My device has the old firmware.
It's on my repo.... but not open to public. I'll move it tonight so others can have a peek at it.
1 Like
Here it is https://gitlab.borgnet.us:8443/sgrayban/hubitat-public-repo/-/tree/master/drivers%2FIris-Keypad
Since I'm at home with no work, I decided to try my troublesome Iris V3 Key pad again. I have 2 of them...one works fine, the other eats batteries because the lights stay on.
The troublesome V3 Key Pad works exactly like yours in the vertical & upside down position as you stated. Going to try @anon61068208 code from his github to see if anythings improves with this keypad.
If it's mounted or placed at the edge of a table, the lights should go off. I'm guessing the two sensors on the bottom of the device may be proximity rather than motion. Which driver are you currently using?
As far as I can determine the lights staying on is a hardware condition that cannot be mitigated by software.
My keypads are mounted on the wall. If you have the V3 on a desk you're going to have problems with it.
