Hub gets very slow by day 2 after restart

🛎️ Get Help
1

I've been experience hub slowdowns since I got my hub. Been in touch with support for some time and they've been looking into it but haven't found a solution yet. I think I have a faulty hub but not 100% sure. While waiting for feedback from support, figured I'll check with the forum in case someone can help out.

My hub gets slow the day after restarting it without fail. I have a bunch of custom devices and apps listed below:
14 Z-Wave devices (all inovelli or ge light switches)
12 Zigbee devices (10 iris motion sensors with 2 peanut zigbee outlets as extenders),
4 philips hue bulbs (using hue integration)
ecobee thermostat with 2 sensors (using ecobee suite)
LG TV ([PORT] LG Smart TV Discovery 2012+)
2 Logitech Harmony hubs ([Release] Logitech Harmony Hub Driver v0.1.20200114 )
SmartThings hub (using HubConnect)
2 Chromecasts (using native Chromecast integration, beta)

3 days ago, I disabled every custom device and app except 2 Inovelli switches (which control hue bulbs) and the ABC app (which I use for the control). I then restarted the HE hub and things worked fine (like they always do right after a restart) with the switch turning on and off the hue bulbs in about 500ms.

The next day (just over 24 hours later), I tried to turn on the hue bulbs with the switch and it took 7s and 9s! Also, my devices and apps pages took about 30s to load. This was with only 2 custom devices and 2 custom ABC child apps enabled (logs are at the bottom of the post). I then restarted and had the same thing occur again. Yesterday, I finally re-enabled all my custom devices and apps and restarted. As expected, every thing became very slow by this morning.

When controlled directly from the dashboard, devices still respond relatively quickly (although noticeably slower than right after a restart). When a switch is manually pushed, it takes the hub a while to process the button press and even longer to then control the device. I'd imagine this means the hub is bugged down by something.

So to summarize, on day 2:

  1. Manually pushed switches take a while to control devices via the hub (about 10s vs 500ms normally)
  2. Hub UI is slow. Over my home network, loading devices and apps takes about 15s ... Loading dashboard takes about 20s. The logs page stays fast though
  3. Control from dashboard and alexa slows down but not as bad as manually controlled devices

I'd appreciate if anyone else that's had a similar experience and gotten it fixed can chime in. Also, if you have other suggestions on things I can try, please let me know. I really have no idea what's causing it and I'm fed up with trying to troubleshoot the hub every day for the last few weeks. I'm very close to returning to SmartThings but really want this to work out (mainly for local execution) so hoping I can figure this out.

Thanks

dev:1182020-01-21 05:54:58.831 pm infoP was turned on
dev:1162020-01-21 05:54:56.545 pm infoBen was turned on
app:302020-01-21 05:54:53.213 pm infoTurning On: [Ben, P]
app:302020-01-21 05:54:52.758 pm debugBedside Lights Switch: Button 1 was pushed
app:302020-01-21 05:54:52.722 pm debugtimeOk = true
app:302020-01-21 05:54:52.713 pm debugdaysOk = true
app:302020-01-21 05:54:52.707 pm debugmodeOk = true
dev:242020-01-21 05:54:49.844 pm infoBedside Lights Switch: Button 1 was pushed

I then decided to turn off the hue lights using Hubitat Smart Lighting and disabled the ABC app. That took 8s and 10s to turn off the hue lights.

dev:1182020-01-21 06:17:24.111 pm infoP was turned off
dev:1162020-01-21 06:17:22.449 pm infoBen was turned off
dev:242020-01-21 06:17:21.378 pm infoBedside Lights Switch: Power report received with value of 7.8 W
dev:242020-01-21 06:17:19.532 pm infoBedside Lights Switch: Power report received with value of 8.2 W
app:5142020-01-21 06:17:17.930 pm infoTurn Off Ben, P when Bedside Lights Switch button 1 held Turn Off
dev:242020-01-21 06:17:17.385 pm infoBedside Lights Switch: Power report received with value of 7.8 W
dev:242020-01-21 06:17:15.501 pm infoBedside Lights Switch: Power report received with value of 8.2 W
dev:242020-01-21 06:17:14.789 pm infoBedside Lights Switch: Button 1 was held

2

Don't know if it's your issue, but take a look at this thread where people are starting to pull Peanut plugs out of their mesh:

1 Like
3

Thanks but pretty sure that's not the issue. I only just bought the Peanut plugs last week because support said they suspected my Wemo plugs were the issue.

5

If it can be repeated, the question must be asked:
"what is it about the MakerAPI that causes that kind of slowdown?"

6

For me, it seemed to be some kind of rule and device corruption. I deleted almost everything at one point and reinstalled which made a huge difference. Also, the peanut plugs are the devil.

7

Sure, but if I can just disable it for a few minutes while the hub does its maintenance, that perfectly fine with me.

I’ll refer to this thoughtful post from Bruce today. I will say that I agree with him 100%. The things I’ve done to extend my hub and the wonderful free tools the Hubitat team has provided to create them are a blessing to me. My expansion in unorthodox ways can and does cause some issues. That’s on me. If MakerAPI really is causing this issue and they can and are able to figure it out, great. But I absolutely will not hold their feet to the fire for it. They are a small team of real people, thoughtful people, working their butts off to make this young hub the best they can, not a faceless corporation raking in money and dumping on their customers. They don’t deserve to be raked over the coals because of incompatibility issues like some on this forum are doing.

[Update]
Deleted my previous post. Hub UI slowed to a crawl at 2 am and so I disable MakerAPI. I was then able to access pages again, but around 10 minutes later, the UI was slow again. I'm calling this inconclusive. Just spent the last 30 min disabling apps, some custom, some built-in. No improvements. Around 2:30 am the hub is just generally responsive again, but I think the hub maintenance is had simply finished. I don't find evidence one way or the other to support that MakerAPI, or any app on my system is to blame or not to blame.

There are no logs to see and no app events. Logs on the Homebridge server don't show anything. Sorry guys, but I don't have anything good to share on this subject. The mystery for me continues.

3 Likes
8

Not using MakerAPI. Thanks though

1 Like
9

MakerAPI is pretty much just a simple responder/forwarder. So the real question is what is the nature of the interaction with Homebridge - Maker API? Could there be some response timeout with retry thing going on?

1 Like
10

So what’s wrong with peanut plugs now??

11

I feel ya. I pretty much accepted that I'll be rebooting the hub every 3-4 days. Vertical blue annotation lines is when i rebooted.

performancehub1_23
performancehub1_23.jpg1822Ă—578 276 KB

12

I don’t know, but if I can get you more than just the anecdotal evidence I have now, I certainly will. @dan.t might be able to help me with collection of helpful logs if there is anything to what I experienced last night, and it wasn’t just a fluke. At this point I have nothing to help anyone, one way or the other, but will do my part if there’s something to this.

13

Happy to look at the logs but I would find it very interesting if that would be the cause.

The plugin has a web server running that waits for the POST events that responds to the event right away, there is no follow up with additional queries or so.

In addition, every 5 minutes it gets the short list of device ids that are configured in the hub to see if something changed in the selection. It will only get the details for a device if there was an actual change.

Other than those two things, the plugin only talks to MakerAPi if someone took an action in the Home App.

On my dev hub, I have the regular check down to every 10 seconds and I don’t see it making in impact.

But, I would be happy if we could prove me wrong! That would give us at least on answer.

As I said, happy to take a look at your logs

1 Like
14

My advise, disable your chromecast integration and see if that makes a difference. There were several users that experienced slowdown problems with the chromecast beta

15

Thanks. I disabled that when I did the 2 days of no custom apps/drivers and still experienced huge slowdowns.

16

@bravenel and others, I get the below error every time I restart my hub from the "Hubitat Dashboard" app...

org.h2.jdbc.JdbcSQLException: Column "device_id" not found [42122-197] on line 903 (dashboardDevices2).

Wondering if phantom devices might be causing issues in my hub...

17

Also, I've done a few soft resets in the last couple of weeks and that acts like a restart for me... Makes the hub run faster for a day and slowdowns return the next day...

18

Interested in this thread as well as I am seeing similar limited uptime before substantial slowdown (my original post describing my issue was split off into Problems with hub performance after update )

No performance issues surface until a couple of days elapse.

19

For what it's worth, I'm now also getting a bunch of dashboard error messages:

app:32020-01-23 10:38:30.101 pm errororg.h2.jdbc.JdbcSQLException: Column "device_id" not found [42122-197] on line 903 (dashboardDevices2)

app:32020-01-23 10:37:50.069 pm errororg.h2.jdbc.JdbcSQLException: Column "name" not found [42122-197] on line 903 (dashboardDevices2)

app:32020-01-23 10:37:16.714 pm errororg.h2.jdbc.JdbcSQLException: Column "name" not found [42122-197] on line 903 (dashboardDevices2)

app:32020-01-23 10:36:39.109 pm errororg.h2.jdbc.JdbcSQLException: Column "name" not found [42122-197] on line 903 (dashboardDevices2)

app:32020-01-23 10:34:26.250 pm errororg.h2.jdbc.JdbcSQLException: Column "device_id" not found [42122-197] on line 909 (dashboardDevices2)

app:32020-01-23 10:32:21.612 pm errororg.h2.jdbc.JdbcSQLException: Column "device_id" not found [42122-197] on line 909 (dashboardDevices2)

app:32020-01-23 10:31:47.610 pm errororg.h2.jdbc.JdbcSQLException: Column "device_id" not found [42122-197] on line 909 (dashboardDevices2)

app:32020-01-23 10:26:57.087 pm errororg.h2.jdbc.JdbcSQLException: General error: "java.lang.NullPointerException" [50000-197] on line 909 (dashboardDevices2)

app:32020-01-23 10:25:37.110 pm errororg.h2.jdbc.JdbcSQLException: Column "device_id" not found [42122-197] on line 909 (dashboardDevices2)

app:32020-01-23 10:24:22.503 pm errororg.h2.jdbc.JdbcSQLException: Column "device_id" not found [42122-197] on line 903 (dashboardDevices2)

app:32020-01-23 10:24:10.986 pm errororg.h2.jdbc.JdbcSQLException: Column "device_id" not found [42122-197] on line 909 (dashboardDevices2)

app:32020-01-23 10:22:08.702 pm errororg.h2.jdbc.JdbcSQLException: Column "device_id" not found [42122-197] on line 903 (dashboardDevices2)

app:32020-01-23 10:21:29.639 pm errororg.h2.jdbc.JdbcSQLException: Column "name" not found [42122-197] on line 903 (dashboardDevices2)

20

These are signs of a corrupted database. It is conceivable, although we haven't seen it before, that you do have a bad flash memory in your hub. Contact me by PM about this...

21

Check this thread out starting about seven days ago.

2 Likes