I have OpenHab 2.4 running on a Raspberry Pi. I have added a 914TRL Kwikset Door Lock but it does not lock or unlock the door when I change it to Locked or Unlocked. In the error logs I get the following error:
[WARN ] [rnal.converter.ZWaveDoorLockConverter] - NODE 13: Command class COMMAND_CLASS_DOOR_LOCK not found
Now, according to this article below Chris Jackson added the development binding to the master so I no longer need to install the .jar file with the security as an add-on correct? I can use the native binding by Chris Jackson that shows in the Binding list in OpenHab 2.4?
Correct. It sounds like the device is not securely included. Exclude it and reinclude it. Here are some instructions, but read your manual too. Some devices require that they are within very close proximity to the controller for secure inclusion (I have some that need to be touching it). Also, check your controller settings in the Thing properties to make sure you haven’t disabled security.
Lots of people doing secure inclusion using the Aeon Gen5 stick. However, remember that secure inclusion cannot be done from the stick. It needs to be done using the binding with the stick still connected to the computer, as described here.
Okay, I was able to get this working - here is the procedure:
First, I removed the USB stick from the raspberry pi and followed the documentation for the zwave stick to exclude the front door lock. I then put the zwave stick back into the usb port on the raspberry pi and rebooted it.
I then turned on live logging in openhab and clicked the blue binding button in the openhab paper ui for the zwave binding to include the door lock. A couple seconds after clicking the zwave binding button I hit the program/inclusion button on the door lock. I noticed the logs showing the secure inclusion was processing.
A FEW TIPS: Clicking the inclusion button on the door lock a couple seconds after is VERY important otherwise it won’t work.
Also, you will want to put NEW BATTERIES in the door lock. The batteries for the door lock were at 50% and were causing problems/errors in the secure inclusion on my first couple of attempts.
I could tell the secure inclusion worked by the logs and by going to OpenHab Admin and looking at the attributes of the door lock - the “secure” attribute had a green check rather than a red X.
Thanks for documenting these lock inclusion tips with the Aeon Labs Zwave stick. I had trouble at first, but replacing the batteries in the lock with fresh ones like you suggested seemed to help. Also, my stick went into a weird state and fell offline while trying over and over. I rebooted my OH Pi machine to revive it. After a clean reboot and with fresh batteries it only took a couple tries to get it included. I played with the delay between putting the stick in inclusion mode via the OH 3 UI and hitting the last keypress on the lock to put it into pairing mode. Faster seems to have worked better for me, but YMMV.
@Ryan_Grace: so you were able to securely include a lock with OH3? I’m still struggling and getting an “Error building derived keys” in the console. So I wonder what you did differently?
16:09:20.286 [ERROR] [ommandclass.ZWaveSecurityCommandClass] - NODE 35: Error building derived keys {}
java.security.InvalidKeyException: No installed provider supports this key: (null)
at javax.crypto.Cipher.chooseProvider(Cipher.java:930) ~[?:?]
at javax.crypto.Cipher.init(Cipher.java:1286) ~[?:?]
at javax.crypto.Cipher.init(Cipher.java:1223) ~[?:?]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.setupNetworkKey(ZWaveSecurityCommandClass.java:476) [bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.handleSecuritySchemeReport(ZWaveSecurityCommandClass.java:149) [bundleFile:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveCommandClass.handleApplicationCommandRequest(ZWaveCommandClass.java:274) [bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.ZWaveNode.processCommand(ZWaveNode.java:1365) [bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager$ZWaveReceiveThread.run(ZWaveTransactionManager.java:532) [bundleFile:?]
16:09:20.303 [ERROR] [ialization.ZWaveNodeInitStageAdvancer] - NODE 35: Error in initialization thread
java.lang.NullPointerException: null
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.getSetSecurityKeyMessage(ZWaveSecurityCommandClass.java:161) ~[bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.doSecureStages(ZWaveNodeInitStageAdvancer.java:526) ~[bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer$1.run(ZWaveNodeInitStageAdvancer.java:206) [bundleFile:?]
But I have a debug log (a bit hard to read with all the devices chattering), but here it is: OH3 zwave debug - Pastebin.com
Arrgh, found the culprit. You were exactly right. I checked with the zwave binding documentation and found out that the network security key is not allowed to be in AA:BB:CC format. But with spaces or commas.
As this is my first security enabled zwave device, I suppose the binding just ignored it silently until now.
Took me two tries to get it securely included, but it’s working now!
