I know there are many anecdotal/individual comments about issues (all of which I believe, not arguing their truthfulness). I just meant that I don't remember seeing Hubitat confirm an issue publicly.
1 Like
Had my first lockup today, booooo.
I know some folks are using Wemos, but how are y’all automatically detecting the hub is locked up? Would prefer a way to auto reboot
Even the experts don't disagree with that
So I have disabled all my TTS and Chromecast to see how it goes. So far so good, things are faster and stable.
I do have 14 various Chromecast and Google Home devices so I'm pretty susceptible to problems I guess. I do have solid LAN and WiFi and I can cast without issue. If I can gather logs or help out somehow let me know.
Remember the point of disabling is not (necessarily) to leave it off, but to identify exactly what combination of elements lead to each person's specific slow/locked hub.
Maybe you feel Chromecast is the culprit.. cool, but maybe turn it back on with none of the TTS devices. Add one at a time? Perhaps you will find that ONE of those is a problem. So much easier to say "I'll do without that one device" than "I can live without TTS" 
2 Likes
It's been well over a week since I did a Hub Reset followed by a Restore, and disabling what I believed might be (or have been) the device driver that caused or contributed to my hub locking up twice.
Everything has been running just fine, without any slowness, so I have contacted the author of that device driver and he said he's working on a new version anyhow. Since I honestly don't know whether that device driver was the culprit in whole or part, I don't feel I need to raise an alarm, especially as no other users reported similar experiences in using the driver.
Suffice to say, having the ability to use the disable driver/app feature was very helpful, and probably doing a Hub Reset followed by a Restore was a really good idea as well.
5 Likes
If nothing else it gives you a nice clean database with no hidden corruption... Which directionally has to be good, right?
1 Like
Hey gang.
Just a quick update in case it helps anybody - as you might recall from higher up the thread, I huffed off and started migrating everything off the hubitat system... but it's still running for now while I move functions off it. Thus far... all I've actually taken off from a hub that was crashing every 48 hours or so was to physically remove the Zwave and Zigbee sticks, as they're now attached to the new system. The hub still does things like Alexa TTS, and some rules that don't rely on zwave or zigbee sensors, and it's still got all the hue bridges attached, etc. But... it's been a while now, and it's not locked up again.
So... in as much as you can learn anything from that... not receiving, and processing, events from the 40 or so (mostly Zwave - there's only half a dozen or so Zigbee devices) looks to have been enough in my environment to stop it exploding. Given it's black-box nature... the only theory I can usefully support in that case is some sort of generic resource exhaustion problem, and my setup for whatever reason tipped it over the edge.
Anyway... I've got the vast bulk moved over... so my next steps are moving all the alexa integration over, and then I'm about done. Just thought I'd give the benefit of the observation that if you lower the number of reporting devices on the hub, it stops dying... at least for me.
-- Jules
1 Like
My "controller" C5 hub locked up this past weekend - stopped responded but light was green. Had to powercycle manually. I only have HubConnect as a 3rd party app and some minor 3rd party drivers that are not causing issues on my other 2 hubs.
It seems to happen when the internet drops or if the power goes out and returns before the hub can make a connection. I cannot really tell though. I only use the controller for illuminance and mode related updates.
Both of my hubs went down overnight. My home router (AC1900 Netgear) slowly died overnight, I noticed (was being unresponsive around midnight, died by around 0300). After rebooting it, HE's web UI was responsive, but everything else had killed. Didn't have a chance to look at the logs.
Same with our office hub. I'll have to check if our Internet went out there, too, but I wanted to share my similar experience, whether it's correlated or not.
I think there is a strong correlation there. In the last year, I've had one instance where the hub got into a non-responsive state and radios shut down but was hesitant to report it because of the finger pointing that usually follows.
In that instance, I rebooted my router for a firmware update, not considering the impact on device communications. I went to the kitchen for a drink, and quickly realized something was wrong. Out of curiosity, I didn't reboot the hub, but let it churn and about 45 minutes later was able to get the past logs. Comparing those with the router logs, it became apparent that when certain TTS apps, weather drivers, and lan controlled switches all try to communicate at once, and can't, there is a problem. (about 200 errors in the two seconds before zigbee shut down)
I wish I were more knowledgeable about these things. Is there some function in computing that says "Somethings not right. Stop that process and move along, please"? Would something like that reside in application code or in firmware?
Forgive my ramblings and semi-rhetorical questions. Just thought I'd add my $.02.
2 Likes
I'm going to attempt to recreate this in a lab environment, one device/app at a time, and see what's going on. Hopefully I can alleviate the finger-pointing and get some solid data... I'm hesitant to publicly report things like this for the same reasons.
5 Likes
My only custom apps are echo speaks, nest manager, advanced button controller, tp link app, and noah weather alerts. I had 11 echo dots connected through echo speaks and my hub went unresponsive every other morning like clockwork. I cut back to 6 echos and now can go 3 days between reboots, and I can actually reboot properly now, whereas with 11 echos connected I had to pull the power to reboot the hub. So I would agree that it’s likely related to network devices somehow. When I was on SmartThings, WebCoRE would stop working when I had all of the echo devices connected. I know that’s what caused the problem because when I unchecked all of the echos, it immediately worked fine, reenabled them and immediate problems.
I just removed the APIXU weather driver. I also have a (very) simple custom email notification driver I wrote that only does an async call - I cannot imagine how that could impact things especially since it's supposed to be non-blocking. Also I have it installed on my other hubs (both C4s) with no issues that I've noticed.
Other than that I have HubConnect running. It's probably not the most recent but not that old either.
A bit of info that might be useful for people experiencing lockups that can't be explained by Chromecast TTS or APIXU, or other community apps.
I have a C4 hub that had been locking up on almost a daily basis (red light, solid lock). I was puzzled, and followed along with this thread to see if any of the suggestions made sense with my configuration.
My hub was mounted in the same upstairs closet as my Media Server, a network switch, a pi or 2, a Hue Hub, and a Zwave Toolbox. The Hubitat, Hue and the Toolbox were all mounted vertically on the wall, spaced reasonably, but probably at least 6-12" apart.
The closet gets warm, and although I've never measured it, it's probably in excess of 85F.
Though this doesn't seem terribly hot, the Hubitat is passively cooled, and it seems that while the Hue Hub, Zwave Toolbox and Media Server were all content (or rather I have seen no ill effects), the Hubitat simply didn't like it.
On a whim, I moved it out of the closet and onto a table about 6' from where it was. Ambient is now in the low-mid 70s, and there is air movement due to a ceiling fan whenver the temp is above 72. This seems to have effectively eliminated my hub shutdowns. It's been up constantly for more than a week, with nary a glitch.
Perhaps not helpful in all cases, but it appears that the Hubitat C4 might be slightly temperature sensitive, and if you install it in an enclosed space with other forms of heat, it could result in lockups (and is probably not good for the lifespan of the Hub!).
It probably comes as no surprise that I'm reconsidering the location of the primary heat source (the MediaServer!).
For now, the Hubitat is staying out in the open!
S.
5 Likes
My C5 HE is mounted sideways behind (i.e. outside) the media cabinet that it initially was in. I used tiny command strips for the mounting. Still gets warm, but not as hot as it used to.
1 Like
Got mine wall mounted using command strips.
I’ve never had a lock up.
1 Like
Makes perfect sense. All of my hubs and server equipment is located in my basement where it’s naturally cooled. Never have to worry about overheating down there.
1 Like
Yeah, in hindsight I should have put it elsewhere, but the WAF was in play, and neatness counts! As in, hidden is neat. 
2 Likes
