You need to consider hub location and distribution of devices and repeaters. I actually had a second zwave mesh at some point and my performance was poor.
As I said, the slowdowns on the radio hubs are rare. Compare it to number of bluescreens on Windows XP vs. bluescreens on Windows 95. My radio hubs are way more on the XP side and I don't really have a problem as there are more firmware updates out than my slowdowns on these hubs occur.
My Hue is on a managed (lite version) switch. That’s where I believe my problem is. I’m thinking of moving the Hue to the main router where the HE is.
Why would you think it is the managed hub? Is it a switch or truly a hub? Good quality one or lower grade?
LJ
But you really don't know that. You can't. We don't have access to the hub to know how the radios are interacting with the rest of the firmware. You have great confidence in that, but you can't be sure since we don't have any way of investigating it.
And as far as having multiple meshes....I would think that you would break it out by region of the house. If you have enough devices to justify having 3 hubs you must have a large enough house where you could break it into two halves, one for each "device" hub.
But then again, like Bruce, I'm a member of the "One Hub is Enough" club. I think we might be the only two members left at this point. 
That said, I do have a Caseta Pro and DIY ZLL/Problematic ZHA device hub for segregation (see DIYHue if you're interested. supports wifi, zll, and zha devices). So, I do split device control up someone by necessity. It's always been my thinking though that having an app to update a virtual device and updating a real device is pretty much a "6 of one, half dozen of the other" situation. And if you have an app that's problematic, figure out another way to do what you want and ditch the app.
First what app prepared those graphs?
I also suspect database performance, database corruption or radio usage. Again tools would be helpful to diagnose these.
Along those lines, I believe I read somewhere that someone had some success backing up the database, resetting the Hubitat, and reloading. Has anyone tried that. I need to go back and look in this thread as I likely read it here. It seems extreme to try this and I don't understand what this does to the radio associations data. Is that backed up as part of the hub backup. It should be but I would want to be sure of that before trying it.
LJ
Like I said, I had to do a soft reset last night. That consists of backing up, soft resetting and then restoring the backup.
1 Like
I have the exact setup except my C5 is my coordinator and C4s are for Zigbee and Zwave. The only hub I have had consistent slow downs is my coordinator. I personally suspect LAN and telnet apps as cause of slowdowns. I have NodeRes downloading nightly backups and after 5 day’s coordinator times out prompting me to reboot.
I've long wondered about this too. Telnet is an "always open" connection rather than on-demand.
Why would there be telnet sessions open???
LJ
Yes, it is based on experience and I can't prove it based on the evidence to make a scientific claim out of it. Neither does your approach though.
My house is not as big as you might think but I have a pretty robust setup right now that I am happy with AND my wife doesn't complain about. And as Bruce rightfully said last Hubitat Live episode, WAF is what we aim for.
The most important statement of my original post was:
I showed my additional data and statements as a backup to my statement. It was surely not meant as a complaint or concern for something to fix.
1 Like
I have several:
Lutron Caseta Pro Hub
Denon Receiver
Onkyo Receiver
UPS integration
First three are stock drivers and last is a custom driver.
Didn't know those use telnet.
I have a yamaha receiver. Is that telnet?
What UPS are you integrating? and Why? Let's not hijack this but I would be interested in knowing. You can private message me.
LJ
To get power notifications. It’s actually via my NAS. You can read about that here:
1 Like
I use Node-Red that listens to the eventsocket and posts the data to an Influx database and use Grafana for the graphing. You can find more here:
Yes, I have done that and yes, it appear to have an felt impact. I have no data to back that statement up so take it with a grain of salt. In addition, it is usually a temporary measure like a reboot.
2 Likes
Okay...So, are you saying that moving to multiple hub and segregating devices by radio is the answer then?
Then likely not worth effort.
Thanks,
LJ
I can definitely say that it made a HUGE impact in my setup and in my environment . Prior to separating, I would have never thought of running the automations that I am running now. And my WAF increased significantly.
BUT, as in bold above, this is my environment and in my setup
I can agree with this 100%. This is more or less what I ended up doing too - instead of buying more Hubitats, I just moved all Z-wave to HS and kept Zigbee on Hubitat. Never been happier with the results.
IMO, there's a critical limit to how many devices/integrations/apps etc. that Hubitat can handle smoothly. It's not very clear what this limit is, but as a general rule of thumb, if you're on this thread complaining you probably have hit this limit and you have two options: buy more hubs or offload half of the functionality to an external box.
Totally understand. More info is more data and more data is always good. Especially with something as wacky as the slowdowns seem to be. Who knows what little nugget might lead to a Eureka moment, right? How many devices do you have on each (z-wave/zigbee) approximately?
Zwave: around 30 or so
Zigbee: around 50 or so
More Lutron devices and hue bulbs but those are connected to the coordinator hub
And just to show how happy I am with my current setup, I use Motion Lightning where my motion sensors are on my Zigbee hub, connected via HubConnect to my Coordinator hub that talks to my Hue bridge to turn on my Hue bulbs and usually have the lights turned on in around 200 ms - 300ms!
