Hub process slowdown after several days

[JasonJoel]

[csteele]

Wikipedia:

The first version of the autonegotiation specification, in the 1995 Fast Ethernet standard IEEE 802.3u, was open to different interpretations. Although most manufacturers implemented this standard in one way, some others, including network giant Cisco, implemented it in a different way. Autonegotiation between devices that implemented it differently failed. Problems like this with autonegotiation led many network administrators to manually set the speed and duplex mode of each network interface card. However, the use of manually set configuration may also lead to duplex mismatches, in particular when two connected devices are:

•  One manually set to half duplex and one manually set to full duplex
  

•  One set to autonegotiation and one manually set to full duplex
  

Duplex mismatch problems are difficult to diagnose because the network is apparently working, and simple programs used for network tests such as ping report a valid connection; however, the network is much slower than expected.

Basically any Auto-Negotiate at 100M or less can fail to negotiate properly. At 1gig and above, Auto-Negotiate works correctly and should always be used.

Therefore Hub C-6 * should use the 1gig chips

(*) no such thing.. yet.

[joetlawson]

5 days in from a soft reset and the hub is still responsive. Other than modifying creating a few new rules I have done nothing else. I have not disabled any 3rd party apps or added any new ones. So I think it is possible some cases of slow hubs can be related to DB corrupting. I will continue to monitor.

[jdjmailbox]

My hubs was slowing down again yesterday, but installed update, so the reboot brought the speed back up... time will tell...

[joetlawson]

Yeah I know Bobby helped me with the port issue but I have a TP-link POE switch and Unifi router and wireless AP's and the patch did not make a difference on my end.

[jtmpush18]

I suggest for everyone who thinks that their hub has slowed down, to install and monitor the situation using Bryan's "Hub Watchdog".

[RELEASE] Hub Watchdog - Simple way to monitor if your hub is slowing down or not

*** BPTWorld apps are no longer being developed or maintained. Thanks *** Introducing 'Hub Watchdog' Simple way to monitor if your hub is slowing down or not. Features: Turns a device on/off and calculates the time it takes to happen Gives a reference to go by to see if the hub is slowing down over time Ability to notify by push, turn on a device or use Rule Machine Track data points in custom virtual device Tracks up to 40 data points (per device) with color coding Track data with graphs! V…

[mik3]

So I’ve removed all third party apps minus device watchdog and wow, things are fast!

It sort of defeats the purpose of allowing custom code....

If the apps and drivers are the fault of improper coding how can we fix this? Can Hubitat provide some best practice guide lines for developers ?

[bjcowles]

@mik3

If the apps and drivers are the fault of improper coding how can we fix this?

One of my wishes is for users suffering slowdowns to assist in troubleshooting. As an example, you now have the performance to a level you are satisfied with. Start adding those custom devices or apps back, but do it methodically. Add one, let it stew for a couple of days, and see if you notice any difference. If it's all good, add another one and see how it does. If you see performance issues, politely and privately, bring it to the attention of the developer with any logs, evidence, etc that may help with narrowing down the problem.

Just my $.02.

[j715]

On 9/26 I disabled all custom apps. The only custom drivers I had left were Logitech Harmony and Inovelli dual switch.

I also reworked my rules to break them out into short ones.

Then rebooted on 9/26.

Started running my test Rule once a day. On 9/27 the execution time was 250 ms. Each day since then it got longer. Today 10/1 it is 900 ms. Which is long enuf to keep the rule from working correctly.

So there is something in the stock stuff causing my hub to slow down.

[bobbyD]

@j715

there is something in the stock stuff causing my hub to slow down

Could you please try disabling the Harmony, also and then rerun your test?

[j715]

Ok, I rebooted. Ran test and it was back to around 200 ms.

I disabled Harmony devices. Ran test, still ok.

I will run tests over the next few days with Harmony disabled. It may be awhile as I will be gone for a few days and won't be able to till I get back.

Thanks for the response.

[mik3]

Also do a backup and a soft reset and restore on your hub

[j715]

I wrote my own app to do the same thing as my test rule. Disabled my rule, enabled app. My app runs almost 5 times faster then the RM rule. Only took 50 ms.

I will switch back and forth each day and check timing.

[bravenel]

@j715

I wrote my own app to do the same thing as my test rule. Disabled my rule, enabled app. My app runs almost 5 times faster then the RM rule. Only took 50 ms.

This is great! Just think of the overhead that RM represents. If you can write little purpose built Groovy apps to do your automations, this is a superior way to go. RM was invented because most people can't do that. Before I wrote RM, that's what I did all of the time. Someone would say in the ST community "how do I do x with y", and I would whip out a little Groovy app to do it. These are small and super fast, each about 1% or 2% the size of RM.

Here's the real kicker to this: If webCoRE had been done differently, so that instead of putting out a huge JSON file to drive an interpreter to execute a Piston, the front end Piston editor simply translated the Piston directly into a Groovy app, that would be huge. Each Piston would be a small app, and would run super fast. This would not be that difficult for someone to pull off, a Piston to Groovy translator.

Maybe this should be a project for us, to do this approach to RM. Create a rule, and then run a tool against it that spits out a small Groovy app that implements the rule. Not a small undertaking...

[jrfarrar]

[j715]

I kinda wondered about that. Over in ST I had a lot of my own Groovy apps as there was no other good way to do it. I tried WebCore but it was just not working out for me. When I came over to HE I kinda assumed RM was the way to go. And it has worked out ok for me for the most part.

I knew RM had some overhead, just didn't realize it was that much difference. But based on your comments I will probably start moving my rules over to small apps. Gives me something to do in my spare time, if I had any.

How about Simple Lighting? Is there much overhead there?

Thanks again.

[corerootedxb]

@bravenel

Maybe this should be a project for us, to do this approach to RM. Create a rule, and then run a tool against it that spits out a small Groovy app that implements the rule. Not a small undertaking...

That would be a game changer for sure.

[dan.t]

@j715

How about Simple Lighting? Is there much overhead there?

I don't think that you have the overhead here as this is an app coded directly in groovy compared to RM which is an interpreter for configurable rules.

[aaiyar]

@bravenel

This is great! Just think of the overhead that RM represents. If you can write little purpose built Groovy apps to do your automations, this is a superior way to go.

Thank you. The take-home lesson for me is that I need to learn enough Groovy to make my simplest rules into independent applications.

Scratch that: cheaper to buy a couple other HEs, and split my Rules between them ....

[dan.t]

@aaiyar

Scratch that: cheaper to buy a couple other HEs, and split my Rules between them ....

Or just wait till @bravenel completes his new "brain child":

@bravenel

Create a rule, and then run a tool against it that spits out a small Groovy app that implements the rule.

You know he will one day, his fingers started to itch once he wrote that