Have you noticed any actual problems with your current setup (e.g., high hub load--a new warning that hub firmware 2.2.5 will show you, or you can also view app and device stats on the Logs page now to see if anything looks historically high)? If not, adding another hub probably won't hurt, but you might not get any benefit from it, either. You are also likely to get little benefit if you move those devices to the other hub then share them back to your "main" hub via Hub Mesh anyway--all the events are still going to be pushed there (though getting some on your LAN and off of Z-Wave like the HEM might be better), so you'll get events--and database entries--and whatnot regardless. But if you could move certain rules to that hub--to truly offload some processing from your current hub--then maybe. (Also note that if you don't need devices from one hub on the other hub, then you could simply keep both hubs entirely independent with no need for Hub Mesh at all.)
But if there's no problem to solve in the first place, the end result may not really be different.
When I got my first hub I focused on moving all my zwave/zigbee/wifi device from ST to Hubitat. Totally impressed with the speed everything was working. Zero lag or at least not measurable.
Recently I started adding these reporting devices and I have definitely noticed a slow down. Where once a light came on immediately when the door opened now there often is a lag. I am blaming this on the newly added reporting devices.
Running each hub independently may be an option however some of these devices such as temperature may need to trigger an action on a device on another hub. I kind of do this now with some devices still on ST using oAuth enabled apps but it gets messy and hard to maintain.
If you're on 2.2.5, check the "Logs" page. There are app and driver runtime stats now. (If you're on an older version, consider upgrading unless you're opposed to doing so if you don't really need to, in which case I think 2.2.3 had the most significant performance improvements for me recently, so I'd still recommend it if you're on 2.2.2.) If any stats seem "high," either in total time or average runtime, there may be an issue--or not, as it's normal for certain devices to be high (e.g., my Lutron Telnet device has a high total runtime because of all my motion sensors that frequently send events that get parsed through this driver, so I'm not worried about it--and the average runtime in each instance is still pretty low). Just one diagnostic you can use to narrow things down a bit and make a better guess as to what may help.
hey man, i have the latest version, i didin't see any warning about high load but i definitely have a high load,i mean what else? my mesh is fine.
i have over 60 devices and some of them are chatty and got stuck with some bugged ones that i can't disable their spammy energy reports.
So i am considering adding a second hub to split devices between them.
Sometimes everything is snappy and reacts in a second, sometimes it takes 5-10 seconds which is frustrating especially after i optimized all of my sensors to send at little reports as possibile and 60 devices don't seem that much to be honest.
Why i am not getting this high load warning since i clearly have one?
If I had to guess, my guess is the same as yours: moving the unavoidably-chatty energy monitor to another hub might help (a better chance of it helping if you don't turn around and share it back via Hub Mesh to your "main" hub, but even then your LAN should be faster than Z-Wave and eliminate that bottleneck; best if you can share whatever other devices you need to this hub and write apps/rules for the energy monitor there, I'd say). But I do agree that 60 devices isn't a lot, at least not if they aren't super-chatty. If they are, there is minimal periodic maintenance (I think this recently became every hour?) and the bigger overnight maintenance (by default around 2 AM, now user-configurable), and at least the latter spends some time cleaning up device events beyond the max event history limit, so with a really chatty device, I could see things like that being an occasional concern.
Other than that, you aren't getting the "high load" warning since the thresholds staff set for that weren't met. This is for the hub's resources as a whole, as far as I know, so just a bogged down Z-Wave network, for example, isn't likely to cause one--and my understanding is that it would generally be a severe enough event that you'd want to consider a hub reboot. I'd again recommend looking at your app and device stats (new in 2.2.5 in "Logs") to see if anything seems abnormally high, though that is one possible cause--just now one of the easiest ones to check.
I am guessing hub resources are fine but just the z wave network being overcrowded?
They are 6 fibaro double switches with a firmware bug where you can't disable these reports, they gave me hell even with inclusion.
So basically they send 12 devices worth of logs with energy reports on default which is about every minute each. I also noticed that every time I turn it on it sends two reports instead of one or maybe that's normal.
I'm pretty disappointed, is not ideal but still not extreme either i was hoping a 200+ advertised network would take this with no problem and i wouldn't have to overcomplicate things with another hub+ more money spent.
Do you think lowering the device event history can help in anyway reduce the load on z wave or that helps only with hub resources?
what i did noticed looking at my logs is that when motion is active the hub logs that instantly but fails to turn on my light
Lowering the event history will only help with hub resources, not Z-Wave--assuming the latter is the problem. Again, looking at the device and app stats on the log page (not so much the live logs themselves) may reveal more information here, though that won't exactly tell you what's going on with Z-Wave, just how long the drivers take to do their thing. Settings > Z-Wave Details (assuming you're on a C-7) can also show you if there is anything alarming like a high packet error rate (PER), lots of route changes, or a weak mesh (more or less: lots of red in the topology map).
So just to verify, even with hub mesh enabled, if I’m have my zigbee/zwave devices on one hub, there’s no reason to keep the antennas enabled on the other hub, since all the hub mesh comms are tasking place at the IP level and no radio sharing occurres at all from what I’m reading?
