Actually I now suspect this may have been the cause of my hub going kaka in the middle of the night this week. I woke up and found the front panel led had turned green, only solution was to pull power.
Mine has been slow lately as well, but I've been making so many other changes it would be hard to pin it on a firmware upgrade in my case. I did upgrade a while ago to the latest firmware as well.... Not sure this really helps...
Great tip, I had no idea, I can even go back to 129 if I wanted.
I might not use it myself this time, but will certainly keep that in mind.
I think it would be useful if that was made known to users as they applied an upgrade, that and an option to download the pre-upgrade backup outside of the hub. Perhaps even nominating / configuring a cloud hosted platform of choice, e.g. Google, OneDrive, etc.
I believe there were quite a few changes in the 2.2.3.x platform to enhance/improve overall platform stability and performance. These changes may have sacrificed the admin web interface performance slightly, as compared to 2.2.2.x. However, my hubs have been very stable on 2.2.3.
The correlation of reported free OS memory to hub performance may be a little nebulous, at least in my experience. When I tracked free OS memory on 220.127.116.11, after 150 hours uptime it showed 359K available yet the UI performed very sluggishly; apps begain failing and the hub required a reboot. Yet on 18.104.22.168, after running for 377 hours the hub reported 255K free and still ran acceptably well (though it eventually required restarting a couple of days later).
This leads me to wonder if some kind of thread synchronization is the root of this issue rather than a memory leak (like what percentage of time the CPU is spinning on locks vs. doing useful work).
so the next test would be do you have 'runaway process' eating the cpu cores.
In the wiki above, there is enableStats and disableStats, so you may want to enable for a while and see if something is running too much (eating the CPU AND HEATING UP THE CPU).
On C4s, do monitor your temperature - they are more likely to turn off cpu cores due to temperature issues than C5, C7. They do attempt to turn the CPUs back on, but if it is hot, they will go off again. You can test this by increasing airflow around it for a few hours if you see the slowdown with a lot of memory. I don't think HE exposes via web hook cores online or cpu load average.
I keep my C4 vertical (vents exposed) and not in a too warm place...I have never had a temp issue with C5 or C7.
I've noticed this as well. I've also been having other issues. I have gone to weekly reboots that I did not do before. It's gone completely unreachable twice in the past few weeks. I have no led's, stopped working a while ago. I didn't post as I haven't dug in at all and having nothing to add. I was unaware of the 8081 having the last 3 versions. Thanks @april.brandt and I will follow @nh.schottfam advice, thank you. I did notice my hub was unusually hot the couple of times it went unreachable but it's in the same spot as always and the ambient temps have been cooler.
In my case UI latency increased (by my subjective estimate) by up to a second, although I don't think rule/automation performance took a hit (at least not that I could discern).
I believe it's the last 3 updates you actually made to the hub rather than the actual released versions. So if you applied all 7 releases in 2.2.3 you wouldn't be able to go back to 2.2.2
Not as far as I know unless you have devices whose built in drivers didn't exist before or use functions that weren't available previously.
I wasn't aware of these hub functions (beyond the hub diagnostics page), thanks for bringing them up! I haven't done these tests as a rollback of the firmware with no other changes brought an immediate improvement in UI performance so unlikely to be a direct fault of devices/apps?
The above 4 hubs are part of my Production set, interconnected via HubConnect.
I have a C5 and C-7 as my Development set, interconnected via HubConnect. Because of their role as development hubs, their restarts are usually related to soft resets I do to swap in various configs. The C-5 had 3 restarts while on .148 and the C-7 had 2.
My final C-5 is also development but not interconnected. It was upgraded to .148 on the 16th at the same time as the first 4. No restarts.
Again, my purpose for detailing this is to indicate that YES, the hubs shouldn't need rebooting, and it is correct to try and find ideas about how/why/when anomalies occur. The reason I say YES, is because all of my hubs work fine on .148 without restarts-for-slowness. Yours should too.
My C-3 has 57 ZWave, 0 Zigbee, 98 devices total
My C-4 has 25, 23, 69
My C-4 has 0, 0, 160 (This is my HubConnect Server Hub with the radios disabled.)
My C-7 has 13, 0, 18
My C-5 has 1, 1, 9
My C-7 has 2, 0, 10