Zwave: Wrong exclusion of node, network failure

Tags: #<Tag:0x00007fc90dfd6ed8>

I set up OH3 from scratch including zwave with around 20 devices. All worked well until I noticed that some window sensors stopped communicating with the controller, although not shown as offline.

Finally I decided to exclude one of them (window sensor) to see if re-inclusion would solve the issue.
OH showed that a completely different Node (thermostat) got exluded…

Both devices did not acknowledge any exclusion so the controller still listed the window sensor but no longer the thermostat but both the window sensor and the thermostat still ‘regarded’ themselves as part of the network.

Rebooting OH , as expected, did not change anything, but now all devices had stopped to communicate with the controller.

Finally I did a hard reset of the controller and, as a test, a factory-reset of two other window sensors and removed all XML files except for the controller’s XML. Then included these two sensors into the new network around two days ago. Also adjusted the orphaned items to the two new nodes.
These sensors show up in the new network (as known devices) but do not communicate to the controller yet, no XML files were generated for them so far. I wake them up continuously.

Now I am lost what caused the initial mix-up of Nodes leading to excludung a different node than intended.
Also I wonder whether my procedure of hard-resets, etc. is the correct way at all to recover everything.
And even after recovery I fear that the same issues might happen again.

What could have caused the node mix-up and how to detect this earlier?
Any help or comments of more experienced zwave users are much appreciated.
Thank you.

Very possibly the battery operated devices were not fully discovered. following the instructions in the binding documentation to enable DEBUG logging would have permitted the system to tell us what was happening.

Why?? I have never heard of needing to do that. I would guess that would trigger a need for complete device re-discovery.

There is no way to determine that now.

According to the binding documentation & my personal experience, that was the wrong path. Hopefully your Z-Wave network does not now have a bunch of zombie nodes that could hamper performance.

The proper debugging process is listed under the heading for when things do not go as planned.

The rest of your issues are very strange (and, as Bruce says, require debug logs for anyone to make much sense of).

This particular behavior, however, has been seen by several people trying include certain battery devices in OH3 (here and here to name a few examples). Again, the cause of this is still not known so debug logs are doubly important to help us provide the dev with more information on what’s going on.

As a work around, depending on your setup, you may be able to use a different software to do the inclusion. I found that my three battery devices that failed repeatedly to be included by OH3 were all included completely on the first try with Open Zwave Control Panel and were then easily and fully discovered by OH3 and work 100% (Other software such as OZWCP will also let you erase any zombie nodes you may now have if you see performance issues as Bruce stated).

1 Like

Thanks for the explanations.

Sorry I completely forgot to mention that I switched on Debug mode to write in a separate file following the binding doc. before doing anything else to see the error messages if any.
The file zwave.log was created but not a single line written to it ever. No idea why.

To remove XML files in the process and to hard-reset was mentioned in that post here however I don’t want to say it was the correct way to do for my case. It seemed a possible solution.

One more information. The most recent two devices I included in the old network (an air quaility sensor and the mentioned thermostat did not have XML files. Ok, the thermostat’s could have dissapeared when the controller excluded it, but I don’t know when creation and deletion of these files occur normally) but there was also no XML for the air quality sensor although it worked flawlessly for weeks. Maybe this was part of the issues starting.

I understood a reset would mean to factory-reset all devices and include them again in the new network. But to me it seems like although the controller was reset and new known devices can be added there is still something wrong since the two added devices still remain silent but at least appear as online in OH …

I also wondered if other software could help in future. OZWCP seems unmaintained. Is is working?
What else is needed, a separate Zwave USB stick or can it be used alongside OH3 with the Razberry board I use?

Any more conclusions from all that?
Thanks again.

OZWCP is by no means fully featured and not particularly user-friendly, but for simple one-shot tasks like a quick network cleanup and including a device, I find that it works well enough. I have never used it with a Razberry, but I see no reason why it shouldn’t work.

You cannot use it along side of OH3, only one connection to the controller works at a time. You will have to stop OH, then boot up OZWCP and put the same device path into the web interface that you used to configure the zwave controller in OH.

There are almost certainly other, more user-friendly options out there that can accomplish the same thing; this just happens to be the one I use.

SiLabs PC Controller for Windows works too but you need to move the stick to a Windows computer.

I only have the Razberry board in my OH3 RasPi4. Maybe an additional stick to use from Windows would be a reasonable invest for the future.
Do I get it right, I have to create an account with SiLabs, download an SDK or their Simpliity Studio dev. platform and from there download the final znifffer tool, the PC Controller you mention?

Apart from that option, is there any way for me to see if the controller in OH3 now works correctly at all?
And any idea why there are no log data?
thanks for your help!