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)
iris v1 causing stability problems? I have been having problems with my zigbee devices lately. Think it start around the time I added 2 v1 motion sensors. I may have to get rid of them now! Glad I read this.
Yes, I have a separate hub for Zigbee bulbs, all of them ZHA and ZLL, I think there's one repeater in there, but no sensors, Z-Wave radio is turned off.
The only Apps in there are Zigbee group enabled groups, no other automations on the bulb hub.
For now After reading something in another thread I went and looked at how many apps I have running. Including parent and child apps .... 90 lol. Maybe, maybe it's time for a second hub! lol
I'll repeat my mantra... "Multiple hubs can solve certain problems. If you have one of those problems, certainly look at what multiple hubs can offer as a solution."
Our critical resource is the ZWave and Zigbee radios. Find a way to make the queues behind each radio to have a depth of 0-2 and you'll have a happy experience, in my estimation. For ME, that meant moving Apps to their own hub.
I've never really taken too long of a look at HubConnect because I no longer have a SmartThings hub and Link to Hub/Hub Link seems to work just fine. What's the benefit for two HE hubs vs the built-in Hub Link/ Link to Hub apps?
There's great benefit to this. So much easier to isolate issues when you can separate the devices from the apps. I admit that I don't do this for everything, but some of these cheap devices have been very easy to discover that they are the problem when they're on my "Test hub" as I call it.
Hub Link and Link to Hub use the subscription model of mirroring events. Each device selected has events and each gets a subscription. Events occur and the Hub Link app is run and it makes a connection to the other hub and pushes that event.
HubConnect started out the same BUT had the design goal of pushing ALL attributes. That's the #1 difference. #2 was built in bidirectionality. Events could go in either direction without having to install another App. However, as time marched on, Hubitat's EventSocket 'feature' leaked out and all it does is pump out events. The result is that if you select EventSocket as the method, a Sending Hub does not need any APP per event, for the event to be seen on the other hub. The Listening Hub sees the ENTIRE EventSocket stream and HubConnect filters on what devices have been selected.
Because of that Event Subscription early model, integrating SmartThings became nearly a "why not"? Same code, different mustache.
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. 
After reading something in another thread I went and looked at how many apps I have running. Including parent and child apps .... 90 lol. Maybe, maybe it's time for a second hub! lol
