I just bought the c8 - and was literally just about to jump on the migration train when I started thinking, my current c5 build is stable, but if I want to ensure I am building a better system - would using that device as a roadmap for a proper rebuild be a better way to go?
Now, in searching the forums, I read seemingly broad-based issues and a common thread with c8 appears to be migration. But in dealing with digitally intercommunicating networks of devices enforcing encryption but each with disparate firmware - wouldn't they operate better when we're not ripping out central command and attempting to put in a new one, but restarting each node and rebuilding the network piece by piece?
Anyone else rebuild instead of migrating to C8? Thoughts on if it is worth it one way or the other? I haven't ever done a full rebuild before, but my main issue when rebuilding nodes on the c5 was always the weaker radio. So it should be easier with a C8 - particularly leveraging rule import tools, HPM, and a good blueprint.
When you memorialize radio engineers today that died in military service, building radio communications and troubleshooting under significantly more duress than what I am contemplating. . .
Following... I have a C-5, and am considering purchasing a C-8. I'd give my hub's stability a B+. Have lots of weird quirky things that drive me nuts, knowing that I had no idea about best practices when I set everything up 3 years ago. Since the C-5 has no Z-wave diagnostic tools built in, I'm left to suffer or pay for PC-based stuff. Or upgrade to a C-8 and get long-range antennas and the latest chipset.
What I've spent the last 30 minutes trying to search for with no successful conclusion is does a C-5 to C-8 cloud migration bring along all my existing Z-wave network quirks? I've read there are more actions you can take with a C-8 to eliminate problems, but not sure if I'd save time long term vs just starting over.
Good callout, it seems like all of my heavily-configured apps have an export-import functionality... has anyone successfully started from scratch with a new hub and successfully did an export/import of all your configured apps (including dashboards, rule machine, button controllers, etc)?
Yes. Well they will re route stuff but the big thing is you likely have ghosts in your c5 which is what's causing you issues. Those will transfer. They may or may not be easily removed. If not you will need a z-wave stick to remove them. If you have access to a z-wave stick you could clear them out on your c5 before migration. Otherwise start fresh. And yes you can export your rules and re import them to the new hub
I took the manual migration path twice.. I have 4 Hubitat Hubs interconnected, each managing a specific physical area of my home. Two of them were C-5's and I determined that I would not do an automated migration. Instead, I took a normal backup of a C-5 to my PC and then shut off the C-5.
I then unboxed the C-8, wired it and powered it up. Then I registered it and went right to Settings: Backup & Restore and restored the backup I had just made. This moved everything over (Apps, drivers, configs of LAN devices, and so on) except the Z-Radio config.
I started with Zigbee because they just drop into place. Start the Hub and the device into Include and bippity-bop it's done. Repeat til done.
The next part is the big variable... I determined how many ZWave devices I had. I know that the first device I Join will use Node 6. I had <26 devices so I went into the Device Info page for all devices that had a DNI less than 32 and altered DNI to have a Z in front. The whole purpose is of course to not step on the old DNI with new devices. Two devices with the same DNI will be a knot that is not easy to untangle. While I'm on the Device Info page, I edit the device label to also be different. I added ' old' to mine. This has to be done for every ZWave device.
Now I went through the ZWave devices and Excluded each, followed by an Include. I do this with everything now.. Exclude first to just get confirmation that the radio is working/reachable. You can't create ghosts with an Exclude. Plus the migration requires an Exclude, so two-birds-one-stone. Then I Include the device, naming it the same and once done, I goto Settings: Swap Apps Device and because I had edited every device label with ' old' it was easy to see which device goes in the left side and which goes into the right. Once the swap is done, I'd remove the ' old' device. Because the DNI was altered on the first few, I had to force delete them, but once I got past node 32 removing the old device was just a few seconds.
It's actually easy, although tedious. 25 of anything repeated gets boring quickly. Then, with all that success under my belt, I went and bought a 2nd C-8 and did the entire thing over again for the other C-5. Faster, because my mind and fingers had the steps down.
Although 20-60 paces on the stairs would really be good for me, with mobile processing I can walk device to device and push a few buttons here and there. . .
Restore the backup - that's exactly what I was in the middle of starting before posting! Thanks very much @csteele abs textbook - developer by day cowboy by night? brand the old ones with zs and usher in the new herd of cattle! I need to read more about the DNI. . . I jest but it makes sense - the processing units' architecture are the same to simply swap the software build - the main thing is reestablishing the radio network. I am running both hubs concurrently now, but everything is still on the C5. I will be importing software manually however - identifying the best device drivers and apps off the old hub, rebuilding the ip facing & virtual devices first, keeping the hubs running concurrently before I rip and switch.
I had a major failure in recent months with some compounding process(es) on boot sapping all my resources - never pinned down the exact cause of what I did to it, some software, but i had to restore a previous build being afforded only a. . . . brisk period before the hub became inoperably slow, unresponsive, and impossible to load. Real scare. So I feel it is time I should enforce a 2.0 critical design blueprint rebuilding app-by-app and rule-by-rule:
sweep up deprecated alpha projects
eliminate redundancies on custom drivers
rethink complicated rules
a. have I over-engineered it? should it be in groovy and out of rule machine?
b. clarify variable language
c. have I factored seasonal influences on the automations correctly?
Once I've done clean up & maintenance on software, go dark on c5; plug in the zigbee devices and the Zwave to the c8. I was thinking I should line up the mains powered zwavers first and then batteries, but also I have various 500 chipsets and 700 chipset, and 2 old unsecured devices and was suspect I should do the 700s mains devices first, then 500s finally the 2 unsecured devices so communication travels upstream chipsets to the hub. No idea if there are any legs to these networking conjecture or just superstition. By now I spend enough time writing about this I must find some Chateauneuf du Pape
Two comments to keep within arms reach as you do the migration...
migrate mains powered from the hub outwards, then battery. You can do this in a wedge shape or rings but building a mesh is paramount.
you are ruining one mesh while you are building another. At some point the old mesh just can't function and it will be quick because the new hub and old are likely to be pretty close and thus the first thing you migrate is the very device everything further is relying on. It's unlikely but possible that the first device you migrate is the only device holding up the old mesh.
Major failure I write about here may have been from using now deprecated Zooz 4 in 1 system driver - causing similar issues as in this thread:
I use those motion events to trigger a set of complicated rules, I likely wrote some rule updates and those may have pushed it over the edge. . . I only discovered I was still using the deprecated drivers on those devices today! Better design - nesting within required expressions to avoid triggering rules' conditional evaluations with a lot of motion events
It wouldn't be wrong, but the whole point of taking a backup and then powering down is to make the step-back-and-get-working as quickly as possible.
If things go poorly, then you will spend some frustrating time trying before giving up. You want to just turn off the new, power up the old and be back in biz. No fiddling with DNI editing, just power up, back in biz. That's my thoughts at least.
It took a while to get around do this, I was using the new hub as a development environment. Admittedly, rebuilding from scratch was quite a bit easier than I thought, and only took 1 day for complete set up. But ultimately, it was more for me A LOT of Marie Kondo's work along the way - organizing everything & renaming, reviewing/improving logic - so I am very happy with the results. The entire set up is working better and has been far more reliable with notably faster response time. Had I been totally satisfied with my Hubitat set up and just wanted a carbon copy plugged over I wouldn't have gone this route as @csteele method above would have been 10x easier. I wrote this up nonetheless in case anyone else wants to go down this route:
rebuilding network hardware
initially set up of the blank slate C8 to my network framework
installed my local lan devices to Hubitat
identifying and downloading the drivers & apps I wanted installed.
ushered in my zibee/zwave networks
excluded and included the wired devices with the 800 chips closest to my hub first,
then wired 500 chips etc on the periphery of those,
rounded off with the wireless devices.
Moving over the devices went through brilliantly. Some zwave device specific quirks; but just look up the right manual/instructions on google. Here was my standard operating procedure per device:
Exclude a batch of devices on the old hub, include one by one on the new hub
I think with Zigbee, it is reset and inclusion - repeat the same step on the device twice for inclusion worked every time.
select the right driver for the device
immediately after inclusion push Configure after the correct driver selection
execute a device event, ensure the flashing lights stop, device goes to sleep, check the Hubitat device driver relay works too
move on to the next device
As csteele pointed out above, exclude all the peripheral devices first as they are losing their mesh along the way, making exclusion tougher. I only had one device fall off following those steps and it was zigbee
restored my old hub (so I had it's original configuration as a reference/checklist)
exporting & importing rules with rule machine; two browser windows
Select replace devices during rule import
hub variables are 'hard coded' in the rule - make sure to identify and correct named variables
Execute/review logic, validate the values shown, do conditional executions operate as expected?
Ensure other apps are correctly set up and connected to the right devices
Once I had my hub operating locally I worked its automations into the cloud.
Validate both hubs' cloud apps' configurations side by side with two browser windows
IFTTT integration; reconnect the Hubitat Settings in IFTTT - My Services to select the new hub
Google Home devices for direct voice control; add new device, works with Google, reconnect the account to bring them all in
also review the Google Home automations logic to ensure they're still as intended
Only other thing is monitoring the oldest "Last Activity" devices after a few days and checking in that they are still working.