One step forward, two steps back.
I hate to say it in this thread, but those are 'ordinary' in the sense they indicate the WebServer built into the Hub encounters an error. Hitting BACK to a page that no longer exists, for example.
There are errors that are 'wider' than others, but for the most part, just click on the Hubitat logo in at the top of the left hand menu and you're good to go. As a developer, I'd love to have a dime for every time I caused a webserver to 500 out. 
2 Likes
Error on Google Home app that seems to have started the sequence of issues...
And the final error sequence prior to Error 500 (from several Xiaomi motion sensors)...
I guess yet another soft reset is in order today then.
The Google Home error simply says you've exhausted your fair share of resources.. you have a quota and exceeded it. It's probably a 'per minute' quota, so slow down
Quartz is the Hubitat Scheduler.. suggesting something is also exhausting resources.. "ResourcePool cannot acquire a new resource" -- pretty straight forward language for SQL
Again, slow down and let the ResourcePool drain and have some become available.
Neither look like a Soft Reset candidate to me.
1 Like
This error effectively locked up the hub. If such an error really should be considered "ordinary", then it's a concern to me that this causes the system to completely lock up requiring a reboot. In my case this meant the HSM alarm immediately sounded upon reboot (since it still thought it was the middle of the night and there was motion downstairs) and the wife went mental (again). Sorry, my view of ordinary error on a commercial/retail product doesn't align with yours. There is no other product in my home right now that has these issues. And I have many, many products 
OK, thanks. Not sure what to do differently. Shouldn't the system handle this without a complete seizure requiring a reboot?
I will try to handle this in my RM startup rule by disabling the alarm on startup. Not sure if that would have avoided the alarm going off in this exceptional circumstance. At least this way the wife may not have noticed the issue again! (WAF currently <0, "I must show you how all this works honey, just in case...given the current circumstances". "Don't bother, I would rip it all out") 
The extent of the errors you have been reporting leads me to suspect you might have bad flash memory in this hub. Is it still the case that your other hub has no errors? You seem to have a uniquely bad situation.
Do you have something odd running on this hub that could be pushing it beyond its limits?
2 Likes
don't you ever sleep?
1 Like
Sure, don't you?
2 Likes
Yeah my other hub seems fine (although it is definitely not running as many devices or as much automation). It doesn't require any reboots whatsoever and just seems to tick along. But there would definitely be a different level of load on this hub.
Not sure what to do next. I did rerun the Google Home connection to Hubitat last night because I'd added some additional virtual switches that I wanted to connect across. That seemed to work fine (I selected all devices to save time and the connector filtered out the unsupported devices). Then after this morning's issue, when scrolling back through the logs to try to see what had happened I noticed the GH error again that I'd seen before a few days back. Maybe no big deal but thought to record it here anyway.
I'm willing to try anything you guys suggest. This error came off the back of 2-3 days of reasonable performance and no reboots (I used to reboot nightly and then reduced this on advice above). So things had been looking better after the various things I'd tried.
Cheers.
If I were to look at your hub would I discover a rats' nest of weird stuff?
1 Like
If you have anything specific to ask, or a proposed next step, just let me know.
Bruce, what can cause this? That looks to me like an error message that would happen when his hub (as csteele has pointed out) has interacted too frequently with the Google Assistant integration. The OOB integration doesn't support sensors yet and nothing should be polling or periodic. Short of asking Google to turn on the lights a LOT what would cause the quota to exceed?
Continuing to document my experience with my hub...
After a week of relatively good experience, nothing to report, no reboots required, just the normal slow response time by time on some motion detection...
Woken up at 7 am with the bedroom lights on. Hub is completely seized up with no dashboard input possible and no response on any page on the Web interface. Managed to reboot using the :8081 port (this has always worked for me). Reboot took a while at 10%,whatever that may mean.
Absolutely NO ERRORS in the logs at all (which ran from 1.32 am until and through the reboot just after 7am). That seems very strange indeed. In all prior cases of seize ups, there was at least some evidence of a few red error flags.
Latest update. This last few days have been much improved. The list of various actions taken, explained above, seem to have fixed the issues I was having (at least for now!). Performance has been reasonable and no crashes for a while now and no reboots necessary apart from hub updates. This is a huge step forward for my system and user experience.
I also updated all my motion rules with the guidance from @bravenel in the most recent live event (instead of using changed for the motion trigger, use active, remove the ifthen structure and use wait instead). I believe this has also helped performance of motion lighting rules as we move around the property. Very happy with that change.
My Zigbee mesh also seems much better now after adding 3 IKEA Tradfri repeaters. But this really took ages to settle (several days and multiple device reconnection, not just 24 hrs after a hub power-down). Lesson here for me is it takes time to settle. No drop offs for days now, including the Xiaomi's (where I also updated to the very latest drivers).
I'd also disabled the Chromecast beta app a while back (as advised) but have found that it's still OK to run TTS through the devices with no hiccups whatsoever and no errors in the log. I'd assumed that disabling this app would remove the ability to do TTS with my Google Home devices but they continue to work fine.
Progress!
(of course immediately after posting this, the hub will undoubtedly crash ha ha ha)...
5 Likes
Latest issue. Noticed the hub had frozen up early this morning. No errors in the logs for several hours prior to the reboot I had to initiate using the 8081 port. I noticed a very strange error I've never seen before, just after the initialisation after the reboot.....
I have absolutely no idea what that error is related to. Maybe @bravenel can elaborate.
The only other error I see in the logs is a Maker API error from several hours earlier.
What is Device Number 2224? That might help at least point to the driver code that is having an issue.
Yeah, good point. It's a Sharp Aquos driver that I jinstalled a couple of days back but didn't set up yet. Not sure if it might have caused the lock up since I didn't configure the driver yet to the TV. This error occurred after the reboot, with no errors prior, so I would think is not related to the lockup.
Looks like you're not alone...
