Keymaster unable to set codes on one connected lock

I had a power failure recently and when I regained power all the Schlage locks in the house needed all the codes resetting/readding through the Keymaster integration as everything showed disconnected and zero codes worked on any door (this I will address on the GitHub as this seems like it is a serious issue and it should not be clearing codes if it is not able to see the HA instance) this worked on all but one lock. I can still lock and unlock the lock through HA but Keymaster can’t set or rest any of the slots. I have tried both the default zwave integration and the zwavejs addon without any success.

I have read the BE469 have issues but I had this setup previously so I am not sure what is wrong.

Are you looking at the ZWAVE logs? Are you seeing any error?

I looked at the ones I could find but they were truncated so I was not sure the best place to look. I did get one message about not being able to check firmware, but I was not sure that would matter. Where is the correct place to check the zwave logs?

If you’re using ZWAVE_JS, Settings then Addon, select ZWAVE_JS, then the log tab.

That is where I am but no scroll bar to view all messages. This is as much as I get.

                                    · AddNodeToNetwork (0x4a)
                                    · RemoveNodeFromNetwork (0x4b)
                                    · AddControllerAndAssignPrimary (0x4c)
                                    · AddPrimaryController (0x4d)
                                    · SetLearnMode (0x50)
                                    · AssignSUCReturnRoute (0x51)
                                    · RequestNetworkUpdate (0x53)
                                    · SetSUCNodeId (0x54)
                                    · DeleteSUCReturnRoute (0x55)
                                    · GetSUCNodeId (0x56)
                                    · SendSUCNodeId (0x57)
                                    · ExploreRequestInclusion (0x5e)
                                    · RequestNodeInfo (0x60)
                                    · RemoveFailedNode (0x61)
                                    · IsFailedNode (0x62)
                                    · ReplaceFailedNode (0x63)
                                    · UNKNOWN_FUNC_UNKNOWN_0x66 (0x66)
                                    · UNKNOWN_FUNC_UNKNOWN_0x67 (0x67)
                                    · FirmwareUpdateNVM (0x78)
                                    · GetRoutingInfo (0x80)
                                    · LockUnlockLastRoute (0x90)
                                    · GetPriorityRoute (0x92)
                                    · SetPriorityRoute (0x93)
                                    · UNKNOWN_FUNC_UNKNOWN_0x98 (0x98)
                                    · undefined (0xb4)
                                    · EnableWatchdog500 (0xb6)
                                    · DisableWatchdog500 (0xb7)
                                    · KickWatchdog500 (0xb8)
                                    · UNKNOWN_FUNC_UNKNOWN_0xB9 (0xb9)
                                    · UNKNOWN_FUNC_RF_POWERLEVEL_GET (0xba)
                                    · GetLibrary (0xbd)
                                    · SendTestFrame (0xbe)
                                    · GetProtocolStatus (0xbf)
                                    · StartWatchdog (0xd2)
                                    · StopWatchdog (0xd3)
                                    · SetMaximumRoutingAttempts (0xd4)
                                    · undefined (0xee)
                                    · undefined (0xef)
2024-10-23T17:00:27.812Z CNTRLR   querying additional controller information...
2024-10-23T17:00:27.884Z CNTRLR   received additional controller information:
                                    Z-Wave API version:         5 (legacy)
                                    Z-Wave chip type:           ZW050x
                                    node type                   Controller
                                    controller role:            primary
                                    controller is the SIS:      true
                                    controller supports timers: false
                                    Z-Wave Classic nodes:       1, 2, 3, 4, 11
2024-10-23T17:00:27.884Z CNTRLR   querying version info...
2024-10-23T17:00:27.900Z CNTRLR   received version info:
                                    controller type: Static Controller
                                    library version: Z-Wave 4.05
2024-10-23T17:00:27.900Z CNTRLR   querying protocol version info...
2024-10-23T17:00:27.913Z CNTRLR   received protocol version info:
                                    protocol type:             Z-Wave
                                    protocol version:          4.5.0
2024-10-23T17:00:27.915Z CNTRLR   querying controller capabilities...
2024-10-23T17:00:27.928Z CNTRLR   received controller capabilities:
                                    controller role:      Primary
                                    is the SUC:           true
                                    started this network: true
                                    SIS is present:       true
                                    was real primary:     true
2024-10-23T17:00:27.930Z CNTRLR   supported Z-Wave features: 
2024-10-23T17:00:27.933Z CNTRLR   querying controller IDs...
2024-10-23T17:00:27.944Z CNTRLR   received controller IDs:
                                    home ID:     0xd6368055
                                    own node ID: 1
2024-10-23T17:00:27.945Z CNTRLR   finding SUC...
2024-10-23T17:00:27.956Z CNTRLR   This is the SUC
2024-10-23T17:00:27.956Z CNTRLR   setting serial API timeouts: ack = 1000 ms, byte = 150 ms
2024-10-23T17:00:27.967Z CNTRLR   serial API timeouts overwritten. The old values were: ack = 1000 ms, byte = 15
                                  0 ms
2024-10-23T17:00:28.119Z CNTRLR   [Node 001] Embedded device config loaded
2024-10-23T17:00:28.139Z CNTRLR   [Node 002] Embedded device config loaded
2024-10-23T17:00:28.155Z CNTRLR   [Node 003] Embedded device config loaded
2024-10-23T17:00:28.164Z CNTRLR   [Node 004] Embedded device config loaded
2024-10-23T17:00:28.184Z CNTRLR   Interview completed
Starting server on <all interfaces>:3000
2024-10-23T17:00:28.216Z CNTRLR   [Node 001] The node is alive.
2024-10-23T17:00:28.216Z CNTRLR   [Node 001] The node is ready to be used
2024-10-23T17:00:28.218Z CNTRLR   Interviewing nodes and/or determining their status: 2, 3, 11, 4
2024-10-23T17:00:28.219Z CNTRLR » [Node 002] pinging the node...
2024-10-23T17:00:28.353Z CNTRLR » [Node 003] pinging the node...
2024-10-23T17:00:28.356Z CNTRLR » [Node 011] pinging the node...
2024-10-23T17:00:28.360Z CNTRLR » [Node 004] pinging the node...
ZwaveJS server listening on <all interfaces>:3000
2024-10-23T17:00:28.399Z CNTRLR   [Node 002] The node is alive.
2024-10-23T17:00:28.400Z CNTRLR   [Node 002] The node is ready to be used
2024-10-23T17:00:28.401Z CNTRLR « [Node 002] ping successful
2024-10-23T17:00:29.656Z CNTRLR   [Node 003] The node is alive.
2024-10-23T17:00:29.657Z CNTRLR   [Node 003] The node is ready to be used
2024-10-23T17:00:29.658Z CNTRLR « [Node 003] ping successful
2024-10-23T17:00:30.930Z CNTRLR   [Node 011] The node is alive.
2024-10-23T17:00:30.931Z CNTRLR   [Node 011] The node is ready to be used
2024-10-23T17:00:30.931Z CNTRLR « [Node 011] ping successful
2024-10-23T17:00:32.185Z CNTRLR   [Node 004] The node is alive.
2024-10-23T17:00:32.186Z CNTRLR   [Node 004] The node is ready to be used
2024-10-23T17:00:32.187Z CNTRLR   All nodes are ready to be used
2024-10-23T17:00:32.188Z CNTRLR « [Node 004] ping successful
New client

I’m not sure but I think when I do anything on the lock through Keymaster it puts a line in the log stating New Client.

I also now know node 2 is the smart plug, node 4 is the front door but this is not very clear, and I wish there was a good way to figure out the nodes number to name.