A few months ago, I migrated from the Zooz ZST39 stick to the ZWA2.
Everything went smoothly - all I had to do was change the stick configuration in Z-Wave JS UI, and restore the NVM.
Today, I tried to do the reverse. There were several reasons for this. One was to see if I had hardware redundancy.
I ran into a couple issues :
- after the NVM restore, there were more nodes on the ZST39 than the ZWA2. Specifically, all the nodes that used to be linked with the ZST39, but which I had subsequently excluded when using the ZWA2, were present.
It appears that the NVM restore process does not overwrite the content of the NVM, but rather is a merge process.
I was able to get past this by doing a factory reset of the ZST39, and then restoring the NVM once again.
I think it would be good to document that restore is a merge, not overwrite. And maybe also add a checkbox to automatically reset the stick before restore.
- More problematic is that the ZST39 stick locked up many times in the few minutes following the restore.
2025-11-17 19:11:39.097 CNTRLR The controller is jammed
It did subsequently recover shortly after, though.
I see two nodes out of 124 with invalid status. Both are Kwikset HC620.
One HC620 is showing as “Unknown” in the status column in ZUI. If I manually ping it, the controller immediately jams. The GUI shows “controller is unable to transmit”. This is 100% reproducible.
2025-11-17 19:28:08.919 CNTRLR » [Node 017] pinging the node...
2025-11-17 19:28:08.920 DRIVER one or more queues busy
2025-11-17 19:28:08.921 DRIVER » [Node 017] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x01
│ callback id: 8
└─[NoOperationCC]
2025-11-17 19:28:08.921 SERIAL » 0x010f00a900010011010001000000000841 (17 bytes)
2025-11-17 19:28:09.010 SERIAL « [ACK] (0x06)
2025-11-17 19:28:09.011 SERIAL « 0x010401a90152 (6 bytes)
2025-11-17 19:28:09.012 SERIAL » [ACK] (0x06)
2025-11-17 19:28:09.012 DRIVER « [RES] [SendDataBridge]
was sent: true
2025-11-17 19:28:09.018 SERIAL « 0x011d00a9080200000000000000000000000000000000000000000000000041 (31 bytes)
2025-11-17 19:28:09.018 SERIAL » [ACK] (0x06)
2025-11-17 19:28:09.018 DRIVER « [REQ] [SendDataBridge]
callback id: 8
transmit status: Fail, took 0 ms
2025-11-17 19:28:09.019 CNTRLR The controller is jammed
2025-11-17 19:28:10.020 DRIVER » [Node 017] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x01
│ callback id: 8
└─[NoOperationCC]
2025-11-17 19:28:10.021 SERIAL » 0x010f00a900010011010001000000000841 (17 bytes)
2025-11-17 19:28:10.026 SERIAL « [ACK] (0x06)
2025-11-17 19:28:10.027 SERIAL « 0x010401a90152 (6 bytes)
2025-11-17 19:28:10.027 SERIAL » [ACK] (0x06)
2025-11-17 19:28:10.028 DRIVER « [RES] [SendDataBridge]
was sent: true
2025-11-17 19:28:10.033 SERIAL « 0x011d00a9080200000000000000000000000000000000000000000000000041 (31 bytes)
2025-11-17 19:28:10.033 SERIAL » [ACK] (0x06)
2025-11-17 19:28:10.033 DRIVER « [REQ] [SendDataBridge]
callback id: 8
transmit status: Fail, took 0 ms
2025-11-17 19:28:11.034 DRIVER » [Node 017] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x01
│ callback id: 8
└─[NoOperationCC]
2025-11-17 19:28:11.034 SERIAL » 0x010f00a900010011010001000000000841 (17 bytes)
2025-11-17 19:28:11.039 SERIAL « [ACK] (0x06)
2025-11-17 19:28:11.041 SERIAL « 0x010401a90152 (6 bytes)
2025-11-17 19:28:11.041 SERIAL » [ACK] (0x06)
2025-11-17 19:28:11.042 DRIVER « [RES] [SendDataBridge]
was sent: true
2025-11-17 19:28:11.047 SERIAL « 0x011d00a9080200000000000000000000000000000000000000000000000041 (31 bytes)
2025-11-17 19:28:11.047 SERIAL » [ACK] (0x06)
2025-11-17 19:28:11.047 DRIVER « [REQ] [SendDataBridge]
callback id: 8
transmit status: Fail, took 0 ms
2025-11-17 19:28:12.048 DRIVER » [Node 017] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x01
│ callback id: 8
└─[NoOperationCC]
2025-11-17 19:28:12.049 SERIAL » 0x010f00a900010011010001000000000841 (17 bytes)
2025-11-17 19:28:12.053 SERIAL « [ACK] (0x06)
2025-11-17 19:28:12.055 SERIAL « 0x010401a90152 (6 bytes)
2025-11-17 19:28:12.055 SERIAL » [ACK] (0x06)
2025-11-17 19:28:12.055 DRIVER « [RES] [SendDataBridge]
was sent: true
2025-11-17 19:28:12.060 SERIAL « 0x011d00a9080200000000000000000000000000000000000000000000000041 (31 bytes)
2025-11-17 19:28:12.061 SERIAL » [ACK] (0x06)
2025-11-17 19:28:12.061 DRIVER « [REQ] [SendDataBridge]
callback id: 8
transmit status: Fail, took 0 ms
2025-11-17 19:28:13.062 DRIVER » [Node 017] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x01
│ callback id: 8
└─[NoOperationCC]
2025-11-17 19:28:13.062 SERIAL » 0x010f00a900010011010001000000000841 (17 bytes)
2025-11-17 19:28:13.067 SERIAL « [ACK] (0x06)
2025-11-17 19:28:13.068 SERIAL « 0x010401a90152 (6 bytes)
2025-11-17 19:28:13.069 SERIAL » [ACK] (0x06)
2025-11-17 19:28:13.069 DRIVER « [RES] [SendDataBridge]
was sent: true
2025-11-17 19:28:13.075 SERIAL « 0x011d00a9080200000000000000000000000000000000000000000000000041 (31 bytes)
2025-11-17 19:28:13.075 SERIAL » [ACK] (0x06)
2025-11-17 19:28:13.075 DRIVER « [REQ] [SendDataBridge]
callback id: 8
transmit status: Fail, took 0 ms
2025-11-17 19:28:13.076 DRIVER Attempting to recover jammed controller...
2025-11-17 19:28:13.076 CNTRLR Performing soft reset...
2025-11-17 19:28:13.076 DRIVER » [REQ] [SoftReset]
2025-11-17 19:28:13.076 SERIAL » 0x01030008f4 (5 bytes)
2025-11-17 19:28:13.079 SERIAL « [ACK] (0x06)
2025-11-17 19:28:13.080 CNTRLR Waiting for the controller to reconnect...
2025-11-17 19:28:13.080 DRIVER all queues idle
2025-11-17 19:28:13.191 SERIAL « 0x010e000a07000100000001031d0000e2 (16 bytes)
2025-11-17 19:28:13.191 SERIAL » [ACK] (0x06)
2025-11-17 19:28:13.191 DRIVER « [REQ] [SerialAPIStarted]
wake up reason: SoftwareReset
watchdog enabled: false
generic device class: 0x00
specific device class: 0x00
always listening: false
supports Long Range: true
2025-11-17 19:28:13.191 CNTRLR reconnected and restarted
2025-11-17 19:28:13.192 CNTRLR Starting hardware watchdog...
2025-11-17 19:28:13.192 CNTRLR Switching serial API to 16-bit node IDs...
2025-11-17 19:28:13.192 DRIVER one or more queues busy
2025-11-17 19:28:13.192 DRIVER » [REQ] [StartWatchdog]
2025-11-17 19:28:13.193 SERIAL » 0x010300d22e (5 bytes)
2025-11-17 19:28:13.193 DRIVER » [REQ] [SerialAPISetup]
command: SetNodeIDType
node ID type: 16 bit
2025-11-17 19:28:13.193 SERIAL » 0x0105000b800273 (7 bytes)
2025-11-17 19:28:13.195 SERIAL « [ACK] (0x06)
2025-11-17 19:28:13.197 SERIAL « [ACK] (0x06)
2025-11-17 19:28:13.198 SERIAL « 0x0105010b800171 (7 bytes)
2025-11-17 19:28:13.198 SERIAL » [ACK] (0x06)
2025-11-17 19:28:13.199 DRIVER « [RES] [SerialAPISetup]
command: SetNodeIDType
success: true
2025-11-17 19:28:13.199 CNTRLR Switching to 16-bit node IDs successful
2025-11-17 19:28:13.199 DRIVER » [Node 017] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x01
│ callback id: 8
└─[NoOperationCC]
2025-11-17 19:28:13.199 SERIAL » 0x010f00a900010011010001000000000841 (17 bytes)
2025-11-17 19:28:13.203 SERIAL « [ACK] (0x06)
2025-11-17 19:28:13.205 SERIAL « 0x010401a90152 (6 bytes)
2025-11-17 19:28:13.205 SERIAL » [ACK] (0x06)
2025-11-17 19:28:13.205 DRIVER « [RES] [SendDataBridge]
was sent: true
2025-11-17 19:28:13.210 SERIAL « 0x011d00a9080200000000000000000000000000000000000000000000000041 (31 bytes)
2025-11-17 19:28:13.211 SERIAL » [ACK] (0x06)
2025-11-17 19:28:13.211 DRIVER « [REQ] [SendDataBridge]
callback id: 8
transmit status: Fail, took 0 ms
2025-11-17 19:28:13.211 DRIVER Automatic controller recovery failed. Returning to normal operation and hoping
for the best.
2025-11-17 19:28:13.211 CNTRLR The controller is no longer jammed
2025-11-17 19:28:13.212 CNTRLR [Node 017] ping failed: Failed to send the command after 1 attempts (ZW0202)
2025-11-17 19:28:13.212 DRIVER all queues idle
This Node 17 is an HC620, which was paired originally with the ZST39, prior to the migration to the ZWA2.
The other HC620 is showing as “Dead”. If I ping it, it times out, but the controller does not jam when trying to ping it. This is a very distant node. But it also was paired with the ZST39 prior to the migration to the ZWA2, and used to work.
The ZST39 is using the latest 1.60 firmware from Zooz.
The conclusion of my test is that the ZST39 is not currently working 100% as redundant backup hardware for the ZWA2. The jamming is a little concerning.