Z-Wave restart never progresses beyond ping

After ongoing issues with using Z-Wave through OpenHAB, I used Zensys to remove all ghost nodes from a Z-Stick 5, relocated the controller to a central position, and installed a fresh openHABian on a new Raspberry Pi 4.

Upon initial install the ~85 mostly-powered Z-Wave devices were discovered. Lights could be controlled from OpenHAB. I cleanly shutdown and rebooted the Raspberry Pi, but OpenHAB never progressed any device status beyond “online - ping”.

After 90 minutes of waiting and collecting logs (a debug log is here) the issue seems to be overwhelming traffic levels. However the openHABian could successfully control everything before reboot, plus when I plugged the Z-Stick back into Hubitat at the same physical location it was able to immediately control every device without issue.

The most chatty devices are Aeotec MultiSensor 6 units (I have about 27) however they were all set to “selective reporting” on Habitat and this appears to be the case based on Habitat logging. Despite this the OpenHAB Thing properties for each claims selective reporting is off, and attempting to change this property fails to be delivered to the node (eg refer to the log at timestamp 17:15:56.470 for node 8).

I am wondering if this issue is something deeper in OpenHAB given it could successfully control my devices before reboot and Hubitat uses the same Z-Stick at the same location and immediatey controls everything. Is there another version I can try?

Or is there something else I should do next? For example I could move the MultiSensors to a different Z-Stick and different OpenHAB but would prefer to avoid the extra network complexity of integrating multiple OpenHAB installations (and effort of moving so many devices between Z-Sticks).

Is having ~85 devices (many of which are sensors) on a single Z-Wave network a reasonable thing to do in the first place?

Your story is somewhat messy… what is Hubitat?
And did you now move the controller to a different location or not ? Or forth and back ?

I suspect your issues are related to that you moved the controller physically. All nodes store neighbour reachability information, moving a node far enough that some nodes get out of direct range requires to update the routing information on the node itself and all of its neighbours.
Now to physically move the controller (which has the most neighbours) obviously is the most impacting action of all.

A different smart home system and hub.

I would probably agree with @mstormi - this might be caused by moving the network around. A few devices are clearly sending a LOT of frames - likely completely flooding the network -:


These events continue for many seconds, and seem to occur on a number of nodes.

When the binding tries to send data, it is rejected by the controller - probably as it has no memory to process the new frame -:

It’s hard to be sure why this is happening. You could try resetting some of the devices to see if it helps.

Thanks @mstormi and @chris for your suggestions.

I ran several “repair network” commands via the Hubitat after relocating it to the middle of the house a few days ago. I believed this had worked based on the Hubitat stating it completed successfully, but just to be sure today I used Z-Wave PC Controller 5 5 to verify and found it had not.

For the benefit of the archive, what I did to correct this today was use Z-Wave PC Controller 5’s “Network Topology” to review the controller node’s (ID 1) direct access to other nodes. Then I went through every device in “Network Management” and performed a “Neighbors Update”. I again checked the “Network Topology” to ensure most had direct access. Then I conducted several “ERTT” (enhanced reliability test) to verify all devices could be reached. I also reviewed the tool’s “Log” to ensure network traffic levels were reasonable (in my case around 15 events per minute).

I then moved the Z-Stick to the OpenHAB Raspberry Pi and did a few reboots to observe how long until all nodes reached “Online” state. They now reach such state within 10 minutes, which is good enough given the Raspberry Pi is on a UPS so unlikely to reboot very often.

Thanks again for your help!

3 Likes

That should be the same as the heal on each individual Thing in OH.