I’m having an issue adding 2/3 of my Kwikset 914 locks. One has loaded fine, and might have been loaded on 2.4, while 2.5 fails to properly include the door locks.
I have about 60 z-wave devices on my network, including 4 door locks. 3 Kwikset 914’s (914TRLv3) and an August Pro. The August Pro was added with 2.5 and the 2.5.0 z-wave bindings, and works fine.
Platform: openhabian 2.5 on Raspberry Pi 4 w/ 4gb ram, 32gb sd
Here’s the info in thing in paperUI about the device
Black & Decker
I can see that it is adding securely, but the thing never gets a COMMAND_CLASS_DOOR_LOCK so any attempts to control the thing with a configured item gives an error and does nothing. As mentioned above, the other locks are working without issue.
The other thing to note is that I’m was getting a TODO in the logs about zwave, until I factory reset one of the locks, excluded it, and re-added it.
2020-01-08 13:46:35.906 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: null
2020-01-08 13:46:35.908 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=ApplicationUpdate, type=Request, dest=67, callback=64, payload=40 43 06 04 40 03 5E 72 98
2020-01-08 13:46:35.909 [WARN ] [essage.ApplicationUpdateMessageClass] - TODO: Implement Application Update Request Handling of New ID Assigned (64).
No really - it’s unfortunately quite complex, and difficult to debug due to lots of security constraints including very short times for things to happen. You can read through the ZWave docs, or the source code.
From a quick look at the log above though, the secure inclusion was working fine. It looks like the device did not respond to the VERSION command class requests and it gets stuck at that point.
Thanks Chris! I’ve been looking through the z-wave docs and that gives me something to poke around at.
As an aside, I’m super impressed with what has been done with z-wave in openHAB. Even with a hiccup here or there, it’s already been way better to work with than some commercial solutions that have been around for a while.
Is this a new lock or had it previously worked? The quality control on the Kwiksets is very poor. I had 2 bad locks before I got a third to work just fine. I also had one of the locks work for a few days before it became totally unusable and would only work after a factory reset.
Oddly enough my Kwiksets (888) that both failed to properly join were branded Vivint on the inside and my third was not branded Vivint on the inside. Don’t know if that has anything to do with it or not.
Is it possible that the default 5000ms timeout isn’t long enough for the VERSION_COMMAND_CLASS_GET for BASIC and that the binding isn’t giving the lock enough time to reply?
I’m going to work on getting a dev environment setup to be able to mess around with the binding to play around with timeouts, however, I figure I’d just do a sanity check due to my unfamiliarity with z-wave behavior.
Edit: I suspect the lock is trying to process something because the next ACK takes over a second to process when previous ACKs happen in 30ms.
I checked with a friend who’s written the z-wave stacks for some commercial devices and they confirmed they typically use 10s timeouts for GETs like this. The only other thing that would influence the lock not responding would be that the GET isn’t sent with security encapsulation/encryption.