I updated an existing OH 2.5.10 installation on a Rpi3 to OH3 (originally M5, but now 3.0 release) using openhabian in mid-December. Regarding the z-wave binding, everything has worked until I recently activated a network heal. I normally have this feature “disabled” unless I add a new device as my 45 node network is responsive and well meshed. Note for clarity: if I change the network heal back to “disable” and stop/start Z-wave binding or OH3.0 I’m back to an error free and responsive network, but I would like to get this issue resolved.
I have collected z-wave Debug logs of the start of network heal and the problems relate to the controller/bridge identity. What I’m thinking is the network heal exposes an issue in my 2.5 to 3.0 transition. Specifically I did not manually add the controller in the OH3.0 UI as all seemed fine with the “heal” disabled. When I now go to the OH 3.0 z-wave inbox, I see a manually added controller item, which confuses me because I already have a controller. Also I noted the OH3.0 HomeID is 10 characters long and my controller has 8. My other concern is that all my nodes have the 8 character ID of the controller, so I don’t want to do a lot of rework. The other oddity is my Z-wave node XML files have a different 8 character Home ID than the “thing”. I was under the impression these needed to be the same, so maybe that’s the problem. I’m looking for guidance on how to fix with a minimum of rework on the other nodes.
Some messages extracted for the Debug logs that point to the Controller;
No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:f55aa6d7
zwave:serial_zstick:f55aa6d7 (Type=Bridge, Status=ONLINE, Label=Z-Wave Serial Controller, Bridge=null)
15:08:31.654 1 [**RX** **REQ** **RequestNodeNeighborUpdate** Neighbor update FAILED **0 /128**](https://opensmarthouse.org/utilities/logviewer/zwave/#info-112)
15:08:56.572 1 [**RX** **REQ** **RequestNodeNeighborUpdate** Neighbor update FAILED **0 /128**](https://opensmarthouse.org/utilities/logviewer/zwave/#info-116)
Incoming Message: Message: class=ApplicationUpdate[73], type=Request[0], dest=1, callback=64, payload=40 01 10 02 02 01 5E 86 72 73 80 71 85 59 84 30 70 EF 20
[WARN ] [essage.ApplicationUpdateMessageClass] - TODO: Implement Application Update Request Handling of New ID Assigned (64).
Note ID difference, not f55aa6d7