My hub also ground to a halt on 1.1.3(.113 but really on all of them)--literally in that the web admin UI eventually just stopped responding at all (or at least I got tired after waiting a few minutes for any page to load), and I think by that point most/all of my automations stopped working, too. They had always been a bit slow, taking probably 5-10 seconds longer than normal to execute, but when they completely stopped working I decided to downgrade to 1.1.2. Everything is working fine now.
This weekend they said they were working on a performance-related hotfix for 1.1.3. Maybe that will help us (though unlike you, mine was slow the whole time on 1.1.3--and I tried uninstalling apps that I thought might be problematic like Other Hub and MQTT Bridge). I sent a ticket to support this weekend but still haven't heard back...
@bobbles Yes, we would like to take a look at your hub. Have you created a ticket already?
@bertabcd1234 We have a hotfix in testing for those people who were reporting issues with zwave locks not working properly with 1.1.2 and 1.1.3, it is not a general performance improvement hotfix.
We're expecting a performance related hot fix for 1.1.3 today [Aug. 19] if testing continues to go well on it.
Did testing not go well? I'm back on 1.1.2 now because 1.1.3 is too slow for me to use and I still haven't heard back from support@hubitat.com regarding the e-mail about this that I sent this weekend.
Iām not saying my hub has ground to a halt, it has not. However, the slowdown in the GUI is noticeable, but on the bright side, device operation is still normal.
Testing has gone fine, we have not released it yet though. And the changes were specific to the zwave network, so that was a miscommunication about "performance"
Ah. Alas, unless it's a Z-Wave device or two bringing my whole hub down, the problems I've noticed are mostly with ZigBee and LAN (Hue) devices, in addition to virtual switches I mostly use via the Alexa skill.
Still would love to hear back from Support about my ticket, though.
Just an update for anyone following this.
I've been in touch with support and have completed the following.
Support identified delays to a couple of pistons that were basically writing lux levels to a virtual device.
All my pistons were then paused by me as the hub isn't really doing that much.
Still running slowly.
Hub rebooted and then updated to 114.
Everything now running smoothly albeit with only 2 simple rules and mode changes by time running.
Support also requested that I did a backup and restore as the database looked excessively large.
This was completed.
Will now monitor and see what happens.
I really hope it is not webCoRE that is causing the issues as I find this easier to use than RM as for some of my pistons I would need Virtual devices configured and about 4 rules to do what I can do with 1 piston.
I've been reading a lot and kind of come to the conclusion that webCoRE may be the cause. I've backed up, and removed webCoRE for now. This will hopefully go one way or the other. Support basically told me the same thing when I had issues the other night. Massive pauses on a few pistons.
I come to the same conclusion. I have 200+ devices now and I have no delay issue like some of the folks here. I was a heavy user of Webcore in ST but manage to get most of my automations without Webcore in HE.
Another possible culprit could be Phillips Hue integration as well. I removed that maybe 5 firmwares back.