Could it be? 2.2.2.125 Fixed the slowdown problem?

I loaded 2.2.2.125 yesterday. And other than during the Hubitat evening maintenance and backup, there has not been a single slowdown. I monitor it every 10 minutes on two devices using Hub Watchdog. This is the first time since owning Hubitat that I have seen a day like this, even with automatically rebooting daily at 4AM. Now I am not rebooting but instead just restarting the Hubitat process after 10 consecutive minutes of slowdown, and still had slowdowns. The Maintenance period always shows a slowdown for 3-6 minutes, and that may be understandable, but I have not seen a slowdown other than that since I loaded 2.2.2.125 yesterday morning. One day of no slowdowns may be premature to say it is totally corrected, but I am excited about the possibility. I will continue to monitor and let you all know.

For those that may know the details of what is in the latest release, is it possible that something done may have addressed one or more issues that might have been leading to this?

LJ

3 Likes

I have been waiting to post but I had to reboot my hub every 3 days or by day four it would start to crawl. I am now on day four and a half (build 2.2.2.123) and my hub is still running normally so I think you may be on to something. Fingers crossed.

FYI: I do not run RM and don't even have it loaded.

The release notes indicate Rule 4.0 performance improvements.

Although I thought that had more to do with editing rules than their execution. Perhaps the editing fix coincidentally fixed a memory leak?

Without going into details, yes, there were changes to address some of the slowdown issues. I wouldn't use the word "fixed" just yet, as all of the changes were incremental, but it's good to hear they made an impact. We'll continue down the same road of small incremental improvements in the next releases.

26 Likes

Exciting for all those users who had issues

3 Likes

It's the 'onion' metaphor...

Each layer of the onion peeled back (incremental changes) improves life for those that were on that layer. All the remaining layers of the 'onion' remain.. to be peeled next and next and next releases.

Least that's my take :smiley:

4 Likes

Interestingly, the outer layers of an onion bulb tend to have more concentrated levels of sulfur (which generates the sulfuric acid that stings). Peeling a few layers off before cutting the bulb is usually sufficient to dramatically reduce the stinging.

By analogy perhaps reaching a threshold of incremental improvements is sufficient for most Hubitat users to no longer experience slowdowns. Maybe that threshold was reached in 2.2.2.125 .....

7 Likes

Have I missed something here? How do you "restart the Hubitat process"?

Two different tools by dman2306. Hubitat Hub Controller, or Rebooter. Based on his description, after working with the Technical staff at Hubitat, he was able to implement this, and is supporting the Hubitat staff in providing input related to whether or not doing the Hubitat Process restart rather than reboot made any difference. They were hoping to prove that perhaps at least some of the slowdowns were truly in Hubitat processes and not in Third party apps. For me the Hubitat restart seemed to be at least as effective if not more than a complete reboot.

LJ

Restart or reboot , what's the difference?

The only point to make is that with a standard reboot, the zwave radios do not "go down", i.e. they are powered for the entire process.
Is a restart different in that respect?

With numbers like this from Hub Watchdog, I doubt that anything has fixed the slowdown disease: (or my version of the disease):

1 Like

Hmm...My Watchdog reports are literally clear. I don't know the exact difference between Restart and Reboot in the context of @dman2306 's work. Let's ask him.

LJ

Restart only restarts the Hubitat process (so the underlying Linux OS is not restarted).

Reboot restarts the underlying Linux OS, so naturally the Hubitat process is also restarted.

1 Like

Why does your Watchdog report say "Zwav" after the delay time? Mine just says "null".

LJ

Wow, How did I miss THAT one! Is that new? or am i blind. (no need to answer that! :flushed:)

LJ

Was this added in recent firmware versions? I didn't see anything in any release notes.

I'm still running versions from earlier this year hence my question above ..... I don't see a "restart" option anywhere, only reboot.

Doesn't appear on the docs site either at Hubitat Diagnostic Tool - Hubitat Documentation

Can't remember, but it has been there for at least a few months. It has never been documented. I believe someone at Hubitat brought it to @dman2306's attention, presumably with the goal of seeing whether restarts were as effective as reboots in resolving a slowdown.

Because, if only reboots resolved a slowdown, it would imply the issue lay outside of the JVM running the hubitat process.

1 Like

Didn't know about this. Thanks!

LJ

1 Like

Thanks @aaiyar didn't know about that ...... would have thought that with all the issues this would have been a good thing to officially announce!

1 Like

If folks have slowdown problems, stating what hub type may help in narrowing problems. The different hubs have different software configurations on them.

I do see improvement in 2.2.2 releases on my setup. I expect there are fixes in web sockets and eventstream methods (likely helping folks using hub connect, nst manager and the likes).

I have C4s, recently started using C5. On my busy C4 hubs, I had to restart every 36 hrs, now it goes many days. I do find doing many compiles shortens my restart interval. I subscribe to the onion theory mentioned above

As FYI, I use hub connect, nst manager, webCoRE (over 100 pistons), Rule Machine, weather apps, maker, Package manager, Intesis, tankUtility, Wemo, Alexa, etc.

2 Likes