Schlage FE599NX not updating

Add-ons Bindings
,
1

I have recently purchased a Schlage FE599NX zwave lock. I’m running with the ZWave binding 2.5.0.201901061034. I believe that should include the security features. I put the z-stick into inclusion mode from paper UI. I can lock and unlock the lock from the controller. I can send new User codes to the device. But when a user enters a code at the lock itself it doesn’t get registered with the controller. I get the response below about the response not being security encapsulated.

Has anyone had any luck with this Lock? Is this an issue with the item database? Should the Command Class Basic not have a check under Sec?

I also don’t seem to get any notification when the Lock and Unlock button are pressed on the lock itself.

Thanks

01:53:21.669 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0D 00 49 84 14 07 04 40 03 85 73 72 98 77
01:53:21.672 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationUpdate[73], type=Request[0], dest=20, callback=132, payload=84 14 07 04 40 03 85 73 72 98
01:53:21.673 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationUpdate[73], type=Request[0], dest=20, callback=132, payload=84 14 07 04 40 03 85 73 72 98
01:53:21.674 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - lastTransaction null
01:53:21.675 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 0
01:53:21.676 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Last transaction: null
01:53:21.677 [DEBUG] [ave.internal.protocol.ZWaveController] - Incoming Message: Message: class=ApplicationUpdate[73], type=Request[0], dest=20, callback=132, payload=84 14 07 04 40 03 85 73 72 98
01:53:21.678 [DEBUG] [message.ApplicationUpdateMessageClass] - NODE 20: Application update request. Node information received. Transaction null
01:53:21.679 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 20: resetResendCount initComplete=true isDead=false
01:53:21.679 [DEBUG] [message.ApplicationUpdateMessageClass] - NODE 20: Application update - no transaction.
01:53:21.681 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
01:53:21.681 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
01:53:30.027 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 14 03 20 01 FF 3B
01:53:30.028 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=20, callback=0, payload=00 14 03 20 01 FF
01:53:30.030 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=20, callback=0, payload=00 14 03 20 01 FF
01:53:30.031 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - lastTransaction null
01:53:30.032 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 20: Application Command Request (ALIVE:DONE)
01:53:30.033 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 20: resetResendCount initComplete=true isDead=false
01:53:30.034 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 20: Incoming command class COMMAND_CLASS_BASIC, endpoint 0
01:53:30.035 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 20: SECURITY required on COMMAND_CLASS_BASIC
01:53:30.035 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 20: Command Class COMMAND_CLASS_BASIC was required to be security encapsulated but it wasn't! Message dropped.
01:53:30.036 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 20: Commands processed 0.
01:53:30.037 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
01:53:30.038 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2

I think I’ve made some progress. Apparently there is a second Association Group. I had to use curl to update that as it doesn’t show up on Paper UI. When I set it to node_1 I could see in the debug log that the controller would get a report when the physical lock/unlock button was pressed. I don’t believe that was actually updating the DoorLock item however, but at least now I know the device is sending something. I’ll be updating the Device Database with that group so it will show up in Paper UI in the future.

It has me wondering if the first association group is where the report of a user entering a code at the door is coming from. And if maybe that is the message that isn’t securely encapsulated.

Edit:
I captured this output of the Door-Lock state report:

12:24:23.404 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 20: Application Command Request (ALIVE:DONE)
12:24:23.406 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 20: resetResendCount initComplete=true isDead=false
12:24:23.407 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 20: Decapsulating COMMAND_CLASS_SECURITY
12:24:23.409 [DEBUG] [ommandclass.ZWaveSecurityCommandClass] - NODE 20: SECURITY_RXD 62 03 00 00 00 FE FE
12:24:23.411 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 20: Incoming command class COMMAND_CLASS_DOOR_LOCK, endpoint 0
12:24:23.412 [DEBUG] [otocol.commandclass.ZWaveCommandClass] - NODE 20: Received COMMAND_CLASS_DOOR_LOCK V1 DOOR_LOCK_REPORT
12:24:23.413 [DEBUG] [ommandclass.ZWaveDoorLockCommandClass] - NODE 20: Door-Lock state report - lockState=Unsecured, handlesMode=0, doorCondition=0, timeoutMinutes=254, timeoutSeconds=254
12:24:23.414 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 20: Commands processed 1.
12:24:23.415 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 20: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@770c64bc.
12:24:23.416 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 20: Command NOT verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@770c64bc.

But my switch item linked to the lock_door channel doesn’t seem to get updated.