With that being said, if you want to post screenshots of your Z-Wave details page (from the C8) I can assist further if you want to see if we can get it working.
Also keep in mind that the migration purposefully does NOT carry over the device routing info so that the new hub can rebuild it all using the updated chipset and radio. So there can be some initial pain as the mesh is rebuilt.
Looks pretty clean. May want to do a shut down and unplug for 30 seconds first to ensure the radio hardware is freshly restarted.
Try a single repair on 0x05 or 0x06, see if it can pass the repair.
Could also try 0x01B, and also maybe try a refresh as well if the repairs are failing.
On the refresh, the only indication you get after, is if it works nothing changes, if it fails you get a "Remove" button for that node (do not click it!).
I am just picking basic devices that seem to have a direct connection and plenty of route options.
Shutdown/unplug/wait/restart has thus far not made any difference. I have tried repairing 1B, which works fine on the C5. Repair failed. Did the extended shutdown after the repair, no difference.
sys:12024-04-09 11:53:04.364infoFinished Z-Wave Network Repair
sys:12024-04-09 11:51:58.347warnZ-Wave Node 05: Repair timed out updating neighbors
sys:12024-04-09 11:49:28.354warnZ-Wave Network responded with Busy message.
sys:12024-04-09 11:49:28.327traceZ-Wave Node 05: Repair is running
sys:12024-04-09 11:49:26.254traceZ-Wave Node 05: Repair is pinging the node
sys:12024-04-09 11:49:26.253traceZ-Wave Node 05: Repair starting
I don't see a list of which neighbors, but some are probably dead-batteries.
@bobbyD Any updates or next steps? I don't have any idea how to do "Network Maintenance" that I haven't already done.
To see a list of the neighbors, you can use the community app Hubitat Z-Wave Mesh Details. It's available in HPM.
You can expand details on a device to see neighbor info:
Running repair on an unhealthy mesh only makes things worse. If you have devices that are unplugged, make sure all the nodes are active. Greater attention will need to be made for potential misbehaving devices, before attempting to run another repair.
I don't see any signs of mesh not being healthy on the Z-Wave status. Do you?
Seriously, if this is just a case of you saying, every few hours, "Yeah, it's not right. You need to do something I won't tell you how to do", please just process a full refund.
Right, that means the issue is with one or more devices. I see that all devices apprear to have been migrated as non-secure. There may be a problem with migrating secure devices from C5 to C8/C8 Pro. Will follow up on your private message.
What device make/model is this? Pretty sure you have a device or two that may have outdated firmware that cause problems in the C8.
If you are getting this Busy message on the first repair attempt after a shut down that is for sure strange. Usually the Busy error only comes up if you have been hammering on refresh/repair or there is a device just absolutely blasting the mesh with garbage. The Busy error is probably what is causing the repair failure. Basically the z-wave chip in the hub is saying its busy and doesn't have time to do what you asked it to do.
Personally... I would use that mesh tool linked above and look for any devices with a high number of messages (the count in the RTT column). Keep in mind those stats reset when you reboot.
Oh yeah that is a good one I did not think of that. That would cause the outbound messages to not be secured and the device would then reject them.
If you have a device that was possibly S0 security on the C5, if you go to the device page and down to the "Data" at the bottom, you can check for "secureInClusters" and also the "S2" data. I think S2: 128 would be S0 security pairing.
Pretty new Zooz 800 S2. Purchased less than six months ago.
Check the Data on that one as I suggested above to see if it was paired with security by chance.
Will check, but remember - on startup the logs show
dev:1632024-04-09 08:40:55.660errorjava.lang.NullPointerException: Cannot execute null+1 on line 146 (method initialize)
dev:1932024-04-09 08:40:52.628errorjava.lang.NullPointerException: Cannot execute null+1 on line 146 (method initialize)
dev:1932024-04-09 08:40:49.062debuginitialize...
dev:1632024-04-09 08:40:49.060debuginitialize...
It could be the start-up problem is causing the other issues?
@bobbyD Were you able to see anything on the null pointer?
Yup, and I asked you which device / driver is getting that error but have not heard back on that question. Would need to know that to understand what it might be causing.
If it's telling me which device gets that error, I don't know how to see it. It's at very start of bootup.
Device 1B Data, as requested:
This is a Zooz 800 S2. How do I determine if it has security set?
It’s not paired with security.
In the logs screen you can click the red “error” box and it will open the device page for the device the log is from. I also explained another way how to find it up above, using the device number.
Okaaaay...
The initialization errors (java.lang.NullPointerException: Cannot execute null+1 on line 146 (method initialize)) are for my home theatre receiver. I didn't even recall that it was listed as a device.
From a full shutdown, wait 5 minutes, restart to Z-Wave repair I again get messages such as:
Stage: Repair Running - Group: 1
Z-Wave Node 02: Repair failed node neighbor discovery (report failed)
Z-Wave Node 04: Repair failed node unreachable
The two nodes that failed are plug-in modules. No other errors, no red in the logs other than the A/V receiver. But Z-Wave still not working.
Should I delete those devices (the A/V receiver and those plug-in modules), or is the probably likely unrelated?
Update: I have deleted the Marantz devices. I no longer get those java null pointer errors on start-up. Z-Wave still doesn't work. I'm not able to determine which "neighbors" Node 02 is not able to update, resulting in the "Z-Wave Node 02: Repair timed out updating neighbors" error.
That error does not mean the device could not reach the neighbors, it means the request to the device you are trying to repair timed out (i.e. it did not respond). If a device could not reach some of its neighbors it would not cause the repair to fail, in fact that is the entire purpose of a repair is to rebuild the neighbors. It is also a good test to see if a device is online and reachable (when using sparingly). Obviously that test is failing even though we know the device is online and functions, the hub just cannot talk to them for some reason.
The only other thing I can think to try, is if you have any devices that are NOT tied to a bunch of rules, you could try removing/excluding one and then pairing it again. Its not a solution but would give more info to determine what is going on. However, if the exclusion or inclusion also does not work, it could make a mess of things.
Which, making a mess would not a be huge deal but somehow Zigbee got botched up on the C5 so you have not way to restore zigbee from a backup anymore from what you have said.
BTW re-pairing zigbee is far less painful than Z-wave unless you have a large quantity of zigbee devices.
Short of some other wisdom from staff I do not have much else for ideas.
Download the Hubitat app
