Hi @bravenel @mike.maxwell @bobbyD @patrick
Any chance you can look at my ticket I raised 2 days ago.
13094
Thanks.
Without any better troubleshooting tools, system statistics, or logging I don't see how this is ever going to get resolved.
Really bums me out, as I really like the community and the idea/promise of the platform. But as of yesterday Hubitat had to be downgraded to 'non-essential' service in my house.
node-red is showing something. Here is my hub response time up until round 6PM yesterday when I power cycled. Not sure what it means yet but seems clear there is a shift in response time.
before power cycle.
after power cycle.
Submit a ticket I guess, and hope support engages. If the hub is doing something scheduled at 2am, only they will know.... Thus far they have commented almost zero on these topics, though.
1 Like
That is the maintainence window... 2am-3am. My hub perfmon spikes every night at that time as well. To be expected during cleanup time.
The hub backs up the database at 2am. That's been discussed before. They've never dinied that it could have a performance impact for some uses when it happens. However, I'm no longer seeing that with the current platform 2.0.9.133.
But I am getting weird slowdowns at odd times of the day that didn't previously occur. The discussion about the hub hitting the NTP time server so often is intriguing, but I have no way to test if that will improve things. The next platform build is just days away. These guys are pushing to give us cool capabilities and improvements. I don't expect to be let down, but I also don't expect to not have any bumps in the road.
I have custom code installed. If I start disabling (which, except for Homebridge, I have not done yet), then I might find a connection between the custom code and the slow downs. So, at this point, it is still on me. I'm a tinkerer. I'm going to break stuff on my own.
1 Like
My hub lockup yesterday definitely happened outside of the maintenance window... Worked fine 1st half of day, died sometime in the afternoon. No one has logged into or looked at the hub for 8 hours+ before it crapped out.
2 Likes
I'm a bit of a tinkerer too.
After RM 3 release I redid all my rules to rationalise them. This cut out quite a few rules but it did make them more complex.
This coincided with my hub grinding to a halt every few days.
The first ticket I raised they assured me this was pure coincidence.
No response to my ticket of 2 days ago yet.
So I'll throw it on there. I have noticed my hub locks up periodically as well if not rebooted. Usually 5 or 6 days or so I have not put in a ticket as I have lots of custom code.
I have also noticed that if the room the hub is in heats up for whatever reason I am more likely to get a lockup.
And the custom code you're running? Have you tried just disabling one of them to see what happens? If that doesn't do it, move onto the next until you find (or don't find) a change. The tool to disable them really does make troubleshooting easier.
Nope. The exact same code and drivers have been running on the hub for months with no lockups.
So what am I going to do, disable everything and then wait WEEKS/MONTHS to see if it locks up again? Not likely.
If the lockups were repeatable, or triggerable, disabling en masse or one by one would be a fine answer. But when the lockup frequency is random/weeks apart, disabling and waiting simply is not going to work.
Just curious. Is your hub mounted vertically or sitting flat?
C-4 laying flat.
Odd....I thought it was "normal practice" to do periodic "maintenance" on your hub. From the looks of this thread it doesn't seem to be the case .
"Periodic" Daily or every other day
"Maintenance" Reboot hubs to clean up any cache files.
"Normal" Accepted Regular Practice.
I haven't experience any hub lockups, but I adhere to what I thought was normal practice.....similar to having to put gasoline in a car.
OK. But same platform or you've upgraded. They've made changes, so what's to say there isn't a lockup occurring due to a platform change that the code hasn't been updated for?
I think if you just start disabling, you will possibly find the issue faster than you are guessing would be required.
2 Likes
You keep your car when it runs out of gas!? I trade it in for a different make when that happens. 
2 Likes
Not when I've only had 2 locks in 3 months... Anyway, I understand your point, but that is not the path I'm willing to take. I bought the hub to USE, not leave the most important things disabled for weeks at a time.
I'm going to think again about splitting some of the user code off to my development hub, and review if there are any more drivers/apps I can do away with without losing major functionality.
If neither of those help/work, I'll be switching to something else (hopefully) more stable. That would be annoying considering how much time and energy I've put into writing user apps and drivers.
As it is now, I would rather have the periodic ST cloud outages than complete hub lockups. At least the cloud outages come back on their own. If the hub locks up when I'm out of the country for weeks on end, that could be VERY bad.
Whilst I do agree with this up to a point, I would be quite happy to do this on perhaps a weekly basis. It has to be done in a controlled manner though. NO just pulling the power. Perhaps something in rule machine to issue a reboot command.
What this doesn't do though is find the route cause.
Mine was great before 2.0.9. This build, I think anyway, has introduced something which is causing the issues people are now starting to see.
1 Like
I would say that is NOT normal practice for a consumer oriented hub/appliance...
But even if it were considered "normal", then Hubitat should add an auto-reboot feature... Like reboot cleanly at 3am every night (or some other configurable time).
2 Likes
The Reboot cycle takes less than 3 minutes, I have 3 hubs, with 3 settings tabs open, usually right at bedtime, I'll click reboot on all 3, verify all 3 came back up and working, then go to bed....
Pretty simple, not rocket science or complicated....
