Yes. It's a restriction, that's all. Something to be aware of and work around.
Hubitat Staff are more than aware of this, yet any fix has the lowest priority because it applies to so few people (so far... 
)
I have been preparing for the switch to multiple hubs for a while now.
One thing I have noticed is that (at least with a C4 hub) if the hub gets too stressed the zigbee shuts down. (Sometimes requiring a reboot to get it back)
Therefore, my design is slightly different.
I have quite a lot of zigbee devices (around 80)
I have only a few z-wave devices. However, 5 of those devices are very āchattyā aeon hems which work best when joined securely (this causes lots more traffic than an insecure join)
So, for me..
One hub for zigbee devices only (no apps to stress the hub apart from link to hub)
One hub for my z-wave only (with a dashboard showing my hems and link to hub)
My third hub will be my ācoordinatorā hub with app my custom apps and cloud apps on (and no usb sticks)
Iāll use a combination of link to hub and maker api (with an easy to use http driver Iām working on) to allow the coordinator to control everything (although some maker api āfailingsā are making this a little difficult)
My fourth hub, yeah, Iāve got 4 of the damned things, is my dev/test hub
(Actually I have 6 but two are UK C5ās and have bad firmware on them so are bricks. As far as Iām aware they were the only ones in existance until I trashed them.)
As Iām in the UK, we get separate usb sticks for z-wave and zigbee so my ādeviceā hubs will only have the relevant usb stick inserted and enabled.
It takes a lot of work to plan and get everything right but I hope to complete this very soon
Andy
1 Like
Thanks - I read your story carefully. I'll reach out when I get stuck! I am wondering if there is a way to test performance before and after the changes. Would timing of response from a command issued to a response returned be a useful measure? Any apps that manage this? Should we create one?
I'm a research scientist so I like hard data / measurement rather than relying on my subjective opinion.
1 Like
How about we design a small app to measure our response time and perhaps other metrics before and after we give this a go? I know you have the programming skills and I am dangerously ambitious when it comes to my javascript attempts.
What is the purpose of having multiple hubs?
How does it all work with more than one? Do the hubs run separate Zwave/Zigbee networks? Or are they both in the same one? Who sends/receives commands?
I may want a second (or third) hub in my house. I have fairly large house - single floor - and I have frequent issues with commands NOT getting to the hub i.e. turn on Master Bath Light from switch and hub never "sees" the event. Thinking maybe second hub on opposite corner of house might help, but not sure what that "looks" like when done. Do some devices connect to one and others to the second? Do automations work across both? Lots of questions, sorry.
In my case (2 hubs - basement & 2nd floor) it was to hopefully make things stable as possible by distributing processing, devices and the networks. Yes each hub has it's own unique ZW/ZB networks (you can set the channel for Zigbee if you want).
You connect them via "Hub Link" and "Link to Hub" apps.
You will still have to connect each up to your regular network - if you don't have wiring to the remote hub you can use something like Powerline Adapters to extend your wired network.
The current drawback with using hublink/link to hub is the limited devices you can expose things like switches but no thermostats etc.
I try to keep all my rules and apps related to devices connected to each hub on those specific hubs - meaning my 2nd floor hub rules/apps control my 2nd floor devices and my basement hub rules apps control my basement, first floor and garage devices. I only have certain virtual devices that talk between hubs.
In your case it may be a little trickier since you will likely have more devices communicating between hubs - I know there are people here that have done it that way..
Begin by imagining two hubs that are completely independent. Say one Hubitat, one Wink. There's no confusion there, ok? They have independent ZWave and Zigbee mesh networks. They all share the same radio frequency band, but by managing Zigbee channels, WiFi channels, Hue channels, they can all be made to play side by side. I think that answers the "Who sends/receives commands?" right?
Now in your mind, replace that Wink with another Hubitat. Everything else is the same.. they are fully independent. You pair/join devices to their respective hub and never the twain shall meet. If Hub A knows about Device 33, then Hub B does not.
So far, everything I've written is focused on the RADIO side of the hub. Two Hubs, equals Two Zigbee meshes + Two ZWave meshes. And this is important because you must manage the repeaters for all 4 of the meshes, just as today with one hub, two meshes to maintain.
OK, now it's time to throw in the linking of the hubs. As @erktrek said, Link to Hub and Hub Link are paired (sender/receiver) builtin apps. You identify devices in Link to Hub and they will appear on the hub that is running Hub Link. If you flip it around, and have each hub run one of each, you get bidirectional linking. All of this is occurring on the LAN side of the Hub(s), completely unrelated to the Radio side of the hub(s)
This alone is not a reason to get multiple hubs. Mesh management 'should' take care of this. A perfectly square 5000 ft home is 70 ft on a side and if the Hub is in the center, 35ft to 45ft radius can be achieved with a routing device in each quadrant. But then who as a perfectly square house? 
The point is it doesn't take much to get a decent mesh in all directions. There's a 4 hop limit with ZWave, BUT the mesh is built by the hub with the intent of making the mesh 'reach' as far as possible.
Imagine three routing outlets... in a line, 12 ft apart, the first 12 ft from the hub. The hub MIGHT choose to route through the Last outlet. All 3 are within range of the Hub, so it chooses to route through the most distant device. Someone on this forum said "we need RF goggles" and WOW would that help
But now to the final part.. how to implement. For @erktrek and I and probably most others, we started with one hub and connected everything to it. Perfect. But the limiting factor of any hub is the radio because (relative to everything else in our tech lives,) ZWave and Zigbee are slow. Thus the radios simply cannot crank out zillions of packets per second. By doubling up on hubs, we double the radio's ability to crank out packets. We probably reduce routing hops and that improves performance too.
Split your existing collection of devices along logical lines. You want to begin with them being as independent as possible. Then via the Link, you can push status to the opposite hub to be evaluated in Rules and affect your automations. Because the Linking part runs over the LAN, which is usually gig speed, (your home may vary ) you can pump a lot of status back and forth.. BUT as has been mentioned, you can't move ALL status. Some devices will only transfer a single attribute. That drives the restriction of being as independent as possible. Let's say you have a device that gives you Humidity readings BUT Link to Hub doesn't include that... then you cannot use that Humidity value on the opposite hub. It doesn't get there. {Workaround is to put the humidity value in a virtual dimmer and use Link to hub to get the value to the opposite hub. }
Long enough, I'll stop now.
7 Likes
So if the challenge is only distance perhaps repeater devices are the "better" (simple+effective) solution.
If the challenge is a large number of devices or a large amount of processing multiple hubs may be better.
Over-simplified?
Yes, for an oversimplification, it's a winner. 
1 Like
Distance is not the issue. The mesh is the issue (I think). I have 120+ zwave devices - mostly wall switches and plugs that are always on and repeat.
I believe my mesh is too noisy maybe? I have run zwave repair - many times - but that doesn't seem to get the slow reporters to work any better. I'm actually replacing one zwave dimmer with a zigbee repeater tonight - because my zigbee network is MUCH faster.
Amazing response - thank you very much!
Sounds like I need to split my house in two and add a second hub (maybe a third). Is there a way to set a zwave channel? I know how for zigbee. I don't have any hue.
Makes sense on the Hub Link and Link to Hub - even for devices that don't relate.
What about automation - all on one hub? or half on each? I would think managing as much as possible from one would be better - though if it died, you'd have to recreate everything on the other.
Here's another thought. Would it make any sense to use an old ST hub as a second hub? I'm thinking just for radio traffic and do all integration and automation on the HE. Thoughts?
My design is three hubs. One for each floor, rather a lot like @erktrek but there's no such thing as basements here. Just down stairs and upstairs. I call my third hub 'coordinator' because my initial reason for architecting it was to hold all of those 'bad apps' that cause slow downs. Rule Machine and it's brethren have never made it to the 'bad app list' and so I have them running on EACH of the 'floor hubs.'
[ Link to Hub in the drawing is bidirectional]
All of the automation is running on the 'floor hubs' with practically no automation that needs elements/values/data from any other hub. It's pretty easy really, bunch of motion / door sensors and their lights/sockets. Easily 90% would never need to go hub to hub. Although you're going to split the home 'side to side' the same applies. Open a door or window here and the other side (other floor) of the house has no need to know.
Same with the 'coordinator' all of the automation on it is related to the devices that are attached. I do not have a ZWave Thermostat, mine's WiFi and although I do have a driver for it, my need is simply to automate the one missing feature.. seasons... where the thermo needs to change from heater to A/C and then 6 months later, back again. I have ApiXU on it, because it's on the 'bad app' list (even though it's just a driver) and I have automation to set virtual switches for things like "gloomy day".
You will note from the drawing, there's no 'side to side' communication. The two 'floor hubs' cannot speak to each other. This is another limitation to Link to Hub. But truthfully, it's a miniscule limitation, I simply route from one 'floor' to another via the coordinator. As I said above, that side of all of this is super speedy.
2 Likes
Iām placing pretty much all of mine on one hub with the sticks removed.
Easy to backup and restore on to a new hub if it fails.
No radio problems to drag down the hub
Radio hubs wonāt have much in the way of custom apps to cause problems
It also means I have āspareā sticks (2 in the Uk per hub) as I bought all my hubs with sticks (C4) to replace any that fail
One thing to note though, I donāt use many (if any) built in apps, mine are all custom
(Apart from the āconnectionā apps like chromecast and sonos etc.)
Andy
1 Like
That was my architectural choice as well.. time will tell.
Because the linkage is so fast, relative to the radio(s) it's perfectly feasible to send everything to the coordinator and let it perform all the automation. Up to the limitations of Link to Hub, that is.
I've spoken of this in other places, but my Garage Door Opener is the best example. Link to Hub exposes it as ONLY a Contact Sensor to 'coordinator' (think tilt sensor).
Presence for me, since it is created on Homekit / Homebridge, exists primarily on 'coordinator' and thus I either send Presence to the 'floor hub' or I send Garage door open / close to 'coordinator'. The 2nd is not an option so I send presence to the 'floors.'
Dashboard is on 'coordinator' only and thus I'd like to have the ability to open and close my Garage Door. Again, virtual switch to the rescue.
Do not interpret any of this to say: must use three hubs. I imagine two will work just fine. Manual "Load Balancing" between two hubs, so that one is heavy with Apps and light on Radio use, would probably work as well.
The big benefit I've 'seen' is the doubling of the radio bandwidth. The range of responsiveness is tighter now. Two hubs brings all of that and at only 2/3 the expense.
2 Likes
back up in msg 38, I mentioned restrictions with Link to Hub and how I worked around it.
and msg 46 I covered the same ground...
In the past couple of weeks I've dropped Link to Hub / Hub Link and am now fully using HubConnect written by @srwhite. It is what I wanted from Link to Hub: sending all the attributes and events, It's extensible and naturally I'm not seeing any issues with it or I wouldn't be mentioning it here.
It installs, not surprisingly, like Link to Hub, in that there are two parts, the "server" end which goes on the 'coordinator':
and then "remote" which installs on each individual hub:
Where you select the devices that will be reflected to the 'coordinator':
AND
The result is a set of devices on the 'coordinator' or 'remote' of the same name but using virtual drivers, rather similar to the Linked drivers.
The installation and setup is fundamentally the same as Link to Hub and Hub Link, not surprisingly. The differences are all in the attributes and events that are reflected.
I am able to put a Garage Door tile on Dashboard and when I click the tile, the garage door opens (or closes.) Rather anti climatic since that's exactly what happens on a single hub. Only if you are using multiple hubs AND you notice missing attributes or events, does the restoration of them seem so impressive
I am now able to send between my three hubs with ease. I can put automations on any hub, but better is that I can interconnect those Apps that live on 'coordinator' with the Rules that could benefit with no workarounds.
I've gotten my Aeon SmartSwitch 6 sending energy, power and voltage along with switch and for my Dome On Off Switch, acceleration. All of these values simply improve Dashboard.
I don't have my SmartThings running any longer, but Steve (@srwhite) does and he's got SmartThings tied into his 'coordinator' Hub also, which means HubConnect replaces "Other Hub" too.
I realize this is of interest to only a tiny few, but I think knowing that the restrictions have melted away might encourage others to consider a multi-hub architecture... even if it's just adding to your own wish list.
3 Likes
An update to my drawing:
{Image updated in message 75 to show SmartThings}
I wanted to have the diagram show that some products and tools work just fine on both hubs and don't benefit from a third hub.... Which comes to a question...
How many people around here are using more than one hub and find Link to Hub restrictions are impacting them? That's the group of people that should explore HubConnect.
@srwhite is close to releasing it, he says. There's not a lot of learning curve to it. It works as expected. If there's adequate interest, I'll put together a how-to with screen caps.
7 Likes
Oh heck yes... I would be very interested in that!!!! Thank you for mentioning it and of course all your work and once again thank you @srwhite...
What devices are you using via Link to Hub that need more attributes (events)?
I just added a handful of additional attributes for the RGB Bulb, which is great and makes it feel more complete, but I'm pretty sure, now that I'm done, I wouldn't have used those attributes in any automation.
Here's how it's defined from within HubConnect, as an example:
"rgbbulb": [driver: "RGB Bulb", selector: "genericRGBs", attr: ["switch", "level", "hue", "saturation", "RGB", "color", "colorMode", "colorTemperature"]],
I looked at my Hank RGBW and can see this list:
Current States
RGB : [255, 162, 23]
color : #ffa217
colorMode : RGB
colorName : Orange
colorTemperature : 2200
hue : 10
level : 1
saturation : 91
switch : off
And then for the Fibaro RGBW LED Strip Controller, I'm seeing:
Current States
colorMode : RGB
colorName : Dark Green
effectName : Fire Place
hue : 0
level : 49
lightEffects : {"1":"Fire Place","2":"Storm","3":"Deep Fade","4":"Lite Fade","5":"Police"}
saturation : 0
switch : on
In other words, all RGBW are not created equal. I picked a combined list of attributes I thought I might be useful in Automation.
You can create your own in HubConnect, in a fill-in-the-blanks style, but I'm interested in what YOU are finding missing. ME, I needed a complete Garage Door Opener.
Steve gave me that on day 1:
"garagedoor": [driver: "Garage Door", selector: "garageDoors", attr: ["door", "contact"]],
1 Like
The short answer is nothing yet - right now I only have some virtual switches. I was purposefully holding off in order to get a sense of how to connect things between hubs and also trying to be careful - now I want to incorporate my 3rd hub as the controller. As my rules/apps evolve it will probably increase my need for more attributes events etc. HubConnect sounds more flexible.
I have Nest thermostats, am using certain attributes of the MultiSensor6 like illuminance. I have an osram RGBW light strip, Water sensors, Dome Water Main shutoff, Orbit watering timer, Power reporting of a Zooz outlet, Maybe Apixu, SONOS etc..
