Zwave Binding - Door Lock not working

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.

Is there a problem with secure inclusion if you are using a Gen5 Aeon zwave stick? I have read in one place you can’t do it with a USB stick.

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?

I never saw that error so not sure. Sorry. I followed the instructions above and after about 10 tries got it included.

Can you provide information on your problem please - eg debug logs or something so we can maybe help?

Thank you very much. I revived a similar thread before I found this one, so that was where I included more detailed information: Problems with secure inclusion of Zwave Kwikset 914 lock - #21 by Tron

So it boils down to this:

16:09:20.286 [ERROR] [ommandclass.ZWaveSecurityCommandClass] - NODE 35: Error building derived keys {} No installed provider supports this key: (null)
        at javax.crypto.Cipher.chooseProvider( ~[?:?]
        at javax.crypto.Cipher.init( ~[?:?]
        at javax.crypto.Cipher.init( ~[?:?]
        at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.setupNetworkKey( [bundleFile:?]
        at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.handleSecuritySchemeReport( [bundleFile:?]
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke( ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke( ~[?:?]
        at java.lang.reflect.Method.invoke( ~[?:?]
        at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveCommandClass.handleApplicationCommandRequest( [bundleFile:?]
        at org.openhab.binding.zwave.internal.protocol.ZWaveNode.processCommand( [bundleFile:?]
        at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager$ [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( ~[bundleFile:?]
        at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.doSecureStages( ~[bundleFile:?]
        at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer$ [bundleFile:?]

But I have a debug log (a bit hard to read with all the devices chattering), but here it is: OH3 zwave debug -

Is the key set - it looks like it’s null which might mean it has the wrong format or something. Please provide a debug log during startup.

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!

Thanks a lot!

Cool - thanks.

I see you opened this as a bug on Github. Please can you update or close this?

Sure - closed it out.
Thanks for the support!

1 Like