I am getting the unresposnive hub ui and automations after updating to 1.17 sources are saying webcore is the problem.... If I got to IP:8081 I can revert to previous versions hub boots and the ui loads but becomes freezy and unresponsive before I can get anywhere to do anything... How is everyone fixing this? I wished there was a safe mode that I could work in to go disable the problem...
Managed to fix mine by unplugging radio stick and booting. This freed the hub enough to 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.
2 Likes
I can look into adding a staggered startup for pistons. Right now, the first piston that runs tries to fire up all the pistons that missed an scheduled execution which can be tough since the hub is trying to startup everything all at once not just webcore.
The biggest thing that I've seen is that the hub has to recompile user apps on reboot which takes awhile since webcore is so large.
@chuck.schwer had mentioned in the past caching the compiled app code on reboots which would help.
How many pistons do you have and how many are schedule based? (run every minute, hour ,etc)
Is it only the http calls to your router that are failing? From your exception the code is happening in the hubiat api layer below webcore since it doesn't have streams or stringwriters.
I did a test call to google.com which stored the httpresponse. Maybe try a small groovy app that just does a httpGet to your router to see if you get the same error outside of webcore.
If your post your pistons I can take a look. Globals aren't updated instantly from what I can see in both ST and Hubitat so if two pistons are writing to it during execution one might overwrite the other, but I would need to see the piston code and debug to be sure.
If I can ever get the hub back alive I'll post them 
This is what i have just seen after the update. I always give it a while but i think the best was is to click done on all the pistons before they run on their own. It would be good if something could be set-up that automatically does this 2 mins after a hub reboot then does one child piston every 5-10 seconds or something.
hmm... I still can't even get into the apps section...
That's the plan for missed scheduled pistons. The ones that are based on device events like motion, though, I can't restrict as they are fired off the Hubitat subscription, not webcore.
By that you mean you can't stop them firing before you have chance to set them up correctly? You would essentially need a middle man between the devices and WebCore and have a switch that turns all the devices off while everything is booting.
Or is it possible to add a pause all pistons? Then start them one at a time?
I have no idea what you're talking about. Sorry I'm not a programmer.
I only had like 6 pistons at the moment. With plans for more. But I may put that on hold as any sort of reboot would put me dead in the water. It’s definitely something wrong with the start sequence as I tried for kicks a regular hub reboot and I was in the same boat. I restarted with the stick out again and paused all the pistons. Rebooted and then went in and Unpaused all my pistons and all work as expected. I would think that maybe something could be made that looks at hub uptime and waits for it to to be greater than a certain amount of wait time before attempting to load pistons?
That's strange. On the latest firmware I have around 50-60 pistons and my startup only takes around 5 minutes before everything is running like it's supposed to. Might be worth pausing them individually to see if one of them is causing trouble for you.
3 Likes
Well.... I upgraded my hub to 1.1.7 yesterday and I'm not seeing the global var setting problem that I was seeing for the last few days anymore.
I did struggle post upgrade, and I'm not sure my hub will boot properly as is with all of my pistons enabled. I was getting into a race condition with some of the piston startup, but I've figured out that the way to work around that is to boot without the radio, pause all the pistons. Stop the hub, boot again with the radio, and enable one by one.
Dunno if the upgrade did it or rebuilding the webcore data cache, or the fact that I'm running webcore recovery every 5 minutes, but suddenly everything is working well!
I still need to test if the piston pause trick is needed on every reboot/power outage, or if the hub will boot cleanly now that I've taken out all the loops that I was trying to use to force setting of globals.
1 Like
You shouldn't need to rebuild data cache that frequently. That might be causing a big slowdown.
Yeah I've dialed the recovery back to once an hour. Frankly I don't notice a difference in performance, everything seems to work fine either way. I'm not even quite sure what this setting does...
It does still look like I need to pause all pistons before rebooting then enable them one at a time, though I haven't tested this extensively. It would be nice to do this in code rather than having to do it by hand. In the meantime I've decided that I need a UPS ASAP.
It's not a call to my router. It's to a set of digital LED strip lights.
Of course not 12 hrs after placing the order for a UPS with Amazon, and getting my hubitat/webcore stable, we have our first power outage in 3 yrs... Sigh.
Well, ok, that was an interesting test. I was expecting the hubitat to come up slowly or completely wedged due to webcore piston startup issues, but it rebooted itself just fine. Everything came back up in just a few minutes, including webcore.
I don't understand what the difference is in this case, compared to a reboot I did yesterday which (seemed) to require stopping all the webcore pistons and then starting them 1 at a time in order to get the box up.
I don't understand whats different, but I'll take it. A box that can recover itself is certainly preferable.
I don't know.... I don't have any trouble rebooting. Of course I only have like 5 pistons now but might end up having more if I can't get motion lighting to work right.
I'm having issues getting the Weather Variable to work on webCoRE on Hubitat. This is with any piston I have that is using the $weather variable.
I get this error in Hubitat Logs:
2018-11-05 22:48:29.718: error groovy.lang.MissingMethodException: No signature of method: app15412903163361203846002.getWeatherFeature() is applicable for argument types: (java.lang.String) values: [conditions] on line 5116 (getWeatherFeature)
Piston Example Below:
