Just wanted to say how I fixed my C-8 finally. I have had my C-8 for 1.5 years.
It always locks up and the only fix is to reboot it. Sometimes it would go for days or just hours before locking up and stop responding.
I have tried every update and fix I could find. Resetting everything and reloading only some of the processes. Nothing would fix it. I tried starting from scratch several times and having nothing but the zwave only. It would still lock up. The C-8 is buggy and no firmware updates have fixed it.
Then I found Rebooter code so I can set it to reboot every day at 2am. Now it never locks up and works flawlessly.
I imagine every other C-8 owner has this same problem. Use this app to fix it.
I just wanted to share so others can fix theirs.
I have mostly Zwave (lights, fan, switches, door lock), 1 hue, tailwind q3 for the garage door, 2 ecobee thermostats, and a timer rule to turn on outside lights.
Hubitat should really add an auto repeatable reboot function to the native settings to fix these issues so you dont need a separate app. It is the only way to prevent it from locking up.
These symptoms are not normal. There is probably something wrong in your configuration. I haven't had to reboot any of my hubs for quite some time, other than updates. I'd start looking at logs, seeing if I had any Zwave ghosts, using older Zigbee devices that do not play well with the newer Zigbee chip in the C8.
I've a C8-Pro, C8, and C7... None of them need any scheduled rebooting.
This is the first time you've ever posted here so it looks like you've never asked for any help. Rebooting daily only papers over your underlying issues with your hub's setup. If you want your hub to run normally, I'm sure folks here would be able to help you if you provide some information.
Hubitat Elevation hubs (like the C5, C7, or C8) sometimes require daily or scheduled reboots to maintain stability, especially in more complex setups. This isn’t officially required by Hubitat, but many advanced users schedule reboots because of a few well-documented reasons:
⸻
Common Reasons for Hubitat Lockups or Slowdowns:
Memory Leaks
• Hubitat runs on Java, and community or custom apps/drivers can sometimes cause memory leaks.
• Over time, especially with power-user setups, the hub may exhaust its memory, slowing down or becoming unresponsive.
Poorly Written Apps or Drivers
• Custom code (especially from community repositories) can loop, log excessively, or not clean up properly.
• Apps like certain versions of webCoRE, or devices that poll too often, are frequent culprits.
Too Much Logging
• If many apps/devices have debug logging enabled, this can fill memory and degrade performance over hours/days.
Zigbee or Z-Wave Network Congestion
• High-volume Zigbee/Z-Wave traffic can jam up the radios or overwhelm the hub.
• Devices that go offline or chatty sensors (like power monitors) can flood the hub with traffic.
LAN-Based Device Spam
• Devices that communicate over LAN (e.g., Tasmota, LIFX, Shelly) can flood the hub if not throttled or managed properly.
Cloud or Internet-Dependent Apps
• Cloud integrations (e.g., Google Home, Alexa, weather, Life360) that timeout or fail repeatedly can bog down processing.
⸻
Why Scheduled Reboots Help
A scheduled reboot (e.g., once every 24–72 hours):
• Frees up memory.
• Stops any runaway processes.
• Gives radios and the hub OS a clean state.
• Prevents cumulative performance degradation.
I too have a C-8 after a C-7. I have to reboot once every 6 months or so. I have about 40 Z-Wave devices and 2 Hue bulbs and 2 Hue motion sensors. The one problem I see with suggesting everyone reboot every night at say 2:00 a.m. is that you might want to use a device that depends on the hub during that reboot time. Sure, it would be very rare, but that’s just rolling the dice. I’d rather reboot it myself when I can control it. But, as mentioned, I only need to do it once every 6 months or so. If you are finding doing it every night is needed then more power to you.
I asked ChatGPT the same question, and here is its response.:
⸻
Why Hubitat Lockups or Slowdowns Are Rare — And Why Scheduled Reboots Are Often Unnecessary
Efficient Memory Management
• Hubitat’s Java-based platform includes garbage collection and memory optimization mechanisms that handle memory automatically.
• Modern firmware is well-optimized, even for complex setups, and rarely runs into memory exhaustion unless there’s a serious bug.
Most Community Apps and Drivers Are Well-Written
• The majority of popular community code is reviewed, stable, and widely tested.
• Issues like infinite loops or excessive polling are uncommon, and developers often fix bugs quickly when reported.
Logging Has Minimal Impact
• Logging, even at debug level, is temporary and stored in memory-efficient buffers.
• Unless actively watching logs from dozens of devices for days, debug output is unlikely to degrade performance noticeably.
Zigbee and Z-Wave Networks Are Robust
• Hubitat handles Zigbee and Z-Wave traffic efficiently, and the radios are designed for high concurrency.
• Even with many devices, modern hubs manage network traffic without slowdowns if the mesh is healthy.
LAN Devices Are Not a Problem When Properly Integrated
• LAN devices using native or well-written drivers do not overwhelm the hub.
• Protocols like MQTT and integrations like ESPHome are optimized to work efficiently with Hubitat’s event model.
Cloud Apps Are Handled Gracefully
• Cloud integrations like Alexa or weather services are sandboxed and retried with proper error handling.
• Temporary network issues don’t typically affect overall hub responsiveness.
⸻
Why Scheduled Reboots Aren’t Necessary
• Hubitat is designed for 24/7 uptime and does not require regular reboots like some consumer routers.
• A well-configured hub can run for weeks or months without degradation.
• Frequent reboots may mask underlying issues instead of fixing them.
• Most performance concerns can be resolved by identifying and addressing misbehaving code or devices, not by rebooting.
⸻
I Don’t believe everything ChatGPT says; the answer depends on how you ask the question...
My C8 does not need reboots, I only reboot when I do updates, and I do not jump on every update. I can easily go months without rebooting if I'm not updating.
That is with a lot of busy apps running constantly, and well over 100 devices with Zwave, Zigbee and Wifi.
It is not a Hubitat issue, it is something with your specific configuration, or even a bad device. If Hubitat added a native rebooter, more people would use it as a band-aid for underlying issues, so I don't see why they should encourage that by offering it as a feature.
I agree. I was using a reboot routine when my Zwave would constantly crash, as that was the only way to get Zwave back up. Rebooting could avoid the crash. Then I found the bad devices causing my issues.
There are lots of great threads on here with suggestions for finding trouble devices in the mesh. Someone should combine them into a single troubleshooting guide.
I asked ChatGPT for a version that argues the opposite viewpoint… This is simply to demonstrate that we cannot fully trust ChatGPT.
I am using a variation of the rebooter that activates when free memory drops below 90 MB. Hubitat has significantly reduced memory leaks compared to a few years ago, but some still exist. Every complex system has a certain degree of memory leaks; the key question is whether they impact your system. To be safe, I have decided to keep my auto-reboot rules enabled.
I have owned the C-7, C-8 and now C8 Pro hubs. With rare exception, the only time I reboot my hub is when installing a firmware update, which I generally do shortly after release.
I have over 200 devices including virtual devices. I have dozens of apps running. Even when running the C8 hub, I had no issues. I updated to the C8 Pro because the UI was faster. I do not use webCoRE, so I do not know how that might affect things.
Check your device and apps logs to see which might be consuming excessive memory or CPU power. In my setup, my Hue bridge takes a lot of CPU busy time, but my overall busy time is quite low.
If you have any offending devices, sometimes finding a community driver can help. Also see if a device is reporting more frequently than necessary. The Third Reality smart switch with power reporting flooded the hub with power readings until a community driver eliminated the issue. Also see if any specific apps are using too much memory or CPU time. There might be an error that is causing a processing loop.
I think it is important to remember that all of our environments are different. What works for one person may not work for someone else. Our personal experiences may not match others based on how they think things should work.
The discussion about memory and memory leaks is a really tough one to lock down. First the whole concept of rebooting for low memory is flawed. Memory is there to be used and it is good to do so. It should go down until a equilibrium is found where memory recovery and memory usage balance out. You shouldn't think of memory like we do in windows where it is good to have allot free. In Linux/Java the goal is to comsume it and then only clear items out as they are not used and space is needed. The problem comes when a task neeeds more memory at a given moment then it can allocate from what is left. In practice the only times i have seen a Java OOM error is when a bad test has started on a hub in the beta program and it killed the memory almost instantly. You will also hear wildly different anecdotal beliefs on where that balancing act should be some will say down to 90MB is fine while others will say 180MB. Neither of them are wrong it is just what those users have found that work well for them. Ontop of that as clearly desmostrated by users above many don't reboot at all.
That said i did create a rule as my environment got more complex and had more devices in it. That rule monitored Memory consumption and when it droped to a certain point it would reboot the hub gracefully. That rule hardly ever actually ended up getting triggered. More frequently then not the next upgrade or some other need would trigger the hub to reboot before it would ever trigger. Ultimately that rule ended up being mostly just as a backup.
I also think it is very important to have reasonalbe expectations when it comes to these hubs. Up until the C8Pro the hubs had what appeared to be 1GB of ram of which a large chunck was used by the OS. I think generally we only see at most beteween 500-600mb for our usage. Then the hub also had a fairly small ARM Cortex A53 CPU i believe. That CPU is very limited in it's overall capabilities. My point is that the hubs are very lower power and it doesn't take much to overwelm them. It is amazing what we can do with these little low power devices. It is also very easy for use as consumers of those device resources to forget that and throw tasks at them that are ineffeicient and create problems. The best example of this is when i see rules that run on a interval basis that is extreamly short. It doesn't take many of those to overwelm a system. The worst thing is when something like that happens and a race condition is created. That can very easily lock a hub. We should run things based on time or on repetitive intervals as little as possible, and depend on device events to trigger things as much as possible. It is unavoidable in some cases, but still should be avoid if at all possible.
The first thing i would ask the OP is when was the last time he rebooted with the option to rebuild the DB after restart. If he is having to pull the power because of hub locks ups there is a good change of corruption in his DB. That will continue to cauase lock ups if not addressed. If that is being done on a regular basis does he log his hub memory from the HubInfo driver to a database of some kind to review it's performance. Do we actually see he has low memory when this occurs or doe we see something else. In that same logging he should be logging CPU. If it isn't memory we may see a huge spike in CPU load that could be indicative of something creating race condition.
I log all of my hubs to a InfluxDB database and have dashboards so i can see the CPU/Memory/ect of the hub. Generally speaking on the rare occasions it does hange up for some reason it isn't hard to see why, and then i fix it and it just runs for days/months withouta reoccurance. If you don't get to the root of the problem it will simply continue to happen and likely progressively get worse.
Nothing with my setup is the problem. I troubleshooted for a year. I started over to default settings and only added minimal items with no apps. The C-8 just locks up every few days. Always has. I have imagine that everyone with the C-8 has the exact same experience as me as mine is nothing special and I wiped the config several times and started over.
Rebooting is the only solution. But Hubitat does not have an auto reboot feature. I googled and found the rebooter app someone made and started using that.
It reboots daily when everyone is asleep and no more lockups.
I just wanted to post this so others can find the fix faster. No firmware update in the last 1.5 years has fixed the issue.
Common Reasons for Hubitat Lockups or Slowdowns:
Why Scheduled Reboots Help
This is simply to demonstrate that we cannot fully trust ChatGPT.
