@wienog Did you ever list out the exact model numbers for Bryan? He is the Zwave guru for Hubitat, and can possibly fix the problem if he knows what model devices are failing here.
They also might be able to look at the internal hub logs and see if something sticks out, so if Bryan asks for your hub ID, be sure to get it to him.
I have a theory, since I don't own any expertise. I'm thinking the particular combination of different zigbee/zwave devices can have a big influence on performance, even outside of energy reporting or chatty devices.
I'd be curious to see a list of the devices you guy's have, to see how different it is to mine.
Hard to get a screenshot. But I can tell you the events that changed my hubs from being rebooted daily to almost never reboot:
Zigbee hub (C-5):
Zwave hub (C-5 at the time, lated migrated to a C-7):
Also, FWIW, I had at one point of time moved all my automations off the hub. I have since deliberately added a substantial amount back on a temporary basis to see if they were any faster if I eliminated processing elsewhere on the LAN. When I added them back, I rewrote rules to be more efficient (largely eliminating use of the *changed* trigger).
I don't see why HE can't use the 32 bit version since the base os is a linux variant???
Zigbee2MQTT is easy to setup, since your already running a linux system, IIRC. It runs on node. Plus it supports a much larger pool of Zigbee devices and if you find a device that is not supports there is a procedure for getting support added.
I recommend getting the Sonoff dongle.
I could be wrong, but perhaps the base OS distribution for the C-4 is 64-bit. Whereas for the more recent models, it is 32-bit. And the JVM comes with the base OS.
I actually run a precompiled 32-bit application (i.e. a binary) in my 64-bit SBC, and setting it up was a PITA.
Seems backwards but very likely. 64-bit --> 32-bit
JVM on the C3/C4 was 64 bit, C5 and C7 have the 32 bit JVM.
I know we are getting way off topic but had to mention - why yes I DO happen to have a Sonoff ZB3 dongle sitting around. Thanks! 
Yes.
Yes, I moved all my Xiaomi devices (~80) to z2m in 2020. I bring them into Hubitat as virtual devices.
But I do have other zigbee devices on Hubitat; including ones that work very poorly on z2m (for eg. z2m doesn't support the SmartThings Arrival Sensor V4 very well, and doesn't support the V2 at all).
@Rxich
I'm using Node-RED for all my automations - this has eliminated the need for most HE apps.
My C5 Network hub seems to be rapidly declining in free memory but I am attributing that to custom drivers specifically the Flume driver at the moment.
I have a bunch of different devices (both old and new) including:
So we got switched to our own topic which is appropriate. Apologies to @paul4 for further derailing things..
In terms of hub performance, I have not had any of the "performance" based issues that many of you have had. In my installations for others, I have also not had any performance issues.
Like many of you, I tinker a lot with my own personal installation, and I try many things out personally, that I would never use at a client's site. I expect there to be issues with those things - that's why I try them out (usually) on a separate hub.
There are many drivers out there, and they are not all written well.
There are many incredibly usefull apps out there, that can kill you hub.
There are many ways to specify preferences that can destroy your hub.
(Just one example that we all know of is frequency of power reporting.)
However, for the overwhelming majority of people who just want something that works (and who don't need to upgrade their system every other month), Hubitat is just fine.
I do the same.. my home is my "dev" site well maybe "beta" site I do have to keep the family somewhat mollified. I have separate servers to test the latest stuff / apps etc but usually those get quickly incorporated into my home system to see how they function in the "real world". Also there is the basement which usually is "safe" from family HA angst but large enough for adequate testing.
For my clients and my sanity I absolutely try and keep things as close to a known baseline setup as possible with an emphasis on Hub resource reduction and ease of maintenance.
I frequently recommend a multi-hub configuration especially for "difficult" properties - older homes/signal unfriendly construction materials/expansive or weird layouts/large deployment of smart devices etc. Even though I know a single hub could theoretically work I've found the routing and management to be much improved..
Having read the first and last comment on this thread, I have obviously done extensive research... 
And the main comment I would add is that HA in general is a work in progress.... IMHO.... And a small number of (major) org's are approaching it from different angles.... some like Hubitat are approaching it from the angle of satisfying the developers who then supplement the offering to round out the experience for the general consumers here on the Community.
So for me, Hub performance atm...? The cost of a new HE hub is cheap enough when on special that you can take advantage of the savings to invest in the extra capacity, but only if you need it. I use my 3 hubs to split out my lighting, local and cloud integrations, with an additional HE hub for development / testing of devices and integrations.
The potential issue with that is custom apps & device drivers can cause their own problems and customer frustrations who might end up blaming the hub / company when they can't get proper support. I've seen this in a few threads..
Also Hubitat, Inc seems to be increasingly reliant on this awesome community as the first line of support. I don't think this is necessarily a bad strategy of course just not sure it's sustainable if things (member goodwill etc) take a turn.
It does feel like dev's need to form an (unnecessary) pact that we will support the continued performance of the HE hub... By unnecessary I mean, if you are going to write a piece of code, why wouldn't you not want it to perform well.....? Granted, my code may not perform well straight away, but I try to respond (work and other interests permitting) to get them working as they should....
I appreciate the sentiment but that will never work given the "open" nature of the development (NOT the underlying system of course!). You want people to freely tinker as they see fit.
Maybe Hubitat could have some sort of app/driver vetting process for an "approved for HE" ratings system.
On the community level thanks to the popularity maybe HPM could implement something like that as well.
Yeah, as much as I might stand on my soap-box, I know that part of the appeal of HE and this Community is the flexibility of its discourse and the exchange of code. While it is tempting to request approval from he HE Gods for the code we write, I know mine is often substandard compared to commercial standards, so would understand if it was rejected. With that in mind, I could appreciate (well not really... ) the time it would take to review each addition and approve (or not),
I guess where I was heading was an indication for users on the stability of the code. That said, the more I am pushed, the more I think the performance of any drivers / apps is largely driven by many external factors, just like enterprise apps many here tend to day-to-day....
This is a black hole we intend never to get near.
Yes I realize this... 
Download the Hubitat app
