Hubitat experiencing severe performance issues since I migrated webCORE setup

#1

So, I recently migrated my webCORE set up from ST to Hubitat. The process proved to be quite a pain. I had first migrated all my automations to webCORE in order to help facilitate the migration process, but I still ran into numerous issues.

In the end I migrated about 70 pistons and about 150 devices (physical & virtual). I have worked out all the compatibility issues & errors I saw in the logs, but now I am running into some performance issues with Hubitat.

After rebooting, Hubitat will perform decently for a period of time. But as time goes on, Hubitat will respond slower and slower, to the point of becoming unusable. Eventually, the Zigbee radio will give out requiring a reboot.
It seems that my Hubitat’s resources are getting maxed out, I guess this would explain the Zigbee radio drop.
In response, I have optimized most of my pistons. I also noticed that disabling recovery improved performance, at a cost.

So my questions are, is this common? Is there a work around?

This is getting to be a bit frustrating. I moved to this platform expecting faster performance and consistency due to local processing. But right now, this setup is so much worst than ST, it makes me long for the days when a piston would execute within 5 seconds.

#2

what version of Hubitat firmware are you running?

The later HE versions have a couple of updates:

  • they have improved JVM settings
  • They reduce the number of events kept in the DB (the DB is a big consumer of JVM space if it is big)

When you do a backup, what is the size of the backup file (this is an indicator or DB size)

I assume you are running latest webcore on HE?

#3

I am on the latest HE version.

For webCORE, it looks like I am a bit behind, running v0.3.110.20200702_HE instead of v0.3.110.20200716_HE. I’ll update now.

Back up size is at 417KB.

#4

Your HE backup is 417KB? are you sure? that sounds really small.

After you update to latest webcore, and let your hub settle a few minutes, reboot your HE Hub (HE console -> settings -> reboot), and then lets let it run for a while (without installing new apps if you can). You can edit pistons, etc, I’m just asking to not update or add new apps either manually or via Hubitat Package manager.

#5

My bad, 417kb was for backing up my pistons in webCORE.
HE backup is at 2,736KB.

#6

ok makes sense

What type of hub do you have C4, C5, C7?

#7

C4, took me a very long time to decide to pull the trigger on migrating.

#8

Well thank you, It appears that updating webCORE did the trick. The hub is no longer bogged down, pistons are triggering in a timely fashion and The Zigbee radio hasn’t gone down.
Thanks again, I now feel much better about spending all that time migrating.

#9

Good to hear. HE folks have been spending a lot of time dealing with some of their performance/hang issues in the platform in recent releases (this has nothing to do with webcore). They have made good improvements - they may not be done (sort of peeling an onion), but JVM, heap, and other optimizations are very much improved.

webCoRE on HE over the last year has dramatically reduced its resource consumption on HE and improved performance. I’m still seeing simple pistons execute in < 15ms once the system ‘warms up’ and the jvm hotspot does its thing (which is good as ST takes > 100ms for the same thing)

#10

Cool, I look forward to having a more consistent experience than with ST.
I forgot to ask, is there a recommended interval for running recovery?

#11

It is up to you. I find it is not used anywhere near as much as on ST. Typically this can be an issue if you shutdown for a while (power outage), or you hub is having other problems.

It really is not much overhead on the frequency. I think mine is set every 30 mins, but 15 is fine too.

#12

understood, thanks.