Fastest my hub has ever been

Do you mean "2.2.3.135", "2.2.3.132", "2.2.3.119" or "2.2.3.118"?

:wink:

1 Like

Unfortunately, as you figured out,dashboard relies on network connectivity, which the hub looses when it goes berserk, but in most cases zigbee/z-wave can still work. Z-wave seems more stable, as I read zigbee is the first to go when the hub is overloaded(or whatever causes these lockup issues)

1 Like

My Zigbee has been fine throughout all these issues...only Z-Wave crashes. Motion sensors and buttons react/send messages, Z-Wave devices are out to lunch.

1 Like

I waited until 132 to update, and am now on 135.

2 Likes

.135 has been the worst for me.

Other C5 users have reported problems w/2.2.3. So C4 maybe no surprise either.

2 Likes

I have had good luck with the latest .135 release.

That said, I have my hub set to purge to 15 events per attribute (vs 100 default).

you can change this if you like on your hub, I think the endpoint is:

http://hup-ip/hub/advanced/event/limit (to see limit)
http://hub-ip/hub/advanced/event/limit/15 (to set it to 15).

If you change it, you likely want to:
http://hup-ip/hub/cleanupDatabase

wait a few mins, then reboot your hub (he console -> settings -> reboot)

I expect what may be happening

  • purging the db makes the DB smaller (and it uses less memory)

    • if you follow procedure to cleanup, wait a few mins, then reboot
  • the latest version of firmware further tries to improve performance by caching some DB in memory (uses more memory).

If you run really low on memory - you get hang, un-responsive, etc.

Just my theory (and some of my experience running C4, C5, and C7 hubs)

5 Likes

100 is default? I have 1000 on 2.2.2.129

1000 is so 2.2.2
I have mine set to 10

4 Likes

Which is why, when you do upgrade, you'll see your overnight DB backup drop significantly.

You can individually set the retention count... make everything 100 and that ONE device, go ahead and make it 250 or 556.

Screen Shot 2020-08-27 at 7.24.56 PM

1 Like

Just bizarro that the default lowered on 2.2.3 yet it’s slower on my end. Guess I’ll open a case :frowning:

I'm on a c5 and it's been 3 days now since I upgraded to 3.132 and now 3.135. I turned off my rebooter app and the UI and all devices have been responding as fast as before if not faster.

I was rebooting my hub every night before because of the slow downs. I know it's been hit or miss for a lot of people but the update and treated me well. Thank you HE team!

1 Like

I must not be understanding your comment.. The size of the 'retention depth' has nothing to do with 'speed' directly. If you are getting 100 events per second with a depth of 1000, it will fill in 10 seconds. With a depth of 100, it will fill in 1 second. But 100 per second is what's impacting speed, not depth. Conversely, if you get 1 event per month for a specific device, a depth of 1000 is absurd, who needs 83 years of retention? There's an indirect relationship to speed when 'scanning' the table, like when you open a Dashboard and fetch the History.

There's also the time it takes to prep the backup... which is once again, 'scanning' the tables. 1000 depth equals longer than 100.

So... you understand why I think I am misunderstanding your post. :smiley:

1 Like

I ran on a higher version for several days and everything was slow(er) than before, even after the item defaults were lowered. Just saying I’d expect the opposite given that the database went from 35mb to 4. And I’d expect a larger database to use more memory.

That's one of the parameters that's being 'balanced' I believe.

I think what's important to understand is that none of the most recent 'set' of releases is exactly the same as the previous, in this regard. Thus the variation in how it's working for the set of users, or tester in the case of Beta.

Everyone wants the balance to be better for them. But people have been saying for years it's difficult to do... I've heard a dart board is a valuable tool for picking values. :smiley:

the smaller db helps

recent releases try to cache more db which means cache uses memory. So it may be smaller db size has not offset larger cache size.

you might try keeping on 10 or 15 items and see if that changes things

Mind if I poke around the logs on your hub?

I don't know if it is a placebo effect or just perception, but after reading Victors post, I closed all the different browsers that I left on dashboards. I had multiple PCs and tablets logged into my HE dashboards. I was experiencing what felt like a problem with my C5. I don't have any of the logging or charting apps used in this thread so I have no hard data to back this up. I am still running 2.2.2.129. I may upgrade this weekend.

Please do. Let me know if you want me to upgrade so you could look at before and after.

Looks like my hubs are back to being at least as fast as they were on 2.2.3.119

Still experiencing those spikes as you can see, and the latency between the spikes isn't that great. Hoping that next release improves. As far as my automation's they are working well enough, but there is still some delay that was not present before the 2.2.3 versions.