Nope. But I don’t think you understand what they’re reporting.
My keypads are using official drivers for my Iris V2 and Xfinity XHK1-TC keypads
What I found was causing the error was the delay option is missing which is fixed as shown below:
/*
armAway
Arms the keypad to "Away".
*/
def armAway(delay)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "armAway", [delay])
}
/*
armHome
Arms the keypad to "Home".
*/
def armHome(delay)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "armHome", [delay])
}
/*
armNight
Arms the keypad to "Night".
*/
def armNight(delay)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "armNight", [delay])
}
/*
disarm
Arms the keypad to "disarmed".
*/
def disarm(delay)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "disarm", [delay])
}
This cleared the errors for me and no longer get errors but I haven't checked yet what was causing the odd HSM behavior I had last week, I was going to put HSM on the hub with the actual keypads on it to test to see if I can replicate it as it may not be related to HubConnect.
There's no need for insults. Its not rocket science. You can clearly see that the method is being called with a value of 90. I'm not an idiot.
The stub driver is also missing armNight (which also is not in the Hubitat documentation, to be fair).
I'll just fix my copy of the driver, and stay out of the arguing. 
Don’t hold your breath.. My driver is created according to the posted specification. The errors are occurring because someone is using a physical driver not following the spec.. Therefore, it’s not a bug. And that’s exactly what the logs are indicating..
1 Like
If I told you that you didn't understand something, how would that make you feel?
1 Like
Yes, of course you are right. You two are arguing semantics.
Now that you know the hubitat documentation is wrong, you can be proactive and fix it or wait for the docs to get updated. I'm ok either way.
But arguing over semantics isn't fruitful.
1 Like
That is what you said to me, albeit with different and sarcastic wording..
Do we know for certain that the documentation is wrong? I am not trying to be difficult about this, but because the keypad driver is considered to be generic, it needs to follow what’s published. If the spec gets clarified I’ll gladly update it in afuture release
Good question, actually. I think so based on the fact that some of the in-box drivers have commands and command variants that are not in the documentation.
But, it could be argued that the SecurityKeypad documentation is "correct" and that these devices are "special" and extended the functionality above the base requirements.
What about an enhanced keypad stub driver?
That’s true. Then it would require a new driver in addition to the current one. But I also have a lot more pressing priorities right now trying to get 1.7 ready to go which is proving to be a challenge since my server hub failed. That’s why I suggested a custom driver for this application at this time.
I can share mine stub driver if needed so you don't have start from scratch if you want me to PM it.
I fixed everything that was making errors in my copy of the keypad driver - but it still won't work in HSM....
In HSM I get errors as follows. It seems it is expecting the keypad driver to return something it is not. Maybe @bravenel can clue us in:
app:3172020-01-05 06:10:53.404 pm errorjava.lang.IllegalArgumentException: The JSON input text should neither be null nor empty. on line 1409 (armNoticeHandler)
At least our experience matches.
I guess we're stuck fixing the stub driver until @mike.maxwell updates the official documentation (assuming it needs updates based on how the centralite, Iris v2, and iris v3 keypad drivers work), or @bravenel tips us off on what is not getting sent that HSM is expecting.
No biggie, I have a ton of other things to work in in the meantime!
3 Likes
Yeah, there's a few extensions to existing methods that were required to integrate the keypads a little better with hsm.
It was some time ago so I'll actually have to troll through the code to find them, or maybe I'll post up the v3 keypad driver.
1 Like
Either way would work. The docs miss armNight and the optional time parameter on the other arm states. There is of course the matter of whatever HSM is looking for when you arm the system that throws the json error above.
It would be great if you could update the official capabilities docs with whatever changes are missing.
Thanks!
