Upgrade to 2.5 - zwave secure device not working

I recently upgraded 2.4 to 2.5.
I uses docker and wanted to create a clean install, after staring the 2.5 container I added the binding and then added the things that was in my zwave stick.
One of my devices is door lock, that was included with security in 2.4.
I copied the security key from 2.4 and put it in the zstick of 2.5 but still the device not working and in his attributes I see it as non-secured item.

Did I miss something?
How can I make it secure again? if I start the 2.4 container I see it secured but in 2.5 it is not…

1 Like

I would suggest that you do a reinitialisation. It’s probable that the binding may have performed the query on the device before you added the key, so performing this again after adding the key will hopefully allow it to see all the secure data as well.

To do this, there is a parameter in the Thing for your lock called something like “Reinitialise device” - change this to true and save the configuration.


Now I notice that I often have a delay between sending a command from OH 2.5 and actually executing (sometimes over half a minute) and sometimes the command does not occur at all.
It started to happen in version 2.5.
Here are the logging logs of a state I was unable to execute the command:

12-Jan-2020 20:47:20.165 [smarthome.event.ItemStatePredictedEvent           ] - kitchenLed predicted to become OFF
12-Jan-2020 20:47:20.171 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 37: Command received zwave:device:Zwave:node37:switch_binary1 --> OFF [OnOffType]
12-Jan-2020 20:47:20.171 [DEBUG] [rotocol.commandclass.ZWaveBinarySwitchCommandClass] - NODE 37: Creating new message for application command SWITCH_BINARY_SET
12-Jan-2020 20:47:20.171 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 37: Encapsulating message, instance / endpoint 1
12-Jan-2020 20:47:20.171 [DEBUG] [otocol.commandclass.ZWaveMultiInstanceCommandClass] - NODE 37: Creating new message for command MULTI_CHANNEL_ENCAP endpoint 1
12-Jan-2020 20:47:20.171 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 37: SECURITY not supported
12-Jan-2020 20:47:20.171 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 37: Command Class COMMAND_CLASS_MULTI_CHANNEL is NOT required to be secured
12-Jan-2020 20:47:21.758 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 67: sendTransaction org.openhab.binding.zwave.internal.protocol.ZWaveSerialPayload@48e3af43
12-Jan-2020 20:47:21.759 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 67: Bump transaction 26406 priority from Controller to Immediate

Any ideas why does it happen?
Thanks ahead!

This post saved me from going through the pain-in-the-ass process of excluding/including my door lock after a fresh install (and a switch from an RPi3 to an RPi4). I was fully prepared to do that, not realizing that I could copy the original security code and then reinitialize the lock.

1 Like