I've checked the forum and all I've found was a driver for the Frient keypad still has not been developed yet. Its coming to over 1 1/2 years when these posts were written and many others Frient products have had drivers made for them. Mike had stated he has one but wasn't working on a driver yet.
Amazon now has these keypads in stock and it would be a great option for our Hubitat alarm systems. Many keypads that do work with Hubitat are hard to find, availability drying up or issues have been noted. I've been using the Iris ver 1 keypad that works great thanks to a Hubitat members who worked on the driver, however, after moving over to the new Hubitat Pro 8, adding Iris ver 1 devices can no longer be done unless transferred over.
Any updated news on a driver for the Frient keypad?
I just tried using the driver that is built into Hubitat. I see 2 issues (really 1) :
It doesn't have an event for "armingIn", which is required to control HSM
it is not listed in the new devices lists, so it has to be added as a generic Zigbee device. It does, however, auto-find the driver once it is added. This, though, is barely an issue.
Is the driver code available to toy with? I could add armingIn and see how it works.
I tested all the hsm integrations with the sample I had. If your device didn't select the correct driver then it's obviously a different firmware version then the sample I have.
Please post the fingerprint for the keypad that you have
I set HSM up to look at the keypad and used the built in Driver "Frient Zigbee Keypad". HSM subscribes to the attribute "armingIn", which that driver doesn't make an event for. It doesn't save thay attribute.
I'm looking at the driver code, it has a custom attribute, armingIn, as well as methods called that send events when its armed via commands as well as the panel.
Maybe you can post your specific HSM configuration for me to test against.
Just realized I didn't say I am in the US. Not sure if you release certain versions of drivers to certain areas. Frient isn't sold in the US. I bought it on UK's Amazon.
That shouldn't matter, but who knows.
Can you post a screenshot of the driver state variables?
Looking at other keypad code, none of them send an event for armingIn, so I'm not sure what you're expectation or use case for this was/is
Well... I dont know what is going on... but it is now sending the armingIn events and controlling HSM! It wasnt doing it when I 1st paired it, and I tried 2 different hubs! This makes no sense... it started hours after I sent that 1st message.
Arming in events are sent one of two ways, with HSM if arm delays are configured, or without HSM if the the preferences are enabled, and the commands are used to set the values.
Not really as the device doesn't have an input button, codes are sent from the device when The arm buttons are used to change state.
When successful these are then sent as events, including lastCodeName.
It would be possible in the code to not update the panel when a given arm state is selected but not update the arming status on the panel, similar to what happens when an invalid code is entered.
Right now invalid codes trigger an invalid code signal to the device.
If we allowed invalid codes to generate a last codeNameEvent we could introduce issues with other subscribers of this event, as lastCodeName is expected to represent a valid code entry.
The driver could be coerced into the functionality you desire but it couldn't do that and function with HSM at the same time.
