Potentially normal after a migration that included ghosts. "Good" devices may not have any routing (routing cache was cleared by migration). So as noted, missing routing does not necessarily mean a device is a ghost at this point. Routing will fill in (for devices that are OK) over the next day or two normally.
Frustrating, but the best thing you may be able to do at this point is wait for your Z-Wave Details page to populate/update routes to get an idea of what's going on.
I understand it's long but it would still help us to help you if you posted your z-wave details page. Just use windows snip and break it up. We can tell other things from the mesh setup than just ghosts as well.
As of today, the entire zwave mesh is useless, and nothing is controllable ... clearly, waiting is not the answer here. Here are the mesh screenshots ... (and a note for the Hubitat developers should they happen upon this thread - it would be nice to have an "export screenshot" button, or other mechanism to break the zwave details list out of whatever sudo frame they are rendered in within the GUI.)
In general it doesn't look bad. Do me a favor. Shut down from the settings menu. Unplug power to the hub for 2 mins and power back up. Then start trying to control devices directly on the device page.
IF this is after an overnight, I'd disagree. All those missing routes are paired to zero route changes... there should be one, right? If the route table is cleared, then finding a route would be a change?
They should route when activated.
This was process was done a day ago now. After the full shutdown/power down/restart, things did start working and I went to bed thinking everything was better. Over the next 36 hours, the system has descended in to complete uselessness. Given what I’ve done thus far, I expect that a restart will return things to normal again (it has several times) … but I’m not currently able to prove it. I will restart it again once I get home.
perhaps @support_team can look at your engineering logs as well.
How do I pull the logs? I will grab them from the device before I reboot it so that I have them ...
You can't, only support staff has access to the engineering logs.
So, I have a new development to add to the information. I air-gapped a couple switches and restarted them, and all the sudden, everything started working again. The other night, I tried pulling the plug on a couple devices, but that didn't have any effect on them or anything else ... they were repeaters, but maybe nothing was routing through them, thus nothing cared?
So I walked around and air-gap restarted a bunch more (almost all of them) just to create a slew of polling traffic, and after 15 minutes, everything is still working (not to say it won't bog back down and die again in an hour). But, I did not need to reboot the hub, i just created a disruption on the mesh and zwave started flowing again.
Now I have to wonder if there is something different about the zwave radio in the C8 that's instigating a packet storm on the mesh (maybe it simply doesn't like one of my devices) and is just saturating the bandwidth beyond usefulness with retries. This is pure speculation, but the mesh has been solid with the C5 for years ... I only switched to the C8 hoping that the dedicated antennae would improve the response time of some of my devices by reducing the hops required.
Well, that didn't take long ... things are starting to stop responding again. ... Guess I got about 30 minutes to an hour out of it.
Do a "binary search" then... airgap half... leave them disabled, verify things are working. If not, enable them and disable the other half. Keep narrowing down by half each 30-60 minute cycle.
That trick only worked once
So, last night before I called it a day, I needed to do a full shutdown and power cycle with a delay in order to wrestle back some control to turn a bunch of lights off. The recovery again lasted about 30-60 minutes before everything gridlocked again.
On a whim, I disabled the switch bindings instances, and for a moment, I had a bit of control. It was very slow, but commanding a light would control the light several minutes later. This was short lived, and everything went back to useless. I gave up and went to bed (switch bindings remained disabled).
When I got up, it was all still dead ... but at some point today, I walked past a motion sensor, and realized the lights came right on.
For the past few hours, I've periodically checked and things have continued to work. I've also been randomly re-activating switch bindings to see if one of those is the culprit, or if it was just another coincidence.
To add to things, today I got up, and the mesh is dead.
Everything worked fine for at least 8-10 hours after the last change I made (turning on switch bindings instances … they still aren’t all on, I just started dealing with other things)
Does anyone have some additional troubleshooting suggestions? I think I need deeper logs to see what’s actually happening here - there is more than Hubitat is showing. Could it just have a bad radio, or something?
And back to one of the original questions … is it safe to swap back to the C5?, or does that risk blowing up either of the meshes? (Shutting down the C8)
A rollback to the C-5 does work, assuming that the state it was in on power off still matches your devices. In other words, any device Exclude/include you did on the C-8 is not going to be reflected in the C-5. You would need to recreate those devices on the C-5.
If you imagine using the migration process to get back, that won't work. Neither of the Z-Radios are writable on the C-5. (C-7 has a writable ZWave radio, but not Zigbee.)
No expectation of a reverse migration, just a rollback to the old hub leaving the previous config intact.
I've been conscious not to make changes to the state of connected devices since powering up the C8 just in case I needed to revert; under the assumption it might be possible. I also figured i could restore the the backup more than once if I needed to try that as well.
Download the Hubitat app
