OH2 Z-Wave refactoring and testing... and SECURITY

I get notifications about this thread every day…

so I’m going to give you all a notification.

Nothing to add but here you go.

Hoping there is help out there, I cant seem to get my Yale lock to work, this is starting with the Yale lock factory settings, and I keep the lock on, by pressing the screen the whole time during inclusion and while I set it up in the paperui.
Best example of an error, as nothing seems to work, when I turn the lock manually I get this in my logs:

Receive Message = 01 04 01 13 01 E8 
[DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
[DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[0x13], type=Response[0x01], dest=255, callback=0, payload=01 
[DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=SendData[0x13], type=Response[0x01], dest=255, callback=0, payload=01 
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[0x13], type=Response[0x01], dest=255, callback=0, payload=01 
[DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 121: [WAIT_RESPONSE] requiresResponse=true callback: 75
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 121: [WAIT_RESPONSE] requiresResponse=true callback: 75
[DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[0x13], type=Response[0x01], dest=255, callback=0, payload=01 
[DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 9: sentData successfully placed on stack.
[DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 121: TransactionAdvance ST: WAIT_RESPONSE
[DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 121: TransactionAdvance WT: null {}
[DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 121: TransactionAdvance RX: Message: class=SendData[0x13], type=Response[0x01], dest=255, callback=0, payload=01 
[DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 121: TransactionAdvance TO: WAIT_REQUEST
[DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 121: Advanced to WAIT_REQUEST
[DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 9: TID 121: Transaction not completed
[DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction lastTransaction outstanding...
[DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
[DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Tue Oct 24 34 MDT 2017 - 5000ms
[DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 4B 00 00 02 A2 
[DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
[DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[0x13], type=Request[0x00], dest=0, callback=75, payload=4B 00 00 02 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=SendData[0x13], type=Request[0x00], dest=0, callback=75, payload=4B 00 00 02 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[0x13], type=Request[0x00], dest=0, callback=75, payload=4B 00 00 02 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 121: [WAIT_REQUEST] requiresResponse=true callback: 75
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 121: [WAIT_REQUEST] requiresResponse=true callback: 75
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 121: (Callback 75)
 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 121: callback 75
 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[0x13], type=Request[0x00], dest=0, callback=75, payload=4B 00 00 02 
 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 9: SendData Request. CallBack ID = 75, Status = Transmission complete and ACK received(0)
 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 121: Transaction COMPLETED
 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 121: TransactionAdvance ST: DONE
 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 121: TransactionAdvance WT: null {}
 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 121: TransactionAdvance RX: Message: class=SendData[0x13], type=Request[0x00], dest=0, callback=75, payload=4B 00 00 02 
 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 121: TransactionAdvance TO: DONE
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 9: Response processed after 29ms
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 9: TID 121: Transaction completed
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 9: notifyTransactionResponse TID:121 DONE
 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 1E 00 04 00 09 18 98 81 C5 13 79 F1 24 C9 E4 1E 4A 5D 35 BA DC EE D2 7A 7B 9C 9F E5 A5 DA 44 
 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=9, callback=0, payload=00 09 18 98 81 C5 13 79 F1 24 C9 E4 1E 4A 5D 35 BA DC EE D2 7A 7B 9C 9F E5 A5 DA 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=9, callback=0, payload=00 09 18 98 81 C5 13 79 F1 24 C9 E4 1E 4A 5D 35 BA DC EE D2 7A 7B 9C 9F E5 A5 DA 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=9, callback=0, payload=00 09 18 98 81 C5 13 79 F1 24 C9 E4 1E 4A 5D 35 BA DC EE D2 7A 7B 9C 9F E5 A5 DA 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 9: Application Command Request (ALIVE:DYNAMIC_VALUES)
 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 9: Decapsulating COMMAND_CLASS_SECURITY
 [DEBUG] [mmandclass.ZWaveSecurityCommandClass] - NODE 9: SECURITY_ERR Failed authentication! [C7 B3 05 83 64 26 F4 15 ]<>[D2 7A 7B 9C 9F E5 A5 DA ]
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing

Here is some of the inclusion logs, i think:

 [INFO ] [smarthome.event.BindingEvent        ] - org.openhab.binding.zwave.event.BindingEvent@420f65e3
 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 4A 2D 02 00 00 9D 
 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], dest=2, callback=45, payload=2D 02 00 00 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], dest=2, callback=45, payload=2D 02 00 00 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], dest=2, callback=45, payload=2D 02 00 00 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 0
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: null
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ****************** Transaction not correlated
 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], dest=2, callback=45, payload=2D 02 00 00 
 [DEBUG] [ol.serialmessage.AddNodeMessageClass] - Add Node: New node found.
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0D 00 4A 2D 03 09 06 04 40 03 72 86 98 B2 
 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], dest=3, callback=45, payload=2D 03 09 06 04 40 03 72 86 98 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], dest=3, callback=45, payload=2D 03 09 06 04 40 03 72 86 98 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], dest=3, callback=45, payload=2D 03 09 06 04 40 03 72 86 98 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 0
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: null
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ****************** Transaction not correlated
 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], dest=3, callback=45, payload=2D 03 09 06 04 40 03 72 86 98 
 [DEBUG] [ol.serialmessage.AddNodeMessageClass] - NODE 9: Adding slave.
 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveInclusionEvent
 [DEBUG] [ve.internal.protocol.ZWaveController] - Stopping inclusion timer.
 [DEBUG] [ol.serialmessage.AddNodeMessageClass] - Ending INCLUSION mode.
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: Adding to controller queue
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: Added to queue - size 1
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - getTransactionToSend 6
 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 05 00 4A 05 2E 9B 
 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 05 00 4A 05 2E 9B 
 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 75: Transaction Start type AddNodeToNetwork 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 75: [WAIT_REQUEST] requiresResponse=true callback: 46
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: expected cmd class: null
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: expected cmd: null
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage Transactions outstanding: 1
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Tue Oct 24 17:57:01 MDT 2017 - 5000ms
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage lastTransaction: TID 75: [WAIT_REQUEST] requiresResponse=true callback: 46
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Tue Oct 24 17:57:01 MDT 2017 - 5000ms
 [DEBUG] [ve.internal.protocol.ZWaveController] - ZWave controller end inclusion
 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 9: Including node.
 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 9: Creating new instance of command class COMMAND_CLASS_NO_OPERATION
 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 9: Command class COMMAND_CLASS_NO_OPERATION, endpoint 0 created
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 9: Version = 1, version set. Enabling extra functionality.
 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 9: Adding command class COMMAND_CLASS_NO_OPERATION to the list of supported command classes.
 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 9: Creating new instance of command class COMMAND_CLASS_BASIC
 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 9: Command class COMMAND_CLASS_BASIC, endpoint 0 created
 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 9: Adding command class COMMAND_CLASS_BASIC to the list of supported command classes.
 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 9: Creating new instance of command class COMMAND_CLASS_MANUFACTURER_SPECIFIC
 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 9: Command class COMMAND_CLASS_MANUFACTURER_SPECIFIC, endpoint 0 created
 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 9: Inclusion is adding command class COMMAND_CLASS_MANUFACTURER_SPECIFIC.
 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 9: Adding command class COMMAND_CLASS_MANUFACTURER_SPECIFIC to the list of supported command classes.
 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 9: Creating new instance of command class COMMAND_CLASS_VERSION
 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 9: Command class COMMAND_CLASS_VERSION, endpoint 0 created
 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 9: Inclusion is adding command class COMMAND_CLASS_VERSION.
 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 9: Adding command class COMMAND_CLASS_VERSION to the list of supported command classes.
 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 9: Creating new instance of command class COMMAND_CLASS_SECURITY
 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 9: Command class COMMAND_CLASS_SECURITY, endpoint 0 created
 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 9: Inclusion is adding command class COMMAND_CLASS_SECURITY.
 [DEBUG] [mmandclass.ZWaveSecurityCommandClass] - NODE 9: Updated networkKey
 [DEBUG] [mmandclass.ZWaveSecurityCommandClass] - NODE 9: setupNetworkKey useSchemeZero=false
 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 4A 2E 06 09 00 93 
 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 1<>127 : Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], dest=6, callback=46, payload=2E 06 09 00 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], dest=6, callback=46, payload=2E 06 09 00 
 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 9: Adding command class COMMAND_CLASS_SECURITY to the list of supported command classes.
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (1): Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 75: [WAIT_REQUEST] requiresResponse=true callback: 46
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], dest=6, callback=46, payload=2E 06 09 00 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 75: [WAIT_REQUEST] requiresResponse=true callback: 46
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 75: [WAIT_REQUEST] requiresResponse=true callback: 46
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 75: (Callback 46)
 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 75: callback 46
 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], dest=6, callback=46, payload=2E 06 09 00 
 [DEBUG] [ol.serialmessage.AddNodeMessageClass] - Add Node: Done.
 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveInclusionEvent
 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 9: Device discovered
 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:controller:node9' to inbox.
 [INFO ] [smarthome.event.InboxAddedEvent     ] - Discovery Result with UID 'zwave:device:controller:node9' has been added.
 [DEBUG] [ve.internal.protocol.ZWaveController] - Stopping inclusion timer.
 [INFO ] [smarthome.event.BindingEvent        ] - org.openhab.binding.zwave.event.BindingEvent@

Other stuff:

[ERROR] [alization.ZWaveNodeInitStageAdvancer] - NODE 9: SECURITY_INC State=COMPLETE


var/lib/openhab2/zwave$ ls -la
Oct 24 18:02 network_d53343a1__node_1.xml
Oct 24 18:03 network_d53343a1__node_2.xml
Oct 24 18:03 network_d53343a1__node_3.xml
Oct 24 18:03 network_d53343a1__node_4.xml
Oct 24 18:03 network_d53343a1__node_5.xml
Oct 24 18:00 network_d53343a1__node_9.xml
Oct 22 00:11 node1.xml
Oct 22 00:11 node2.xml
Oct 22 00:11 node3.xml
Oct 22 00:11 node4.xml
Oct 22 00:12 node5.xml

Here are a handful of questions that will help in troubleshooting. Which version of Yale lock, and how many other secure devices do you have included? Are you using the jar from the first post, with no other zwave bindings installed (bundle:list |grep -i zwave)? Is security enabled in the controller settings? Do you see SECURITY_INCLUSION_FAILED anywhere in your logs? When selecting the lock’s Thing in Habmin, under Attributes> Security, do you see a red X or green checkmark?

Yale version: YRD220
No other secure devices.
Latest .jar (Oct 24)

bundle:list |grep -i zwave
235 | Installed |  80 | 2.2.0.201710172006     | ZWave Binding
236 | Active    |  80 | 2.2.0.201710241752     | ZWave Binding

Is security enabled in the controller settings?
In habmin under security it has a question mark. I don’t know where else to look, I don’t see any other mentions of security under this thing.

No I do not.

I see a green checkmark.

This is in the database and other people are using it successfully.

You have two zwave bindings installed. They both have security, but probably best to clean that up. If you only have the one jar in addons, an OH restart should fix it. Ghost bindings can be a pain to get rid of sometimes. When updating the binding, keep the name the same and overwrite the old one. I always shut OH down before updating too.

Select the controller, select Tools (top right)> Advanced, then look under Zwave Network Settings> Secure Inclusion Mode. You probably should chose Entry Control Devices, if you are only using a lock. [Nevermind… if it’s securely included then this is not an issue]

This is a good sign. The lock should be securely included and may still be initializing. Depending on the number of devices, this can take a while.

When I click on tools, after selecting advanced options I only have 4 choices:
Soft Reset Controller
Hard Reset Controller
Exclude Devices
Synchronize Network

Once Advanced is selected, there will be more options available within the Thing.

BEFORE

AFTER

Thanks allot for your help so far, really appreciated.

So if my settings, once advanced is selected, are like you describe then it means it might just need more time before it might work?

You are very welcome! :+1:

If you have a green checkmark next to security, then you’re securely paired, so security is enabled. I don’t know if having the two bindings installed could cause any problems though, so I’d shutdown OH, check to make sure only one jar is in addons, and then restart OH and check that only the one shows up. Then wait :slight_smile:.

But how do you know it is not working? Did you get your items setup and it doesn’t respond to changes in the UI?

Extra binding removed and waiting… while I wait I see alot of things like this:

[DEBUG] [nal.protocol.ZWaveTransactionManager] - Completing UNINTIALIZED transaction 310!!! How?!?

and

 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 9: notifyTransactionResponse TID:318 CANCELLED
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - STOP transaction timer
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 318: Transaction event listener: DONE: CANCELLED -> 
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 9: -- To notify -- TIMEOUT_WAITING_FOR_DATA
 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ********* Transaction Response Complete 318 -- 
 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 9: Node Init response (2) TIMEOUT_WAITING_FOR_DATA
 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 9: No data from device, but it was ACK'd. Possibly not supported? (Try 2)

I believe I have it setup correctly, when I use the switch “door_lock” the lock doesn’t do anything. Im assuming I should have control over the deadbolt. Battery level also does not get updated.

ITEMS
Switch  BackDoorLock            "Back Door Lock"                                (Switches)      { channel="zwave:device:controller:node9:lock_door"}
Contact BackDoorAlarm           "Back Door Alarm"                               <doorlock>      { channel="zwave:device:controller:node9:alarm_general"}
String  BackDoorAlarmS          "Back Door String"                                                      { channel="zwave:device:controller:node9:alarm_raw"}
Number  BackDoorB                       "Back Dooy Battery"                                                     { channel="zwave:device:controller:node9:battery-level"}

SITEMAP
Switch item=BackDoorLock
Text item=BackDoorB

I have my yale keyfree working, chris too, for me it was more about the order I setup, as said, if you are securely locked, great but if you do have multiple versions of jar file, expect conflicts… This is in testing phase and not likely setup to handle it…

Mine is the version that has the keys, no idea if that matters.

What was the order you set them up?

I now only have one version of the jar, quick question, if I remove the Thing from openhab and do a discovery again will I run into any conflicts with security? The problem I’m getting is that each time I exclude this lock and include it again I increment up on my node count, and it appears that the node numbers (currently 6-8) I may not be able to use in the future? (Aeon ZStick btw)

After it gets to 232 nodes, the zstick will wrap around to start at 1 again. If you are getting a green checkmark, then there should not be any need to exclude/include the lock. You can delete the Thing and/or delete the xml and everything will go back in place. But you shouldn’t need to… there must be something else going on. Did you include the device close to the zstick and mount it far away? You could be having some coverage issues in your zwave network and the lock just can’t communicate with the zstick. What is returned when you enter smarthome:things list |grep node9 in the Karaf console?

The logs you’ve posted really don’t paint a big enough picture (for me, at least!) on what is going on. Share a log file that goes from startup until you see a green checkmark again, and include some turns of the lock. Or you could put it in Chris’ log viewer and see if you can spot anything (filter it on the node of your lock).

I also use the aeon zstick, and my lock has the key function too.

when you reset, you have to clear from openhab, the zstick and the door, this meant:

  1. unregistering openhab on the door module
  2. heal the zstick
  3. remove the binding

I had to then go into inclusion mode on openhab and ensure the door wasn’t automatically being picked up without putting the door into inclusion mode - this results in an insecure pairing.

put the door in inclusion mode and it gets picked up - I had to refresh the screen because initially it only shows “node 3” with some missing info, refreshing then showed the whole door info.

For a long time I got an issue where 2 input fields in the door settings wouldn’t update and had -1 set, I can’t remember how I rectified this, but I had switched from paperUI to habmin which gave a different interface to the bundle data.

Being honest, if you have a ton of nodes to setup, it may be best to unregister everything and start from scratch on a clean openHab just to test, I don’t know if there is an easy export / import functionality on openHab, but clearing the data on zwave, openhab and the door was critical in getting it properly registered.

I guess this means reset the lock? Or exclude it from the system?

This is for sure not needed :wink:

The most important thing is to ensure that the lock is completely reset. This is normally completed as part of the exclusion process - put the controller into exclusion mode in HABmin, then press whatever buttons are needed on the lock to put it into exclusion mode. This should reset the lock.

This is normal since the initial inclusion doesn’t provide this information. It is updated after the inclusion completes and the device interrogation starts - this normally takes 5 or 10 seconds depending on the device.

Yes, reset the lock, this is because the locks zwave module stores information on the network it last connected to, a full reset was the only way I was able to successfully pair after a failed attempt.

Note that if you try to just unbind the lock, this MUST be done first before clearing openhab / zstick, if you unbind the door last, the lock will give an error sound when trying to remove.

I only advise because it rules out any possibility of a conflict from previous parameters that may not be valid anymore (for me I had -1 as a value for certain parameters that broke the binding)

What do you mean by “clearing the stick”? The only thing to do here should be to exclude the device. Exclusion should remove the device from the stick, and also reset the device.

The Z-Wave standard states that the lock should reset even if it’s already excluded, so while it might sound an error, it should still reset.

I’m not sure what parameters you mean since when you delete the thing, it should remove everything, and if you don’t delete the thing, a new thing is in any case going to be created as there will be a new node ID.

To unregister the network on the lock, I needed to put the zstick close to the door, and into exclusion mode, then put the door in exclusion mode, even though it was a couple of meters away.

however that doesn’t reset the device, that just frees up the lock to join another network. My guess is that there is a file with parameters stored in the module, that is only cleared on full reset or joining a new network. Either way, it was the only way I could successfully register the lock.

I see, then just personal preference and piece of mind then. I don’t know what the code is doing so I prefer full clearance.

Are you sure? It should reset it - I’m pretty sure this is required by the standard.

I guess I’m just a bit worried that you’re drawing an incorrect conclusion - you did something, and it worked, so you assume it’s needed (a fair assumption). It doesn’t actually mean it is, and we need to be careful that we’re not making it harder for people than it really needs to be :wink: .

I have the same (I guess) Yale keyfree lock and don’t have any of the problems you see. I only exclude the device to reset it and I can then immediately include it securely again. I don’t have to restart the binding or anything like this…

Each thing is independent so if you create a new thing, it shouldn’t interact with another thing…

agreed I don’t want to be giving more work than required, but I did try pretty extensively and that was the only way to get it into a working condition from a failure… but then this is coming from someone who had 2 broken zsticks and 2 broken zwave door modules at the same time. :relaxed:

Yes but that is resetting from an already successful pairing. Once it works it’s great, but getting it to work is a lot of trial and error.