Problems after C5 to C8 migration

I purchased a C8 when they were first released and have sat on it until it appeared all the migration problems were resolved. I finally had enough time and nerve to perform the migration yesterday, and I'm really regretting it at this point.

I have a decent size ZWave network (about 100 devices), plus a small zigbee network (maybe 20 devices). After the upgrade, I now have random devices that just don't work, and tons of rules (rule machine, button controller, switch bindings) that all seem to be useless. The rules appear to trigger in the logs, but none of the commands translate out to the physical devices. This is a big problem for me because there are multiple rooms in my house where the switches are loadless and depend on the rules to actually turn on the lights.

After lots of troubleshooting, I fully shutdown and power cycled the hub last night, and after that seems things to behave normally, so I chalked it up to an upgrade step I just needed to take ... but when I got up this morning, everything was broken again.

The last thing I want to do is rebuild my environment from scratch because of the extensive amount of time it's going o take, but I couldn't find any obvious steps on the forum regarding similar issues. Any suggestions when be greatly appreciated.

Also, since the C8 adopted the hub ID for the zwave, I figure I can probably switch back to the C5 on that side ... but is the same true for the zigbee? or will reverting back to the C5 blow the whole network up now?

You may want to give the hub and devices a day or so to settle in with the new hub. What does the Zwave table look like. Are there any ghosts?

1 Like

I considered that, but the behavior doesn't seem to fit that logic. For example, I have two zwave modules that control the lights above/below my kitchen cabinets. After the reboot, they both worked again (as expected), but this morning, the module for the underside can't even be commanded directly from the dashboard or even the device page anymore. They are identical modules, and about 6 inches apart. Some problematic things do eventually respond, but only after very lengthy delays (several minutes)

I could see the mesh needing hours to recalculate (it's been over twelve since the reboot), but not days.

Can you post screenshots of your z-wave settings page?

I ask because the C-5 does not display z-wave ghosts, and the situation you describe resembles others in which a z-wave mesh containing ghosts was migrated from one controller to another.

Edit: This is a resolvable situation.

2 Likes

You didn't mention it, but powering OFF the C5 is necessary. Don't touch it in any way, it can be used to revert if needed. You simply don't want duplicate controllers alive at once. Shutdown doesn't do it. Do a Shutdown, then power off the C-5.

1 Like

As I mentioned, thats a long page. If I'm correct that a ghost shows up with a status of "PENDING", I have none. Every device on the list is a status of "OK" ... but correct me if that assumption is the wrong way to tell ...

No .. I'm very clear that the two cannot co-exist in a powered on state (ever) because the C8 is now using the C5's ID.

You say you have over 100 zwave devices. Are they all Zwave Plus? or are some zwave 300 and older?

1 Like

"ever" is a bit strong, but I suspect you do understand :slight_smile:

Eventually, the C-8 will be working and you'll be interested in "factory resetting" the C-5.

when it's time

Turn it on, go into ZWave Details and reset the radio. Same for Zigbee but also set a different channel, just to add some safety. At that point you can leave it on for as long as you want :smiley:

Almost 100 ... probably around 90, but yes, they are all zwave plus. I retired all the old zwave devices sometime ago. If there is an obvious way to tell from the list, I will double check. I remember being able to tell in the hex information exposed on the C5, but the C8 doesn't present that anymore, so I'm not sure how.

Nope .. "ever". From what I understand, you can't factory reset the origin of the database and run it anywhere near where the migrated database continues to exist. The origin device will always reclaim it's own ID when it powers up even if the database is flushed. Hubitat's migration is more of a trick than an actual migration ... the new device just pretends to be the old device in perpetuity so you can't have them both running.

I understand the hesitancy, but you can have them both on for a "short period of time". Imagine that you do so at a time when ZWave traffic is low and that any confusion caused by duplicate Home IDs affects the fewest devices. If the overlap is 5 mins or less, the time it takes to power on, thus starting the duplication, to the moment you type reset and hit Reset button... which is when the duplication ends, then the "real" hub and its devices will begin to recover. Yes it might take a short while to recover, but recover it will.

There's a LOT of us that did this exact process to be able to reuse a C-5 / C-7 for some other task, or even resale. I know I can raise my hand to that.

2 Likes

ok .. yes a short time would have minimal risk. I apologize, I thought you meant that it could be brought back up and used as a secondary hub for hub-mesh type things or network seperation. (i.e. first floor/second floor devices.)

1 Like

As I understand it Zwave specifically uses a software defined network ID. When you reset the Zwave network, it clears the database and regenerates the network id. For that reason, your old devices won't recognize the hub after you do a reset of the zwave radio.

After you reset the Zwave radio you could add it back with hub mesh. You would just have to be aware that the Zwave networks would be independent of each other.

2 Likes

I appreciate the insight here, as I thought it used the hardware ID ... regardless though, this conversation has diverged from the actual issue I care about :slight_smile:

2 Likes

I don't want to take this too far off track of resolving your Migration problems but because I have 6 Hubitat Hubs powered on 24x7x365, with 4 of them interconnected via HubConnect, another 2 interconnected with an independent HubConnect. Then HubMesh, to interconnect the two sets, I'm worried you think HubMesh somehow makes use of the Z-Radios... it does not. HubMesh is a LAN network interconnect. When you have finished your migration to the C-8 and want to reuse your C-5, maybe for Internet facing services: Alexa, Google Home, weather, etc. you would use HubMesh to 'mirror' those devices onto your C-8.

No, I'm fully aware that hub-mesh does not use the zwave or zigbee radios to communicate between the hubs. I only referenced hub mesh as the implementation could involve zwave/zigbee devices being used on both hubs requiring the radios to be turned on.

That is incorrect. Ghosts will not have a Hubitat-device associated with the zwave node, and have a state of β€œDiscover”

Some other ghost examples below...

One thing to be aware of is frequently after a migration you will not show any routes (final column on the Z-Wave Details page) for up to several days as they fill in again (migration clears out the routing cache). So every mains powered device that doesn't have routing after a migration is not necessarily a ghost.

1 Like

I also have nothing with FAILED or DISCOVER states. Some of the devices don't show a routing map, but there is no correlation between devices that are missing routes and devices that are misbehaving.