How easy is it to migrate from a C-5 to a C-7? I'm having a lot of problems with my C-5 and thinking about an upgrade. But I have a LOT of devices paired with it and a LOT of automations and I don't want to manually do each one over again.
Could I just backup my C-5, get a C-7, and "restore" the C5 backup file to the C7 and having everything?
hub protect will allow you to migrate from C-5 to C-7. the only things i think are zigbee devices that need to be manually re-paired
I would recommend making every effort to solve these problems first.
Problem is, I've gone through tech support and this is what they finally offered me - a replacement. And at extra cost.
I don't know why, but my HE periodically gets unresponsive, requiring me to power it down and power it up again.
@aaiyar is right, if you can solve the problems first it would certainly help.
There are a few utilities / drivers around that may help. Are you getting any warnings / alerts through the Hub Admin Web UI for things like load on the hub or database size? Things like the Hub Information driver may help by logging a trend of things like db size or load over time, particularly if you have a way of logging the results and charting them over time. Hubigraphs is a good local tool for this or a more involved setup could include an external db and Grafana, but probably not worth setting that up afresh for this purpose alone.
I probably can't comment on your exact question, I bought a C-7 last year as an addition to my C-4, plus went through the exercise of moving my lighting from my Hue bridge onto the new C-7, so not quite a migration as such.
To add to my last comments, one reason it would be best to resolve your issue or at least understand it, is that if it is something to do the way you have configured your devices and/or rules, or the apps you have chosen to use, then migration may or may not solve this for you. I believe the C-7 has more "grunt" in some respects (perhaps the Java is 64-bit???), but it doesn't cure all issues I would expect.
Also, as much as a quick "big-bang" migration may be somewhat easier, taking the time to transition things over time manually, can provide you with an opportunity to re-assess your setup and iron out any kinks or do away with any unnecessary elements. For a period you could run both hubs like I do, splitting them into a lighting hub and apps / LAN-based devices.
Just a few thoughts and options....
Only an updated zwave radio and stack. Rest of the hardware is the same as the C5. And it also has a 32-bit JVM.
Once I got a warning that there was CPU overload, and that I had to look at my drivers and apps very carefully. However, the hub was so unresponsive that I couldn't do anything until I unplugged and replugged it.
Most other times, it just becomes unresponsive with no warning.
I'm honestly not sure what the problem is. I've had a variety of other problems that I've mostly ironed out - updating the Firmware on my Leviton devices mostly fixed the unresponsive dashboard button problem, eliminating ghost nodes appears to have improved performance somewhat, and getting extenders (which I'm still experimenting with) seems to have improved some device response times.
But I still run into slow network performance at times and unresponsive Hubitat at other times, and I just don't know what else to do is besides rebooting/restarting it.
You mentioned utilities that could help. Do you have any specific suggestions with links?
There's probably been threads elsewhere where people have discussed this in more detail, I'll see what I can find on that front. A list for my own benefit of things I will try and find are:
In terms of some of the drivers I was suggesting, the main one at this stage is probably the Hub Information Driver. It can poll for various status information on your hub, including load, memory usage, database size, etc
Once you move on to things like devices misbehaving or apps as well I think, you can start to look at things like the Device Watchdog app by Bryan, but I don't think that will be of use for you just yet.
Let me follow up on the list I made above.
Thanks! For my edification, what is JVM?
Java Virtual Machine. Can explain in more detail if that doesn't make sense...
Doesn't make sense... but I'm eager to learn!
Hmmm not sure how far to go with an explanation, I'll probably have most of this right but a few details wrong... It's be a while since I studied this at Uni... And not 100% sure on the details for the HE hub, but hey, I'll have a crack and let others correct my description.
Java is a programming language that can be used to develop applications able to be installed on a number of different platforms, e.g. Windows, Linux, etc. I think I also remember being taught it was also originally designed for developing software to be loaded on electrical appliances such as washing machines, VCR's, etc. Coming back to a more PC-based example, one issue is that many applications want to interact with operating system specific commands or features, e.g. storage of files, display of graphics on screen, access to the Internet. These can be implemented in different ways on each system and make use of different libraries developed specifically for each platform. In many languages historically this mean developing code multiple times for different platforms. The idea behind the JVM is that you / I as the developer write our code once using the Java language, deploy the same code to different platforms (Windows, Linux, etc) then the JVM installed on those systems translates the same code into the appropriate commands for the system it is running on. The JVM is the bit of software that is different on each platform, but as the developer I don't have to care, I make the same calls in my code and the JVM does the work for me.
This means that as well as your piece of Java software consuming resources such as memory and CPU on a machine, the JVM also consumes memory and CPU.
I believe the Hubitat system (the software on your hub), or at least part of it, is running inside a JVM on the physical hub. That's why you can have the concept of restarting the system vs restarting the hub entirely (I think). It's also why you have the concept of total memory being consumed as well as how much of the memory allocated to the JVM process is being consumed.
A bit of a side-track to your migration question, but hey... it's all interesting stuff... I hope 
I did get it slightly wrong with the device / app stats, they are now in a separate section to the logs, under Runtime Stats. I have tried finding a good explanation of how best to use this, but can't quite find one at the moment. I guess you are basically looking at what is consuming the most time on the CPU, and see if you disable or adjust the settings of that device or app if you can reduce it's impact on the resource usage on the hub.
Some notes around accessing and reading the Zigbee routing table can be found here:
Might leave you with those, don't want to keep spamming this thread. The database size can be found using the Hub Info driver.
To further expound on @sburke781 ’s explanation, the JVM is where all of your apps and drivers are run.
Unfortunately for memory constrained systems like the HE this can be a drawback. My understanding is while 64bit is "faster" and can address a larger memory space it also takes up more RAM and storage. Interestingly the C-4 is running 64bit while like @aaiyar says the C-5 & C-7 are 32bit. You can definitely see a more pronounced memory usage increase over time with the C-4 vs the others.
Originally I thought 64bit would always be the "best" solution but in this case maybe not.
Yeah, I'm certainly not the one to comment with any authority on this... I think in terms of a hub migration it probably isn't the most critical element in deciding to make the jump. Unless I'm mistaken...
Personally I still think sorting out any inefficiencies with devices and/or apps may be the more appropriate thing to focus on...
Mesh, Hardware, Apps/Drivers the trifecta of doom...
Download the Hubitat app
