@stefan.oh Here is as long a log as the 1MB upload limit will permit.oh.log (1004.9 KB)
Splendid 
The log covers app. 9h of time, that should give us an idea of what is happening.
I’ve uploaded the log into the Z-Wave Log Viewer that Chris provides on his website.
Looking at the Filter option I count only 27 nodes that take part in the communication. Your network map shows way more than these 27 nodes. Also in the network map I see #76 as the node with the highest number, but in the filter view of the log viewer there is a node #255. Filtering for this node does not give any hints, maybe this is just data garbage that cannot be associated with a single node.
Filtering randomly for one node, #61, shows some traffic. Temperature is reported, but it seems that you took care to avoid traffic: only changes of at least 0,5 degF are reported, or multiples of that. That’s good, avoiding unnecessary traffic is one of the top priorities in a network with limited bandwith but a lot of participating communication partners.
And to the next random node, #28. Only ONE message is shown. Either it is a node that has not much to report or it has no chance to do so. I cannot tell.
Node #8 is similar, only 2 points in time it is seen in the logs.
On to node #75. Now it gets interesting. There are several messages “DeleteSUCReturnRoute”. Is there more than one controller in your setup? What are the settings for your controller(s)?
Node #48: Only one point in time this node communicates. But it is shown that it took over 20 seconds to receive an acknoledgement from the device. Only 3 other nodes were communicating at 16:41:xx. That does not look like congestion of the network.
Node #55: Between 7:54 and 9:39 the node does not report anything, there are messages containing “DeleteSUC ReturnRoute”. But at 16:22 it starts reporting kWh, beginning every two minutes, then it becomes more erratic.
I cannot pinpoint something (to me) obvious. But I’m curious why a lot of nodes shown in your network view are not seen in the logfile.
Looking at the file without the logviewer at Chris’s website I see messages like
2020-12-27 08:04:32.099 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 23: SECURITY not supported
2020-12-27 08:04:32.099 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 23: Command Class COMMAND_CLASS_SWITCH_MULTILEVEL is NOT required to be secured
2020-12-27 08:04:32.102 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 29: SECURITY not supported
Are your devices included with security enabled? That puts a strain on all the processing, in the devices as well as on the controller. Maybe that is a hint.
Did you check the load on the system where OH is running?
2 Likes
This morning, I discovered one thing that may have caused the network to relapse.
I had unplugged a ‘smart’ power strip. It’s node #55 that you did spot. When I moved thing around before the trouble started, a printer was unplugged from that strip and another one plugged in. So I thought it could have been a contributing factor in the network problem. After a heal everything went well.
Yesterday night, I discovered that my spouse had plugged that strip back in… So that seems an indication that it might be a trigger of the trouble.
I unplugged it again and started a heal 43 minutes ago. The network is not back to normal yet. The heal takes a long time.
node75 is not something I see configured nor is it in the inbox.
node8 is a relay switch.
node28 is a dimmer and is physically the closest to the NUC/Zwave controller stick
node23 and node29 are dimmers. I have no idea why they show up with security.
I do have two door locks that have ZWave but I never paired them, so they should not appear in the log.
I have a memory that node255 represents the controller itself. I got this impression from some tinkering a long time ago and could be wrong.
As a side question. Issues of slowness have been dogging me throughout the use of OH/Zwave for about 5 years now. I’ve added Zigbee devices but have much fewer of those than ZWave (4 lightbulbs and 2 switches). Is zigbee also prone to issues and I am just lucky, or is it a more reliable network/protocol?
The system running OH has very low load. Its only use is to run OH.
The controller is usually #1 as far as I have seen it in the past. In your network map you will notice it is painted a bit bigger than the other nodes and has an orange ring.
I am a bit confused about the network map you posted on the one side and other information on the other side: the log does not show traffic for a lot of nodes printed in the network map. But the log shows entries for a node #75 that is NOT shown in the picture you posted. Is it one and the same installation we are looking at?
Sometimes it showed up as 255, for whatever reason …
Another discrepancy to the picture with the network map. There is no node #255 but node #1 is there. Or is the controller #1 AND #255? Maybe 
2 controllers? 
Yes, if this rare situation happens it is both … one controller, two node id’s.
But I am not able to explain that 
I think that is the situation I am having. The controller is #1 AND #255. Maybe it’s related to my problem.
I am not considering buying a new ZWave stick and transferring the settings from the one I have to the new one. I’ve seen an inexpensive SLUSB001A at digikey. Maybe it’s worth a try, though I have not seen much said about that stick.
That is a newer 700 Series stick ( Z-Wave Plus 2) I am not sure it would work with the current binding designed for the 500 Series (Z-Wave Plus) sticks.
1 Like
I don’t think so. In the past when this happened it was not the root cause of problems.
Why not going with @stefan.oh analytics from above:
Get rid of all the nodes which are not present anymore, in addition to that make a soft reset of the stick (shutdown the server, remove the stick, wait a couple of minutes, reinsert the stick and fire up openHAB)
1 Like
Correct, confirmed from Chris:
1 Like
I don’t think that is the issue. There are gaps in the node numbers because of having had to either replace or re-pair devices. But I do have all the nodes shown in the network and OH shows them all online. I’ve removed one device I thought might be the cause. For a while and after a heal it seemed to have worked.
It was plugged back in my spouse, I’ve redone the procedure and it is still not working.
What I really do not understand, fundamentally, is that the Zwave stick’s lights color change frequency goes down dramatically when the network is in trouble. Doesn’t that mean that on the stick’s side something unusual is going on? The log slows down as well dramatically. Is there a way to see what the stick is doing when flashing slowly?
Many times the nodes do not get completely excluded from the network, leaving zombie nodes on the controller which can mess up the network routing and cause performance issues.
How do you remove them? There is the node75 which I do not know at all why it’s there. It does not appear in the list of things nor in the inbox.
Edit: node 75 has now appeared in the inbox. Does hitting remove there remove it from the stick’s setup?
I normally use SiLabs PC Controller software on a Windows PC. It permits you to see & delete them.
Hi,
I’d agree with Bruce - connect the stick with the manufacturer’s debug software, or close as you can get to it and remove dead, unused, or unwanted devices. This may also allow you to update the controller firmware.
For a few months my Z-Wave network would stop for 120 seconds - clearly a timeout trying to connect to devices that had failed previously. As I use a RaZberry Z-Wave adapter on a RPi, the equivalent is Z-Way which allowed me to mark a device as failed, then remove failed devices. After also upgrading the firmware (several releases behind), my network is now stable.
Chris, mhilbush and others tried to implement the same controller commands to exclude a device, however under 2.5.x HABmin, the feature Remove device from the controller didn’t work for me - hence the need to use other lower-level software.
There’s several posts on the topic if the instructions Bruce posted arent enough (search for Remove device from the controller), but here’s the full-fat tech discussion about adding the exclude commands to openHAB itself:
It took me about an hour to build a Z-Way uSD, configure it, remove the nodes, and update the controller firmware. The USB stick you use should be easier to move to a different computer (ideally in the same location). Well worth considering as a maintenance task (once a year?).
TTFN,
James
I agree with James, removed some ghost devices and did firmware upgrades via z-way too.
Just as a little addition, I installed z-way on the same RPi, stopped OH and ran z-way then.
So no need for another hardware.
Interesting @chris4789 - didn’t know you could install Z-Way on the same OS install as openHAB (only running one at a time). Always learning! 
I guess there’s a trade off between the extra effort of building a separate uSD card for the same RPi, and the slight risk of breaking something on a production install of openHABian.