I'd estimate that most of my devices on the "lighting" hub get shared to my "main" hub. My lighting hub consist mostly of motion sensors (Zigbee) and the Hue Bridge and Lutron integrations (LAN), though to avoid needing multiple Zigbee networks, I actually put all my Zigbee devices on it (most are indeed lighting-related, but I also have my thermostat, some buttons, smart plugs, temperature/humidity sensors, and other devices). Any automation that isn't a lighting automation is handled via HubConnect on my main hub. My goal is to keep event subscriptions to a minimum on my lighting hub (ideally just a lighting automation and, if needed, HubConnect). I'm not sure if Hubitat cares as much, but on ST, it was often recommended to have the least amount of apps subscribing to the same device event; in any case, my goal here is to make my lights respond as fast as possible by ensuring there aren't multiple apps competing to process the same event (just my lighting app and possibly HubConnect; any other automations will be handled by the other hub through that) and that my hub's resources aren't getting eaten away doing other automations or running runaway third-party code (I try to be cautious, but I do have the old Homebridge app and some other possibly intensive apps running on my main hub...plus since I don't care as much about speed there, I can be reckless with event subscriptions, like subscribing to most motion sensors "inactive" events to supplement my presence detection should gelocation fail).
So, I guess to summarize, because my motion sensors are useful for other automations, I do share them to my main hub. And I actually have a few sensors from my main hub shared with my lighting hub, since my lighting hub is Zigbee-only but I have a few Z-Wave motion sensors (they're all kinda slow in my opinion so I don't see the benefit of isolating the to my lighting hub where speed is the goal and none are used as the primary sensor in interior rooms). But how you do it is totally up to you.
Neat! I thought I was early, but I only got hub #26. Shoutout to those of us with the C3 model, in any case! (I got a C4 because that's what was available when I decided to buy a development/test hub, and I got a C5 because it was so pretty I couldn't resist and had been thinking about segregating my lighting automations for some time anyway.)
So my question is....is HubConnect officially supported? If not that makes this moot. If it was, I'd buy another hub tomorrow just for this reason....maybe even 2.
If HE internally adopts such an application and makes it official, I'll be the first buying more hubs as that's a great idea. However, I'd be in the same position with a problem on my "virgin" hub because technically, HubConnect would be running.
HubConnect is not, but Hub Link/Link to Hub are. You can use those to "sync" devices between two Hubitat hubs, segregating third-party code to one. It is not a moot point then.
That being said, I like HubConnect much better, so I do use that. I'm not too concerned, both because I trust the code to be well-written (I've dug into it a few times to troubleshoot problems I had with some earlier versions; and both the author and his right-hand man are well-known, trusted, and active members of the forum) and because disabling one app is much easier than disabling a dozen--and when I do, most of my lighting automations (the kind that are annoying when they don't work) aren't affected.
Does Hub Link/Link to Hub not work for you? It's official.
I'm in! I can see huge advantages to having zigbee/zwave separate and custom code separate.
For those that do that, do you put the custom device handlers on the "zwave" hub so to speak. Or do you use a custom code hub and link the zwave/zigbee devices to that hub?
I have 3 hubs, I originally started with ONLY having any/all apps on the coordinator hub which seem to be a bit slower when rules ran.
So what I've since changed as I have a hub for Zwave and a Hub for Zigbee, is that any rule/app/code that pertains specifically to zigbee gets installed on the zigbee hub (same with zwave) Only ones that need both or wifi/lan/cloud get put on the coordinator.
So some apps/code/rules are installed on all 3 hubs that correlate to which devices it coincides with and speed has been back to normal
I have two hubs due to distance. I have a few devices in my backyard which are to far away from my main hub to work. So, I extended my WIFI out and then installed another hub.
For some, reading a Title or the first couple of posts, of this or some other threads, makes me feel like the interpretation skews towards "what flaw is there?"
There isn't a flaw. There's no reason to use multiple hubs if you're not encountering one of the issues that an additional hub improves:
Got a great distance to 'leap' between devices that a mesh is non-trivial to build?? then extend your LAN (even if it's via WiFi) and place a hub at a distance. HubConnect has the feature of linking hubs that are NOT on the same LAN.
Got a must-have "bad app"? It's bad only in the sense of consuming resources to the exclusion of others. I don't think we actually have an intentionally bad app. They all seem to be ones that are 'too big' in one dimension or another. An additional hub to run 'bad apps' where their behavior doesn't impact other components seems like an easy answer, and that was MY initial reason.
Are you worried, having spend too many hours joining/pairing devices, that a hub might fail? Maybe you'd like to split your devices across an additional Hub as 'insurance' against a Hub failure. At some point, the Hub becomes critical. Can't do without. More than one Hub means you can have options.
So many good reasons have been explored here. One of them kinda sorta fits each of us, I imagine.
Don't get a separate Zigbee hub just because I did. If you have a lot of devices and really care about speed, there may be some benefit, especially on the C4, where the USB stick handles both Z-Wave and Zigbee traffic (USB 1.x speeds should be more than enough to handle both protocols at the same time, but how the stick itself processes either is not something I know). I'm not sure if the C5 with its internal radios handles anything differently (e.g., maybe a separate bus for each radio?). In any case, for most users, this not an issue at all. Heck, it's probably not even an issue for those of us who think it might be (though I do question whether some of the excessively chatty Z-Wave devices out there might have the potential to bog down Zigbee processing--or any processing on the hub, for that matter; luckily, for the devices I'm thinking of, the manufacturers have responded with firmware updates to help eliminate that). But as mentioned above, there may be a variety of reasons you choose to get a second (or more) hub, with this perhaps playing one part.
I do like the idea, however, of separating custom code onto its own hub. I have as little custom code as possible running on my "lighting" hub (also my Zigbee hub since most of those devices are lighting anyway and I don't need any more Zigbee networks in my house). This is because I want my lights to work work as reliably and respond as quickly as possible, and limiting custom code running on that hub plus minimizing the number of event subscriptions for motion activity and button presses (or whatever you use for lighting) are two ways I can help ensure that. If a "runaway" app on my main hub makes my thermostat take a second or so longer to process a setpoint change, I'm OK with that. If I'm halfway into the room and the lights are still off, then I don't like my automation setup anymore.
Only 1 months with HE, I have 3 hubs : 1) Downstairs. 2) Upstairs. Z wave and Zigbee on both, and official apps. 3) Server, use HubConnect, all Lan devices, Dashboard, PushOver, 3th party apps, Echo, Google, connect with ST hub ...no radio on this hub. So far so good.
There are many ways to 'split' devices across Hubs. I chose the very simple "altitude criteria" -- Upstairs is one Hub, Downstairs is the other. The third hub is 'coordinator' and I'll detail what's on each.. NOT to suggest 'do it this way' but to simply explain the choices I've made.
Hub #1 - ZeeRadioLower
This was my original Hubitat and once had everything on it. Adding the 2nd Hub meant Excluding about half the devices. Because of that role as the one-and-only, I have a couple of Apps I didn't move off, including Chromecast (beta).
Hub #2 - ZeeRadioUpper
This hub began as my development hub but when I decided to split ZWave devices in the house, it was too handy and Hubitat ordering too "far" At this time I was still 100% ZWave and had only 4 Zigbee devices on my Development hub. It was easy to just say, ok, Zigbee here only.
because of my choice to use only ZWave, and then 'back into' having 15 Zigbee, about half of the motion sensors really should be on the Lower hub, if I was being 'pure' to my upstairs/downstairs intent. But as I've said elsewhere, the LAN speed between the hubs is so many times faster than the Radio, I can pass the events over HubConnect and never even notice. I have a Zigbee motion sensor (Iris v3) over the kitchen sink (with a 'tube' to give it tunnel vision) and it's meant to turn on the light over the sink. Motion to Hub2, over HubConnect to Hub3, over HubConnect to Hub 1 to be the condition that a Rule is looking for to turn on the light. It's no difference perceptually from being all on the same hub. Naturally then, I'm not looking to 'fix it" and power up the Zigbee radio on hub1. One Zigbee mesh is all I want to build out.
damn hanging round these forums does have some great ideas!
I was thinking the same thing plus maybe using my old SmartThings V2 hub to run cloud based devices like the echo dots and ring doorbell.
To be clear if all hubs are on the same local network if they lost internet they will still communicate (except for cloud based devices)?
Hubitat, yes. SmartThings is 100% cloud. HubConnect's SmartThings Remote Client sends / receives data from their Cloud. HubConnect's Server Instance for your SmartThings hub also communicates to their Cloud.
I actually turned off my ST hub for a day and everything worked fine (except for devices physically joined to the ST Hub Z-radios) from their mobile app.
Your ST mobile app might be able to use those services but the internet being down between your Hubitat Hubs and their Cloud(s) would prevent them from working, true.
I would like to ask the HE development team....if you could separate out tasks to different hubs...what would YOUR recommendation be? AKA separating what would be most beneficial? Zwave? Zigbee? Custom code? @bravenel@mike.maxwell
Also again for those of you doing custom code separation, are you meaning app only? Or custom drivers as well. Meaning if you have a custom zwave driver you are using do you have two zwave networks? one with custom drivers only and one with built in?
Some people only segregate apps. Some people have multiple zwave and zigbee networks, Some people also separate zigbee devices by type of zigbee - ZHA vs ZLL (I think @mike.maxwell does that if I remember correctly).
There is no one right answer to this. All of the options are possibilities, and pretty much all of the permutations of segregation are being done by one person or another.
In my case I'll likely end up w/3 hubs and 2 separate zigbee networks - one zigbee network for xiaomi deivces and some compatible repeaters, and another for all 'normal' zigbee. I think I've decided that it is cheaper to just buy another hub for the xiaomi devices and segregate them versus replacing them with fully compliant zigbee or zwave temp/humidity sensors.
Even though I use some custom zwave drivers, I don't plan on segregating those as I am confident in my zwave driver coding/troubleshooting ability.
So....wouldn't it be cool to have a "zigbee" ONLY type hub that just had a network interface? Similar to how lutron and Hue work? Man if I could buy a hub that the only purpose was to link with my zwave devices using some type of removable usb key/etc that mean I could upgrade it without having to rejoin...I'd be on that like flys on ....
Take all of this radio load off of HE totally.... A Zigbee hub and a Zwave hub that works natively with HE....yes please. (I get that is what we are doing with multiple HE hubs..but you know what I'm saying)
If you have a lot of devices and really care about speed, there may be some benefit, especially on the C4, where the USB stick handles both Z-Wave and Zigbee traffic (USB 1.x speeds should be more than enough to handle both protocols at the same time, but how the stick itself processes either is not something I know). I'm not sure if the C5 with its internal radios handles anything differently (e.g., maybe a separate bus for each radio?). In any case, for most users, this not an issue at all. Heck, it's probably not even an issue for those of us who think it might be (though I do question whether some of the excessively chatty Z-Wave devices out there might have the potential to bog down Zigbee processing--or any processing on the hub, for that matter; luckily, for the devices I'm thinking of, the manufacturers have responded with firmware updates to help eliminate that). But as mentioned above, there may be a variety of reasons you choose to get a second (or more) hub, with this perhaps playing one part.
At this time I was still 100% ZWave and had only 4 Zigbee devices on my Development hub. It was easy to just say, ok, Zigbee here only.
Naturally then, I'm not looking to 'fix it" and power up the Zigbee radio on hub1. One Zigbee mesh is all I want to build out. 
