You might also take a look at the logs page and let it run for a minute or two... then count the number of events your hub is processing, per minute.
I'm seeing 36 events per minute.. or 1.6 events per second. That's pretty low volume.. I'm guessing yours is above 4 per second.
Wow, your numbers sure are low!
There has to be something going on then, as clearly you are utilizing it WAY more than I am. Maybe I should start excluding devices from the Maker API and see what changes
I'd be very tempted to just toss it and make everything WiFi, but the smoke detectors and water sensors are the sticking point
Unless I'm missing something, my logs are INCREDIBLY low
I've had this up for a few mins and nothing
This is what past logs looks like
Just warnings, but given the fact a few devices in here are critical to my automations, its not reassuring
Is there a hard limit for radios being shut off that I can see how close I am to?
I can't see how WiFi makes anything better... you're still processing events.. the radio used.. ZWave, Zigbee, WiFi, BlueTooth, Matter, LoRa.... on and on.. isn't going to change the NUMBER of events. All things being equal.. and of course they never are...
You could be sending power readings 3 per second, for example..they get processed, found to be below a threshold of your automation and thus discarded... so it fools you into thinking you don't have much going on.. yet the hub is processing 3 per second.
A few points:
YEA.. that's the answer.. % of total. In 35 days you've seen 183,000 events... snooooore. 
Poor hub, it's rebelling at you. so little to do !! LOL
WiFi makes things better because its relying on redundant AP's in my house (So no single point of failure like a Z-Wave Radio) and then the information goes into HASS in a VM, which is running on an extremely powerful host with redundancy at every level
The odds of WiFi devices becoming unreachable past a device failure is super slim. Even if HASS completely takes a dump, I can restore a backup in less than 5 minutes to a new VM
I have zero automations on Hubitat. The only automations I have relying on sensors presented via hubitat are to alarm on Smoke/CO or Water
Then just the switches are part of an automation to to turn on with light levels (Light level is all in HASS, not Hubitat)
Even if Hubitat were perfect, I really, really, really don't like relying on a hardware device. Without having a spare on-site, it would be a nightmare if the hub failed and I was doing all my automation on it. With my HASS setup, the device cannot fail as its protected by vSphere HA
I'm 100% happy with the Home Assitant HomeKit integration, so no need to even look at the Hubitat one. I'm also now using devices that can't be added easily into Hubitat, so it would be a step backwards
I'm not using the HomeBridge app in Hubitat anymore, just the maker API to get it into HASS
I'd love to move them to HASS directly, but since I'm running HASS in a VM, its kind of a pain to get radios in. I was very happy getting Hubitat to feed into HASS for a radio, best of all worlds IMO
So do you think there is something up with the hub in that case?
Doubtful.. certainly the Apps side is pleasingly low...
Can you do the same for that Device Stats tab??
What those stats don’t show is the amount of TCP traffic. If you are using a heavy load of TCP calls and have a lot of waits/delays in responses it will inflate your hub load numbers.
Looks minimal to me, but I have no reference for another Hubitat
The green bars is when I started messing around in the UI
Can't get one for just TCP, sadly
Just curious to know if you are using jason0x43's hacs-hubitat integration to link Hubitat to HA? I have 330 devices connected to HA and my MakerAPI stats are significantly lower.
Yep, the exact same one...
Something must be wrong with my hub, or a device I suppose
I would suspect a device over the hub. With only 17 devices I would start diagnosing this using logbook in HA to see if you can determine which device is causing the issue. If that doesn't shed any light on the issue you could start excluding devices from MakerAPI one at a time to see if you can find the bad actor.
I'd suggest a similar "shed devices to find the bad actor" but use a binary search method... disable half your devices going to Hubitat. Wait a unit of time to allow the Alert to clear. If nothing, Enable them all and disable the other half.
You repeat that "disable half" (of what's left) to narrow down to the bad actor.
You start with 17 devices and disable 8... and get a yes/no answer. If yes, enable 4... and get a yes/no answer. If yes, enable 2 (of the 4) and get a yes/no answer. That gets you down to 2 devices in 3 tests. In any test, a No means "flip the test".
I can say from experience it doesn't take much to kill a hub with maker API if a integrated device sends back to many commands from a external system. Sometimes you won't even see it if the hub has the local device already set that way.
What you have to remeber is that there is allot more tcp overhead then just sending the data. It may have to open a connection which involves handshakes and such as well. Then maker api has to process it to get the commands to the rest of the system. I think what csteel is suggesting is a great idea.
Have we isolated this issue to only being when Maker API is running with those devices integrated? If not you may want to start there by disabling it completely first.
Download the Hubitat app
