After weeks of reading and debugging the device behavior I am happy to contribute this driver to the community.
The registration and de-registration functionality for the PIN Code / RFID Tag logic and inner workings has been written from scratch, now the hole process is way simpler but most importantly accurate.
Great work man.
I looked at these keypads when I first joined HE but went with an Iris Keypad as that was the best option at the time.
Now it’s awesome to have another option for Access Keypads.
Love that this brings RFID capabilities to HE.
Cheers
Had massive errors in the log at first since the keypad and driver was in a strange state. I would include some instructions how to clear the state for future users. I used clear and initialize but without looking at the code I don't really know what they do.
I don't think "Away mode delay" is working as you intended. Looking that wt-rfid-Zipato-Mini-Keypad-RFiD-Z-Wave-User-Manual-v1.4.pdf document on page 02 it says that param3 is "Feedback timeout", not "Away mode delay" as you label it. The only way I could delay the Away mode was to change param2 that you call "Notification sound" and the PDF calls "Feedback time".
When I set the "Notification sound" to x (seconds) I can see the mode changing after x seconds which is what I would expect from "Away mode delay".
Looking at param3's description it says "To configure the timeout to wait for a WAKEUP_NO_MORE_INFORMATION before the error beep is automatically sound." I experimented with the setting but I think it's more of an internal setting that allows the controller to pace itself before the keypad gets pissed off about the missing WAKEUP_NO_MORE_INFORMATION command. I'm think you may not expose that setting since it's dependent on the speed of communication in the driver?
In short I suggest you:
a. change your param3 to use param2 instead
b. remove your current param2 line.
Super nice work on how to capture and set both RFID tags and pin codes. You may want to add the ability to set the user code directly since that's possible without a capture. The codes are ASCII so just a matter of adding 48 to the numbers, i.e. {49, 49, 50, 0,0,0,0,0} means 1,1,2 on the keypad. I may just fork your driver and do a MR
Hmmm I'm getting super odd behavior here where they keypad is stuck in a blinking mode after requesting to go into away. Let me debug this over the weekend before I cry wolf.
Ok some more information. There are some z-wave storms happening with this driver for me. I'm looking at 30+ "dev:133 2020-02-29 00:56:20.171 info Forgetting slot: 3" for example in a row. Replacing batteries doesn't stop the deluge. I'm wondering if the MSR set is not happening quickly enough so any wakeup will trigger userCode requests even if there are userCode requests already queued up. Still looking.
#1 This was intended do be used as a fresh install, if you swap the driver on an existent driver you can try using the Clear State command.
This will clear set reset all the state variables.
#2 In relation to the parameter 3, the wording on all the manual and docs is not clear but most importantly functionally, It work a bit strange and after testing I managed to find a useful use case:
This parameter is used in conjunction with the command basicSet(value: 0xFF), when a Code or RFID is recognized the switch is not set on immediately (It's delayed).
If the parameter 3 is set to a positive value and we send the basicSet(value: 0xFF) command, the device will start counting down until the parameter 3 value (beeping), ones it stops it will send the SwitchBinaryReport(value:0) that will then set the switch to on
#3 On the user code input, yes we would add it directly from the UI, but I just wanted to keep the methods / UI consistent, additionally this method also guaranties the user is waking up the device correctly as we can verify it with the captured code.
#4 The event flood, yes I have seen this ad its definitively some sort of race condition, one way I have worked around this is to add the line two time updateDataValue("MSR", msr) this will more or less guaranty the values actually gets written.
Unfortunately on the driver side we don't have access to the atomicState variable functionality.
I am completely open for suggestion or changes (PR's), I would just like that we (the community) have one driver that was been battle tested.
Still figuring out the command storms. I'm speculating that my mesh is triggering the storm since the keypad is two hops away from the controller. This causes a much slower rate which may cause the MSR flag to be set much slower. I also think other constant-powered devices will hold commands for battery devices so turning on and off the keypad doesn't help since the mesh is still full of commands waiting for the keypad.
Still looking at it and will spend a few hours on this on Tuesday. Really nice code BTW!
Figured out some more things about this device after hijacking the NotificationReport and WakeUpNotification methods.
The keypad works as a beeper in many ways, in addition to keypad with usercodes.
Switching it on with switchBinarySet turns the beeper on and off. Not responding to it with a wakeUpNoMoreInformation also makes it optionally beep after a while (six quick beeps).
param2: Automatically turn switch (keypad) off after X seconds. Auto off will send a SwitchBinaryReport(0) at that time. A keypad that is on is beeping.
param3: Require a switchBinarySet or wakeUpNoMoreInformation within X seconds from the controller after they keypad sends a WakeUpNotification. While waiting, the keypad is blinking every second with the led being mostly on and the keypad is locked for further input. This can be used to prevent brute force attempts since the controller can select to not send a wakeUpNoMoreInformation when bad codes are input. X=0 disables all this.
param4: Feedback beeps per second when switched on using switchBinarySet (1).
I'm going to look at this on Tuesday to see if we can add some configurations such as locking the keypad for N seconds after M failed attempts and a cleaner delayed arming since I think the arming right now is a side effect of the SwitchBinaryReport coming back but the current implementation thinks it's always the UI setting it to off.
Sadly I'm giving up on this keypad. I don't trust it anymore. I've watched it completely go crazy and flood the z-wave network too many times here on my desk.
