Slow issue fixed?

I used to keep logs open all the time but I got impatient when it would take too long to switch from "all" to some specific device, and back again. So I started using Previous Logs in it's own tab far more often.

Same here. When I keep logs open it seems to chew up memory in my browser and brings that tab to a crawl. Closing the tab and opening a new logs tab fixes. However, this does not have any impact on my hub. Its just the browser on my pc.

I also have a tablet running dashboards 24/7 with no issues.

Ahh yes, an important distinction... same here.

Since Dashboard's driven by the same Event Socket mechanism I'm using 24x7 for HubConnect, I have no fear of leaving it on always, even though I look at it only about once a week.

@yannick00000 @guywmartin
I've been dealing with these 2-3 day slowdowns for almost a year now. It doesn't seem to matter how many devices, dashboards, rm rules, sl rules, etc. Like clock work every 2-3 days i need to reboot. It was happening with only a few rules and devices to now with lots of rules and 150 devices. Funny thing is this has only ever effected rm, while my rm rules slow to crawl, all of my sl rules are still lighting quick. None of my RM rules are crazy either. After 2-3 days it takes forever to do anything in rm as well. Device control from the device page remains fine, all events are fine as well. I contacted Bobby over 6 months ago to go over this and present my findings about rm. It was basically brushed off as no one else had this problem with rm so it's not that. I just applied the latest update so well see how the next few days go.

@AutoM8
I use a mix of Simple Lighting, Motion Lighting and Rule Machine depending on the room. When the hub slows down, all 3 types react the same for me, trigger from the motion sensor (visual led on the device)... delay ... light will turn on. Usually this is quite noticeable (and frustrating) with motion automation but since the update (and maybe more affected since I'm not rebooting so often) I've noticed the delay with contact sensors as well. Usually, contact sensors (Dome) are lightning fast.

1 Like

Could a persistent Event Socket connection be the root cause, though? Like due to a memory leak or something? I do all my automation in a custom thing I built (think like Node-Red) and I'm getting all my events from the Event Socket.

Maybe it's time for me to look at using the Maker API web hook to get the events instead.

just upgraded to 2.1.9.115. Slower than ever. Unusable even. Do you guys do any testing or you're just testing on us?

1 Like

Yes, they do testing.

Then Beta Testers test.

1 Like

My hub also started to slow down again tonight. I'm on the latest update and it seems I have to reboot about once a week before and now after the update.

In troubleshooting with support, I've:

  • disabled the "use all devices" for each of my dashboards
  • Made sure any dashboards used locally are using the local url, not the cloud url
  • Disabled the Chromecast app
  • Disabled all Chromecast devices

Pretty much the same things happen each time it starts to slow down:

  1. I notice that z-wave motion sensors trigger and then lights controlled by both z-wave switches and Lutron switches take a second to turn on (they are normally almost instant)
  2. Later in the evening, when my hub watchdog app runs, I'll get a notification the the ZigBee device I monitor took >1 sec to activate
  3. I will then also get a notification that the virtual device took > 1 sec to activate.

So z-wave and Lutron devices are noticably slow and hub watchdog reports the ZigBee and virtual device are slow. Everything just starts to bog down.

Both of my Z-Radio Hubs are on v2.1.9.114 and I just ran one of my trivial tests...

Pico button to turn OFF then turn ON the light in this room.

dev:838 2020-02-27 08:14:22.556 pm info Office WallSwitch was turned on [digital]
app:805 2020-02-27 08:14:22.190 pm info Turning On: [Office WallSwitch]
dev:766 2020-02-27 08:14:22.081 pm info Office Pico button 1 was pushed
dev:774 2020-02-27 08:14:22.021 pm info rcvd: DEVICE,2,2,4
dev:774 2020-02-27 08:14:21.800 pm info rcvd: DEVICE,2,2,3
dev:838 2020-02-27 08:14:20.570 pm info Office WallSwitch was turned off [digital]
app:805 2020-02-27 08:14:20.185 pm info Turning Off: [Office WallSwitch]
dev:766 2020-02-27 08:14:20.073 pm info Office Pico button 5 was pushed
dev:774 2020-02-27 08:14:20.022 pm info rcvd: DEVICE,2,4,4
dev:774 2020-02-27 08:14:19.793 pm info rcvd: DEVICE,2,4,3

Roughly 700ms to OFF and roughly the same for ON from PUSH. From RELEASE, about 500ms.

Exactly 6 days since I booted to 2.1.9.114

I'll upgrade to 2.1.9.115 and rerun the test and update this...

UPDATE:

dev:838 2020-02-27 08:34:19.147 pm info Office WallSwitch was turned on [digital]
app:805 2020-02-27 08:34:18.760 pm info Turning On: [Office WallSwitch]
dev:766 2020-02-27 08:34:18.602 pm info Office Pico button 1 was pushed
dev:774 2020-02-27 08:34:18.561 pm info rcvd: DEVICE,2,2,4
dev:774 2020-02-27 08:34:18.406 pm info rcvd: DEVICE,2,2,3
dev:838 2020-02-27 08:34:16.112 pm info Office WallSwitch was turned off [digital]
app:805 2020-02-27 08:34:15.727 pm info Turning Off: [Office WallSwitch]
dev:766 2020-02-27 08:34:15.519 pm info Office Pico button 5 was pushed
dev:774 2020-02-27 08:34:15.454 pm info rcvd: DEVICE,2,4,4
dev:774 2020-02-27 08:34:15.226 pm info rcvd: DEVICE,2,4,3

After booting to the latest, and waiting 5 mins for the internal processes to settle down, the numbers are:

900ms and 700ms, roughly from PUSH. From RELEASE, about 650ms

So.. rebooting didn't make it faster after 6 days of uptime.

Oh, didn't realize there was a HotFix today. I'm on .114. I'll update to .115 but based on the release notes, doesn't look like anything in there that would potentially address slow down.

I was at 1.5 sec for a ZigBee device and 1.3 sec for a virtual switch.

My hubs have been faster than ever. I wish I knew what it was I did that fixed mine. It may have been many things together. I haven’t seen any slowdown with the latest updates, actually quite the opposite.

Wow, your times are very speedy! I wish you knew what you did as well!!

2 Likes

I guess I do know a couple things that helped for my environment, but may not be applicable to others. I moved Hue integration to the second hub with Alexa on the first; Deleted and rewrote most rules and put on second hub with all button controllers and other end devices; moved echo speaks to my SmartThings hub; removed all peanut plugs; installed HubConnect 2 and have devices routed through a proxy server.

1 Like

I guess we know what he did LOL Nothing like subtracting half the load to make a difference. :smiley: :smiley:

2 Likes

How many of you use GV's with connectors?

I'm not using any global variables or connectors. I do use the hue integration though.

@frits
I use 21 GV / 10 connectors

To be fair, slowdowns were happening when I had half as many devices, and I see people on here with 35 devices complaining about slowdowns. I’m at 284 devices now (went a little overboard after HC2) and my automations have never been so fast. I do think that much of my particular problem was fixed when I deleted most rules and many devices from my original hub. That is when my hub responsiveness became immediately faster. And before you say “well duh”, It still left around 100 devices and 15 rules, as well as the HubConnect server, Alexa integration , and dashboards on my original hub. I just deleted ML and all button controller rules

No GVs