HubConnect was built with this capability from the earliest days. Mostly because the Author goes Camping for months at a time and he has Internet in the Camper and ties it back to his primary Hub. There's a hundred plus devices in the camper... every door / window has a contact sensor so he can tell at a glance if the camper is road ready, as an example.
HubConnect offers an Internet option for connecting hubs:
The "internet" option is an outgrowth of the SmartThings integration.. The way into SmartThings is via their cloud. Well the same is true externally via Hubitat's cloud.
HubConnect processes events. It gets them from one hub and injects them to the connected hub. Hubitat Hubs are 100mb full Ethernet and compared to Zigbee at 250kb (yes, k vs m) the delay to transfer over the LAN is minuscule. If you use the EventSocket connection, there's zero additional processing on the sending hub.
If one hub (A) has two Z-Devices, a Contact and a Dimmer... and the desire is to have the dimmer come On when the Contact is open, and the Dimmer Off when the Contact is closed. Moving the 'calculation' (detect the event, determine that it has an effect, sending the action) to another hub (B) allows hub A to process Z-Radio queues. Z-Radios are Half Duplex. They must complete a transaction before beginning another. The result is that we want the Hubs to be idle... ready to process the Radio traffic, not off bringing in 2k worth of weather data. That desire to have idle hubs, ready to manage the slowest traffic we own, is a big portion of the benefit of multiple hubs. In a real sense, we're deciding to "dedicate a processor" to the Radio.
I do have a site-to-site vpn actually. lol. Everything is "local" to me. It makes it a lot easier to troubleshoot things at their house, even though they are just a few miles away.
There's a HubConnect specific Thread with over 3200 posts.
Read the first 3-4 then skip down to maybe the most recent 200. It will give you a flavor for the way it's being used. There will be a learning curve but there are drawings and videos to help.
And remember, I'm not suggesting you need more than one hub, but when YOU decide you do.. here's where the help resides
For the sake of keeping the record straight, one of the key reasons that some have more than one hub, is because there are certain devices (e.g. Xiaomi sensors, Zigbee bulbs, etc.) that do not play well with other devices on a Hubitat Hub. In order to handle these unique and limited circumstances, many have decided to put these "problem" devices on their own hub, and connect everything together with the HubConnect package.
Many have also decided to have a development hub(s) and a production hub(s).
If you think about it, they've made the decision that having an "extra" hub is worth it.
As a developer (for 30+ years!) and new owner, I greatly appreciate what Hubitat has accomplished! I have Alexa, and had SmartThings! HE is a breath of fresh air. As a former Java developer I have no trouble handling Groovy. I love the way the community is able to jump in and code their own drivers and apps. This highlights the great design of HE.
I am having a ball.
To the point of @SmartHomePrimer, can someone explain how adding another HE helps instead of say, using a zwave repeater? I am thinking of how I just added a couple aeotec zwave repeaters , one to a shed where I do have a hard wire. Sounds like a second hub would be better?
We can offer things to think about, but ultimately you have to decide on "better". Now, I am very biased. I have 7 hubs. But only 4 of them are 'in production' the rest are Development.
I have a hub for "Upstairs" and a second for "downstairs" and a third that acts as the center of the collection. It also handles all the LAN and Internet devices: Weather, Alexa, Google Home, HomeKit (via Homebridge) and so on. My thinking was to treat "upstairs" like it was a 2nd home... if that one Hub faults, only that portion of the home is affected. Same with "downstairs". Those hubs are ONLY Z-Device hubs, nothing else. My thinking there is that the Z-devices are SLOW relative to the LAN. Anything I can do to keep them working on clearing any backlog of device commands, is a benefit. I want radio queues to be as close to empty as practical.
I've recently started adding in a 4th Hub to be yet another Z-radio hub. I'm calling it "Front" because there's a lot of devices in my home along a region at the front of my house and I'm thinking I can move a subset of 'upstairs' and 'downstairs' to (again) reduce the queue depth. It's a bit of an experiment because I have nothing that is needing this.. therefore it's a bit hard to measure 'success'.
Others have a 2nd hub just for backup.. to reduce the shipping time to zero, mostly. But why have it sit in a box?
A Hub in your shed would be useful if the count of devices in the shed AND their response time, was going to justify the Hub's cost.
I just have to say, I gave up my ST back in February and went to HE. I have had very few bumps in the road and absolutely love HE compared to ST for so many reasons that I have mentioned in prior posts. Every time I think, "Aw man...HE doesn't integrate with that devices....I may have to hook up the ST hub just for that...", I do research on this forum and find results where I have yet to need to hook back up the ST hub for anything. Doesn't matter the product I have or circumstances; Mysa thermostats, IFTT charging money now, Genie garage door opener...it hasn't mattered, I have found solutions to get them baked into my HE. A little more work perhaps but all worth it and fun for me. Plus, my HE has been far more reliable than my ST ever was.
Thank you for the kind words. If you have a detached structure, that is the perfect example of why someone might split the mesh. Other examples of why people get secondary hubs is either for development purposes - so they can test new apps without breaking the main hub, or to install certain apps that are known to create problems, if certain conditions are present.
That desire to have idle hubs, ready to manage the slowest traffic we own, is a big portion of the benefit of multiple hubs. In a real sense, we're deciding to "dedicate a processor" to the Radio.
