Slow issue fixed?

Database corruption is way to easy to happen on this platform. Rules should not be so fragile where any change could have undesirable affects down the road. If removing a device breaks rules, then just prevent the ability to remove that device until the device is removed from all automation's. With so many changes that can be altered in a rule trying to figure out which rule or automation is causing the slowdowns without any useful info from the logs is very difficult

2 Likes

I understand that Hubitat uses the Java H2 database. I was looking at the H2 database website a few days ago and noticed it supports multiple connection modes. Embedded mode seems to be faster, but more susceptible to corruption unless applications are well-behaved. Server mode is apparently slower but seems more robust. I wonder which mode is used in Hubitat.

7 Likes

Interesting, that could explain some issues depending what mode is used. Some more insight into this from the HE team would be appreciated.

3 Likes

Hey I just noticed this today on some of my devices. It seemed really weird. Is it possible something got corrupted?

1 Like

Well I am convinced that we have some kind of memory leak. I went from one hub to three and a Raspberry PI, using HubConnect, thinking that it would solve my slow downs by spreading out the load. It did not. The slow downs still occur, they just occur every 8 days or so now where before they were occurring every 3 days.

Hubitat Staff has publicly acknowledged that they have been trying to track down some sort of resource leak style of issue. They have also mentioned that it has not been easy to track down.

Update: Here is the post I was thinking of

3 Likes

Are they occurring on all three hubs? Simultaneously?

Because, as I'm sure you know, I have 3 hubs and a Raspberry PI, using HubConnect, As well as a connection to SmartThings and another to Homebridge.

Adding Zniffer has allowed me to see an 'overview of my ZWave network, which dominates my home, and I can see a problem or two. Yet nothing is systemic and need of an immediate fix. I have introduced a 4th Hub to split again, specifically 'front of house' instead of only 'upstairs' and 'downstairs'.

1 Like

Well, I don't know for sure. I have devices paired to two of the hubs and rules and cloud devices paired to the other. When I notice that it takes a motion rule to turn on a light several seconds, I have just been rebooting all of them. That usually occurs every 8 days or so. Next time I will reboot only the hub that the devices are paired to and see if there is an improvement and if not reboot the rule cloud hub. That should tell us. I just haven't thought to do that yet.

1 Like

In my mind I've invented a construct for deciding where one specific device will live... I call it "cause-and-effect'. It suggests to me that the Effect I want, light on, alert, Garage Door Open or Close, Fan On or Off, etc. have a Cause.. Motion sensor, Door Sensor, Temperature with '-and-' being the Rule or App that ties them together.

I choose to place "Cause", "And", and "Effect" on the same hub. Exceptions are.. Internet facing Apps (Dashboard, Alexa Echo, Mode Manager, etc.) and Devices (like Weather, Lux, etc.) are all on my Hub with HubConnect Server. Since my Server hub has no Z-Devices, only "Cause" and "And" are on Server hub. "Effect" still live on the Z-Devices hubs.

In this model, during the cycle of Platform upgrades, when I reboot Server, nothing really bad happens. I went this way from the dim and distance past where I assumed all the slowdowns would be due to internet facing interactions. If that Hub 'hung' waiting for some weather site to respond, the Kitchen wouldn't be affected at all.

Like always, I have no belief that my way is somehow better.. :smiley:

3 Likes

There was some possible issue that @bcopeland was kicking around something about shared memory as related to drivers... he ran into it when working on one of his projects. Dunno if that has any relevance but thought it was worth bringing up. Maybe nothing.

On the hub side - main hub all good / upstairs hub improving. After a soft-reset on my upstairs hub and moving all my rules to NR + removing most apps things seem to be calming down. No reboots for last couple of days on any hub. Hubs appear to be responding as they should. :crossed_fingers:

2 Likes

I'm convinced that a possible part of the problem is the procedures/process that Hubitat uses for zwave repair.
If you ran a number of consecutive zwave repairs, you would find that your zwave automations slow to a crawl. It should not have that effect.

It's been many years since my Z80 class, but in technical terms, that's bad.

In my case, every time I have run a z-wave repair, my z-wave network gets all messed up until I reboot my hub. So I never run a z-wave repair anymore, ever.

If I need to I reboot before and after!

You need to reboot after.
So, make yourself a RM that will run a repair (if the virtual flag is on) and then restart. Do it at some time in the middle of the night.

This is interesting. I wonder how long it will go without a reboot or soft-restore.

Short answer - rebooted last night at 2 am... :rage:

The apps installed are

  • groups & scenes
  • Lutron Integrator
  • Maker API
  • Rootin Tootin Self-Rebootin

Rule Machine with 2 simple rules - both just set a virtual switch one on reboot and the other for the Rootin Tootin app..

I did recently remove some older GE Zwave fan toggles from the bathroom and replaced them with newer GE Enbrighten ones. I did not use the Zooz which I have everywhere else due to their recommendations.

I suspect I have 2 ghost devices that are not clearing. I have not yet included my Z-Stick on that hub to find out though.

Another thought is it could be the Rootin Tootin app - I have an older version running so maybe its a little more trigger happy. Anecdotally it is working well with my main hub - still running, no reboots, no ghosts.

Not really witnessing slowdown on the upstairs hub until the reboot.. it may be the repair crapping out on the ghosts? Is that possible?

2am is when the hub starts its self-maintenance. Hopefully the Rootn-Tootn app is aware of this and avoids rebooting the hub during this maintenance window. If not, I would suspect the app as being a little too trigger-happy.

Note: I have not used this app, nor looked at its code. Just a thought... :thinking:

1 Like

I'm not positive on this but I have a vague (maybe false) memory of the original/older version of the app did not take into account the 2am maintenace?

Normally I would agree but I have the exact same version (it's not the original release version) running happily on my main hub.. no reboots there. I really need to check out whats going on on that network.

I believe this may have been asked in a prior thread but do you know how to unpair a secondary controller (Z-Stick) using the PC Controller 5 software? Currently it's included on my main hub and would like to exclude it and pair it with the upstairs hub..

I guess the real question is how to put the Z-Stick into exclusion mode using the Controller software. NWE?