~20 minute delay when completing lock interview on server start

Describe the bug

When I restart the server, my 3 Kwikset 914 locks have a ~20min unexpected delay after retrieving usercodes and before transitioning from RestartFromCache to Complete. These locks have all been added securely and allowed to complete their interview, but this delay is observed every time when the zwjs server restarts.

The logs below are with “INFO” enabled, but the pattern is also present with “DEBUG” and I’ve included the log with debug enabled below. zwavejs2mqtt-debug.zip

Scan starts here:

2021-02-17 16:59:40.106 INFO MQTT: Connecting to mqtt://192.168.1.159:1883
2021-02-17 16:59:40.156 INFO ZWAVE: Connecting to /dev/ttyACM0
2021-02-17 16:59:40.178 INFO APP: Listening on port 8091 host 0.0.0.0 protocol HTTP
2021-02-17 16:59:40.225 INFO MQTT: MQTT client connected
2021-02-17 16:59:45.691 INFO ZWAVE: Zwave driver is ready
2021-02-17 16:59:45.692 INFO ZWAVE: Controller status: Driver ready
2021-02-17 16:59:45.706 INFO ZWAVE: Scanning network with homeid: 0xe92faa0a

The scan proceeds, setting most line-powered nodes “Complete”, and retrieves all 30 usercodes from all 3 locks. At ~17:06:xx, metadata for the 112-0-xx parameters is updated for all 3 locks (sample of last communication):

2021-02-17 17:06:30.155 INFO ZWAVE: Node 64: metadata updated: 112-0-31-4
2021-02-17 17:06:30.156 INFO ZWAVE: Node 64: metadata updated: 112-0-31-8
2021-02-17 17:06:32.127 INFO ZWAVE: Node 44: value updated: 112-0-1 1 => 1
2021-02-17 17:06:33.603 INFO ZWAVE: Node 45: value updated: 112-0-1 1 => 1

At this point, all 3 locks are marked RestartFromCache, and remain that way for exactly 20 minutes. During this time, there is no activity to any of the three locks, but other nodes report in and work properly. After 20mins, I finally see some activity with the locks that goes like this:

2021-02-17 17:26:24.938 INFO ZWAVE: Node 44: value updated: 112-0-33 960049460 => 960049460
2021-02-17 17:26:26.450 INFO ZWAVE: Node 45: value updated: 112-0-33 960049460 => 960049460
2021-02-17 17:26:28.394 INFO ZWAVE: Node 64: value updated: 112-0-33 960049460 => 960049460
2021-02-17 17:26:30.384 INFO ZWAVE: Node 44: value updated: 112-0-34 808464947 => 808464947
2021-02-17 17:26:31.839 INFO ZWAVE: Node 45: value updated: 112-0-34 808464947 => 808464947
2021-02-17 17:26:32.424 INFO ZWAVE: Node 64: value updated: 112-0-34 808464947 => 808464947
2021-02-17 17:26:33.083 INFO ZWAVE: Node 44: value updated: 112-0-31-1 1 => 1
2021-02-17 17:26:33.086 INFO ZWAVE: Node 44: value updated: 112-0-31-2 0 => 0
2021-02-17 17:26:33.088 INFO ZWAVE: Node 44: value updated: 112-0-31-4 1 => 1
2021-02-17 17:26:33.092 INFO ZWAVE: Node 44: value updated: 112-0-31-8 0 => 0
2021-02-17 17:26:33.325 INFO ZWAVE: Node 45: value updated: 112-0-31-1 1 => 1
2021-02-17 17:26:33.328 INFO ZWAVE: Node 45: value updated: 112-0-31-2 0 => 0
2021-02-17 17:26:33.330 INFO ZWAVE: Node 45: value updated: 112-0-31-4 1 => 1
2021-02-17 17:26:33.332 INFO ZWAVE: Node 45: value updated: 112-0-31-8 0 => 0
2021-02-17 17:26:33.756 INFO ZWAVE: Node 42: value updated: 50-0-value-66049 0 => 0
2021-02-17 17:26:33.758 INFO ZWAVE: Node 42: value updated: 50-0-deltaTime-66049 0 => 0
2021-02-17 17:26:33.933 INFO ZWAVE: Node 64: value updated: 112-0-31-1 1 => 1
2021-02-17 17:26:33.936 INFO ZWAVE: Node 64: value updated: 112-0-31-2 0 => 0
2021-02-17 17:26:33.938 INFO ZWAVE: Node 64: value updated: 112-0-31-4 1 => 1
2021-02-17 17:26:33.940 INFO ZWAVE: Node 64: value updated: 112-0-31-8 0 => 0
2021-02-17 17:26:36.311 INFO ZWAVE: Node 44: interview completed, all values are updated
2021-02-17 17:26:36.324 INFO ZWAVE: Node 45: interview completed, all values are updated
2021-02-17 17:26:36.919 INFO ZWAVE: Node 64: interview completed, all values are updated

When this happens, the locks are finally all marked Complete. Other nodes work fine during this 20 minute delay, both battery and line-powered. When these locks are finally marked complete, they work fine remotely and when manually actuated. The locks are marked “Alive” during this whole time, as viewed from the ZWJS2MQTT web ui.

I started to notice this behavior when the change to ignore sleeping nodes when marking the scan complete, but it’s possible that it’s been this way for a while.

Device information

Which device(s) is/are affected (make/model)? Kwikset 914 locks What are the node IDs? 44, 45, 64

Last Known Working Configuration

• New device

• Previously working device (node-zwave-js)

  • Which library version/docker image/adapter version?
  • Have you made any recent configuration changes to the device? Describe.

• Previously working device (other platform)

  • Which platform?
  • Have you made any recent configuration changes to the device? Describe.

Installation information How did you install node-zwave-js?

• zwavejs2mqtt (latest) docker image
• zwavejs2mqtt (dev) docker image
• ioBroker.zwave2 adapter
• Pkg
• Manual Docker build
  • node-zwave-js branch: master
  • zwavejs2mqtt branch: master
• Manually built (as described in the docs)
• Other:

To Reproduce Steps to reproduce the behavior:

1. Restart the zwjs2mqtt server and monitor the zwjs2mqtt web ui and log
2. Observe 20 minute delay in communication with a Kwikset 914 lock between reading the usercodes and finally marking the device “Complete”

Additional context Add any other context about the problem here.

Logfile:

Here’s a log with “INFO” enabled: zwavejs2mqtt.log

Here’s a log with “DEBUG” enabled with the same behavior (search for “Node 45” from the bottom until you see the 20 minute gap): zwavejs2mqtt-debug.zip

[rccoleman]

Yes, I did. All I saw were power reports from my Aeotec SmartSwitch 6 and motion sensor reports, appearing to be pretty darn quiet. I’ll try to enable zwjs logs to see if I can see any other traffic going on.

[rccoleman]

Correct, it’s a correlation between the UserCodeCC values and the config parameters.

I think this is now well-understood and the mitigation will be the PR to eliminate the query-on-start. There will still be a delay following inclusion that cannot be avoided. I’m going to go ahead and close it.

Thanks, folks.