Time for me to roll back.... nothing else will work.
I hope that Hubitat Support is aware of this issue.
I don't understand how many hubs could be working very well, and some (like one of mine) are just "dead in the water" with this update.
Yup. Hopefully they are making good progress on the fixes.
I would guess the fact that it has been pretty quiet in here from Bryan and Mike means they are hard at work improving things. 
3 Likes
This is more than "driver fixes"!
There must be something else... when I can't even get into the UI.
Corrected. "Driver" was a typo/autocorrect.
C-5 with 2.2.1.116
Was having regular slowdown. Rebooted hub everyday.
I updated to 2.2.3.119 2 days ago and completely disabled rebooter app. I keep my usual dashboard open 24/7
So far, so good, hub has no slowdown and tiles/apps are displaying faster than before
Yes, the engineers (myself included) are working on it.
There is a handful of improvements still being tested internally. If I had to guess, the one most likely to affect your hub is improved event history management. We saw folks who updated to to 2.2.3 reporting much better response times after nightly cleanup job has run. So why not do a cleanup when hub starts and avoid sluggish response until overnight job? Hindsight 20/20...
Hopefully this fix will deal with the slow hub issue. We'll keep chipping away at the problem until it's no more.
7 Likes
I tried that zwave repair failed every device
Very odd.
I've had no issue with the zwave repair (other than some "busy" messages in the log).
My hub has also slowed to a craw since tge update. Dashboard timesout on web browser, rules and other apps take minutes to run actions which were previously done in less than a second.
Roling back to an older version
FWIW, just shy of three days since reboot on 2.2.3.118 here and virtual switch delays now all exceed my .07 'warn' value; performance is deteriorating.
Minimum delay has nearly doubled from approx. .038 to .071 in sample period. Interestingly, max delay is still relatively low (.463; for some reason the periodic 5.1 sec spikes haven't occurred recently-- has some scheduled housekeeping stalled?).
Median and mean delays also remain reasonable and are below the thresholds at which my piston would restart the hub. Subjectively I haven't noticed any performance hit and nothing unusual has been logged. Everything still seems to be running fine. After the equivalent uptime on older firmware, I'd be seeing much larger and more frequent max delays, extending into tens of seconds, and noticeable lag in automations.
Is the value expected to be that low for a virtual switch? My hub is consistently in the .12-.18 range but I’m not noticing any sort of issues. Perhaps my tolerance is just higher...
I'm sure it varies based on what is running on the hub, the numbers I usually see for a virtual switch seem to be quite a bit lower than yours. Also I only have about 75 physical devices (but lots of virtual switches and automations).
I've just rolled back to 2.2.2 and my problems have cleared. Hub is responding well again.
1 Like
same here- rolled back and ita responsive again. Something messed up with 2.2.3
Just tagging @bcopeland and @bravenel so they are aware of this thread - looks like many people experiencing similar issues
1 Like
C3 here, update went w/o a hitch, been running great for days... logged in this morning, no response, tried IP:8081, it started to render the UI with the title bar and the left nav pane, main screen provided 404 Error
Logged into the Android app, immediately launched a battery dashboard with no issues, tried another which was fine and then opened the local UI, all good
Went back to my laptop with the Chrome browser and now the hub is responding
Not sure what triggered it to respond however I am relieved and now a bit worried at the same time
We're all pulling for the HE team 
Edit: Now I see my log is gathering Alexa errors which I haven't seen for many months...
Edit 2: The Alexa log errors appear to be during an internet outage as my Ring Alarm went onto Cellular backup for about 20 mins. We didn't loose power, apparently just lost the internet...
Still doesn't explain why my hub wasn't responsive this morning. I'll keep digging
One of the only differences between my C5 and 2 C4's was the inclusion of the Alexa app on the C5...
Of course my C5 also has the radios set to "offline" as well.
Both of my dev hubs (C4 and C5) have both radios disabled. I didn't have any issues on upgrade, or use since upgrading.
I realize that doesn't mean no one else does - just sharing my experiences.
Unless I have two of the only C-3 and C-7 hubs that share this feature, based on what I've seen (sniffing packets) the Zigbee radios never turn off (even when the hubs are in shutdown status with power still on, yet Zigbee status set to 'Disabled'). Zigbee commands don't execute when the status is 'Disabled', but the hubs radios still are broadcasting.
That is bad and can cause interference, bandwidth reduction and (maybe) extra processing to listeners. 4 of my hubs have Z networks disabled.
@mike.maxwell
Please tell me it’s not so Hubitat , or in those immortal words ‘make it so’
