oh... alright that must have been from before I re-enabled them.
Since doing I'm hoping the webcore editor is gradually coming back alive. I can now get to the piston list, but I can't yet load an individual piston. I get:
There was a problem loading the dashboard data...
The little processor in the hubitat must be burnin' up!
I wish I knew what this thing was doing. I still can't get into the editor for a piston, and none of my pistons are working... I don't quite understand what's taking hubitat 40+ minutes to sort out, especially after it took 3hrs or so to get back to the point where the hubitat interface itself worked.
I'd pay double for a box that's twice as fast...
It's not the CPU speed that's causing this. The CPU is plenty fast. Something else is dragging your system down into the mud. Could be webCoRE, hard to tell from here. If you contact support@hubitat.com we could take a look and see what's going on.
Well I'm at a bit of a loss here. 3+ hours since upgrading to 1.1.7 and my hub still isn't functioning.
The hubitat interface came back alive, but it's not discovering new devices. The webcore interface gets stuck at "\loading..." and that's it.
May I suggest as a test that you remove webCoRE and see if the hub functions correctly or not. You have backups of the database, save one to your pc. You can restore back later. Something is amiss with webCoRE most likely. We don't support it, can't support it. It was designed specifically to run in the ST cloud, and in the best circumstances introduces considerable overhead. Not bashing webCoRE, I actually like the concept and ui, but it's been nothing but headaches for people on Hubitat Elevation.
What's weird is that most aspect of it were working pretty well 2 days ago, then it all got weird. I wish I could tail a realtime log of what hubitat is doing.
The logs tab isn't that helpful. It's especially unhelpful when the whole box is unresponsive, which seems to be any restart+3hrs.
It sounds like something is thrashing about. Your loops of setting a global variable until its set would be a possible example. That may sound good before you do it, but the law of unintended consequences could catch up. Every time an app does a runIn, such as do something in 1 second, that means the app has to be loaded from the database. While doing so doesn't take 1 second, get enough of that stuff going on and you could get in a gridlock situation.
Like I said before, if you contact support they might be able to give you some clue to go on. It seems that you're hitting your head against a wall right now. Hate to see you so frustrated...
OK well I seem to have stumbled on a recovery procedure.
Shutdown the hub and remove the radio stick
Boot without the radio stick
Hub comes up and is responsive
Go into apps -> webcore and tick the "disable all pistons" slider to "on"
register a browser with webcore and browse to webcore dashboard
Pause all pistons one at a time
shutdown the hubitat hub cleanly
insert radio stick
reboot
in apps -> webcore -> slide the disable all pistons switch to "off"
in webcore dashboard enable pistons 1 at a time
I'm back up, so yeah it looks like a race cond of some sort on startup. Probably was those variable setting loops I was messing with to try to get around the global var issue.
Its nice to know I can recover if I need to. I guess there's a bit of a learning curve. Sorry if I got a bit pissy. I've been in the entropy vortex for the last couple of days, not just with this. Bike broke yesterday, tv broke, db I'm working on broke, dog threw up on the rug, etc. Just one of those losing streaks.
Download the Hubitat app
