I have no idea why my Hub seems to go through these cycles, but once again I am running into my hub slowing down and the only way to fix it is to reboot the thing.
Is there any way to schedule a reboot on a nightly basis without using another device to kill the power to it?
Don't do a reboot schedule. What custom apps or drivers do you have installed?
I'd try to debug the issue but the information I need isn't in the logging we have access to.
I only have a couple custom apps which I need to integrate my home with HE. They were working fine for quite a few months until this last update. Since I know HE support will ask me to remove these custom apps to see if the problem still exists, my only option is to schedule a reboot.
Are they your apps (you wrote or are maintaining) ? Did they get updated to match the current OS (v2.0.5.114) ? Obviously if they are ported ST apps, they could have cloud dependencies that manifest as... memory leak? Infinite loop?
What's the cycle time on your slow downs? I know you say you want to nightly reboot, but is that how often it slows?
One is ( homecloudhub ) it was ported from smartThings over to HE and integrates with AT&T Digital Life
The other is Echo Speaks
I can't speak for Echo Speaks, but I didn't see any updates that were needed for Homecloudhub
I don't have an exact time, because I hadn't started tracking it yet, but if I had to guess it's 2 weeks. I am usually patient and wait to see if it recovers on it's own so a couple days can pass before I get tired of waiting.
Is there any custom drivers? My issue seems to have been due to the driver not have the capability of turning off logs and there were a lot of them per device. So by the time I had about 15 of these devices it was bogging down the hub. I made some changes to it and sorted the logs and it's been humming along for a few weeks now 
There was a time when I didn't update to every new Release the day it came out. But I now have three hubs and if One hub would benefit, I try to keep them all the same.. which means I'm booting to new OS's pretty often these days.
I just looked at one of my Hub's System Events and 3-4 versions ago I upgraded from 2.0.4.118 to 2.0.5.112 with 16 days between. Then every day to v2.0.5.116 on Feb 9. That's my current version.
I have had no slow downs on any of the three hubs in that period.
They both have custom drivers, but Homecloudhub isn't very chatty.
I have noticed that echo speaks has quite a few log entries but it's at the app not the device.
I'll link my topic over there to see if anyone else is having issues.
I really wish we had access to system level commands like top so we could see what resource was suffering on the hub, 
just make sure its nothing is chatty at all that what I find (I may be wrong). There should be no debug messages under normal use and only descriptive messages if turned on.
Top wouldn't show you anything useful. The only way to track down issues like this is with log.debug and careful examination of the logs you have access to. Also, you can selectively disable apps and drivers. This is the way to isolate the source of the problem. Once you've found which app or driver is causing the issue, then you can use log.debug to isolate within the app or driver.
I was also thinking about buying a second hub and just using the second hub for custom apps. If my theory is correct, the hub without the custom apps won't show any issues if the Hub 2 has the apps that are causing the problem. Is that correct?
It should be obvious that the way to start is to disable the apps and drivers that you would move to a second hub, and see if that resolves your problem. If it does, then you should drill into why they are messing up. Click on the shaded X on the Apps or Devices page to reveal the disable column.
A very small number of us have taken this path. I have 3 hubs. One is for my downstairs ZWave. The second is for Upstairs ZWave (and my giant collection of 5 Zigbee 
)
A third hub was purchased for the reason you mention... I don't want any of my Hubs-with-Radios to be slowed by an app. Only Hubitat apps run on my Hubs-with-Radios. Amazon, Chromecast, Homebridge, Dashboard and Thermostat Scheduler all run on my third hub: "coordinator."
On a Hubs-with-Radios I will run RM, Lutron, Lock Code, Link to Hub, and Advanced Button Controller.
This has an odd result.. no slowdowns anywhere. You'd expect that 'coordinator' would run slow from at least one of those apps. Not so far.
Caveat: Link to Hub is great BUT it does NOT forward all commands and attributes. My Garage Door Opener (GDO) is a good (bad?) example: On 'coordinator' only Contact is available. I cannot open or close the GDO from 'coordinator' without a workaround (virtual devices).
I'll give it a try the next time I see the issue.
Top is going to tell you the Java VM is running. Running a lot.
Hope that helps <-- (being facetious)
I made an assumption that each app may have spawned it's own process. Obviously not having access to the OS directly I have no way to tell how the Hub OS actually works. I had heard it was a flavor of Linux, but that is all I knew.
A flavor of Linux is what the JVM is running on. The "personality" we call "the Hub" is Java code, which includes a sandboxed Groovy.
The underlying Linux tools are going to disclose that.
Your "style" of debugging (and maybe mine) is a familiar one, but I think we are hoping to fit our round pegs in the square hole. Staff has explained how they debug.. zillions of log.debug statements, because it's the fastest "style" for this environment. You and I have to learn this style. 
I did as suggested and it did not resolve my problem. Eventually things got a little more snappier but my devices are still not responding. I even have virtual devices that don't show state changes.
After disabling all of the apps it took 5 minutes or so for the hub to respond better, but the devices were still not responding. I rebooted and then all of my devices started updating.
The only thing that seemed to respond during this time was my hue devices.
Then perhaps there's an issue with a device that is messing up the mesh. I don't know enough to know why a reboot would correct the issue, but eliminating the custom apps and proving the IP connected devices still function properly, then it would seems to point to only the wireless mesh being left to examine for issues.
Failing any positive results from that testing, then you have nothing left but the platform to examine.
I have been looking at the other thread, but will post here going forward to avoid redundancy.
If there was an app with a runaway process loading the hub, chances are it would have needed a reboot to clear things out. Just disabling the app will not always flush the bad code.
I suggested @Keo keep the hub running as is (with custom apps disabled and a reboot) for a bit to see if the slowness returns.
Download the Hubitat app
