Reboot comes up for a second, then freezes again. Spins and spins and spins. Power off/on same thing. HELP.
What custom apps and drivers do you have installed? These are usually to source of this kind of problem.
See this post:
Well its pretty much only webcore and I don't doubt the problem lies somewhere in there.
It seems to have stabilized. Maybe I didn't wait long enough after rebooting to give the hubitat enough time to start all of my pistons. I was able to get into the apps section and stop all the pistons. Everything seems to have stabilized a bit after that.
I still don't quite understand the interaction between hubitat and the webcore dashboard. It keeps throwing up a banner that there was a problem loading dashboard data but then it goes ahead and loads, though everything seems slow. I thought maybe I was running out of memory or something but a look at the webcore app in the app list shows its only using 12%.
Phew... ok well, I was finally able to back all of my pistons up in batches of less than 10. This is still frightening in that I don't know what caused it, and I don't know what solved it either.
The one thing I did is turn logging off on every webcore piston I could. Would turning down Max number of stats and Max number of logs do anything? I guess I'm thinking along the lines that one of the pistons was logging too aggressively, which cause everything else to grind to a halt.
Unfortunately I ran into issues running WebCoRE as well... I've converted everything over to Rule Machine now. I'm still learning is nuances. It's simply not made for Hubitat.
Was a big bummer to be, but I've gotten over it.
mine is doing this same thing after the update to 1.17 hmmmm
I can confirm this has happened to me every single time I have tried to update since 1.1.2...
I was lucky - I had access to my hub for approx. 3 minutes before it would start to "lock" after I did either a hard or soft reboot; mostly hard.
The only way I managed to get my hub stable was to DISABLE all pistons within that 3 minute period. The hub, for lack of a better description, would then stabilize, and I could re-able all pistons. But given enough time performance would degrade again to the point of a semi-locked hub...
I now have less than 15 pistons left, stuff that simply cannot be done with RM.
I have also moved all my pistons back to ST & use the HE<-> pusher to do things; works remarkably well, both the ST update & WC controlling HE via ST. Nothing is mission critical as this would defeat HE running local.
Yes, like most, it has taken several rules to do what a single piston could do, but oh well.
Oh, this last update was flawless for me using the above strategy.
DOS Ain't Done Til Lotus Won't Run
Thanks
J
1 Like
I fixed mine by unplugging radio stock and rebooting. This freed up the hub enough to go in and pause all my webcore pistons and reboot with the stick. Then I could re enable my webcore pistons one by one. Perhaps this is something the webcore people can fix. Like a staggered or delayed startup maybe. In the future I’ll just pause all my pistons before performing an update.
Yeah, webcore looks good but there are some SERIOUS logic flaws in it, on Hubitat anyway. Not the least of which is that setting of @global vars seems to be rather hit or miss.
I'm guessing that globals aren't really global, they're actually just copied to every subscribed piston, and there's a timing issue of some sort. You set a global variable and sometimes it gets set... sometimes it doesn't. Some global variables set correctly every single time, some rarely get set correctly. Sometimes if you throw multiple set commands at it, that works, sometimes it doesn't. It's truly baffling,
Even if you set your global in a loop until your setting piston thinks its true, that doesn't mean its true in the consuming piston. They must have solved this somehow on mainline webcore, but its still an issue here in hubitat-land and an impediment to serious use.
And yet it use to work like a charm... I had well over a 100 pistons working beautifully, including all of the aforementioned issues looping/vars etc. etc. And then one update "broke" it all... Not finger pointing, just real-world personal hard gained observation.
J
1 Like
which update? An update to hubitat or webcore? Were you able to revert? Can you provide a hubitat version number and webcore version number that will work together?
History:
There was/are issues with Apps running away, infinite loops, etc. In an attempt to prevent that, apps were given a "max run time" (paraphrasing). WebCoRE on Hubitat got hit by this, although at the time, it was clear that was unexpected. The implication is that WebCoRE "runs" more than expected. The solution was a hot fix to remove the max run time.
The WebCoRE maintainer and Hubitat conversed behind the scenes and summaries were given, which I've further summarized above 
(In other words, the truth is way in the back now. )
I don't see how the previous issue and issues from 1.1.7 are intertwined in any way. The previous imact to WebCoRE was removed, and lots of confirmation that it was cured were given.
Not discounting issues with 1.1.7, just thinking out loud that they seem more likely to be NEW interactions vs a repeat of the old.
I think there's little question that WebCoRE is a net consumer of resources... how could it not be ? It's a BIG app. Which is similar to saying, if there's a resource issue, the first item to pop into most everyone's mind is...
Can you disable all the pistons first before updating the firmware? There are tons of stuffs the hub is building during startup. I don't have webcore and I still see my Z-Wave going nuts with initialization.
Oh well hmm... I just checked my hubitat version and I was still on 1.1.6 so I upgrade to 1.1.7 and see what happens. I figured it couldn't be any more broken, but that's never actually true is it? Things can always get worse. 
Anyway, I stopped all of my webcore pistons before doing the update and the hub came back alive... for a few minutes and now is spinning on the the "Apps" page, I suppose I'll go get some lunch and see whats what when I get back.
I don't know all the details of a Hub boot.. probably more like barely a few.. but here's what I've read...
The Hub has a (potentially) large DB and it checks that on boot. (That DB is the dominant component of the Backups.) If it finds it's corrupted, it rolls back to a previously saved version, and if that's no good, the one before that, etc. Clearly that can take time and the DB is probably locked.
ZWave initialization. Using other Hubs, I've seen the amount of traffic on the ZWave network at initialization and it's large and time consuming. Every device in the DB is queried, timeouts occur, details are returned.
I'm not a Zigbee user, and have spent no time watching Zigbee. Maybe it needs no initialization, but if true, I think I'd have read that as a "feature" on someone's list
Only after all the above is finished is the Hub ready for play time. 
Although, again, I'll caveat that my opinions above are from reading this forum.
yeah, well its been 20m and afaik the hub is fully locked up. The web interface is completely inaccessible. I'm going to go run an errand and if its not back alive when I get back, I suppose I'll pursue other options...
It does seem that being able to disable an app and it’s interactions would be a useful recovery/ diagnostic. Rather than having to uninstall.
Hubitat “Safe Boot” mode?
Hah! Well I went to lunch, ran some errands, came back and hubitat is responsive again. I just re-enabled all pistons... and now webcore is being slow to load. I'll give that some time and hope it comes back as well.
Anybody know what this means?
Kill switch is active, aborting piston execution.
All your pistons are disabled...
J
