Using multiple hubs and recommendations

So, I currently have a C-3 which is connected to my ST hub via Hub Link. I have a C-7 on the way. I’m thinking I should probably keep both Hubitat hubs running but maybe hosting different device classes. I anticipate my ST hub will still host devices for a few more months as well during my transition. I do anticipate using webCoRE on the C-7 and bring some of my ST pistons over. Some questions:

  1. C-3 and ST are connected - I assume this means the C-3 is master hub. Can I introduce the C-7 as master with both C-3 and the ST hub connected without losing the ST devices I’ve linked to the C-3?

  2. What’s a good recommendation on device distribution between 2 HE hubs? I have some zwave devices on the C-3 and with the current C-7 zwave issues, I intend to keep them there until the C-7 issues are resolved. I was thinking longer term, maybe putting devices/apps that require cloud integration on C-3 and the rest on C-7. Is that a good plan?

I haven't used Hub Link/Link to Hub in this manner, but I think the answer to your first question is "yes." If not, the more powerful HubConnect can definitely handle this, and you may wish to consider migrating to that anyway, as it supports a wider variety of devices, has fewer bugs (do bulbs still not work with Hub Link?), and doesn't create annoying "shadow devices" on the hub with the "real" device. If that all sounds too good to be true, there's a tradeoff: it's custom code you have to add and install yourself according to the directions, but it's not too bad. :slight_smile:

As far as how to distribute things between hubs goes, there is no right or wrong answer. Well, actually, I guess there are a few likely "wrong" answers--if either uses Z-Wave or Zigbee, it would be a good idea to have a strong mesh for that protocol, so picking a far-away device as your only repeater, using overlapping Zigbee channels, or a variety of other mesh-unfriendly ideas would be bad. But other than that, some people split up hubs by protocol, purpose, or "zone"/location in house. If you do any coding, some people keep a separate hub for testing and development. Others segregate "questionable" code (webCoRe used to be one of these, but I think the current version is a lot better) to one hub so their "main" one keeps running. Some people do more than one of these.

That being said, if you don't really need multiple hubs, it's definitely easier to only have one, so I'd consider if you think you have a good case for this or just really want to try. (True needs would include something like Zigbee smart bulbs, many of which don't play well with other Zigbee devices, and so do best on their own network. Some people also believe--and I am not implying that this is correct or incorrect--that having a large number of Z-Wave or perhaps both Z-Wave and Zigbee devices could also lead to slower communication due to the low bandwidth of these protocols, especially the former, but there is no hard number here. The "questionable code" or test/development thing is another possible reason you might at least want one. But I'm not trying to stop you regardless!)

Another use-case for multiple hubs I've seen and saw some merit in is large footprint houses. Say you have 4,000 sq ft but it's all on one level. You could do it with one hub and repeaters but you're going to require multiple hops to get there and back and that might cause a slight delay. So, some folks use one hub at one end and one hub at another.

Still another use-case is an out-building that you can't reach through Zigbee or Z-wave signals. If you have another building that is so far away that you wouldn't be able to reliably get there with an RF signal but that building is wired for network connectivity, then you could use a second hub in that building and have it tied to your main hub in the house.

But I agree with @bertabcd1234. Having multiple hubs just to have multiple hubs isn't really effective and will just end up causing you headaches in the long run.

1 Like

There is also another "use case" for multiple hubs.
There has been many discussions here of using one hub for device control (Zigbee/Zwave devices), and one for program control (simple automation, motion lighting, rule machine, webcore, etc. + external : MyQ, Google Home/Aamazon Alexa, SharpTools, etc.). If further specialization is required then one hub for Zigbee and one for Zwave.
This approach separates out the two critical functions of device control from program control. (Many here are using Node-Red on a RPI for Program control.)

1 Like

Lots of good examples here for why to use multiple but some glaring issues not... Extra point of failure and added difficulty of troubleshooting when things go sideways. In some cases having two hubs may be helpful for narrowing down the problem but could just as easily have you lost and confused. Depending on your troubleshooting skills I would at least take this under consideration.

If you are aware of the numerous gotchas and can visualize how it all ties together and how it could fail under common scenarios then more hardware is always nice. It really helps to understand your networks first and where your true bottlenecks are. Get some logs and performance benchmarks with one and then see if two actually helps or hurts.

Technically yes, but depending on how it’s configured, it can serve to provide some fail safe so control isn’t lost to the entire house.

I don't understand the "one hub for z-wave and one for zigbee" model. You have 2 whole radios which are not doing anything and Bruce has long said that the radios are the usual bottleneck. That does not seem like a valid "use-case" to me.

I agree with this statement, but that is also assuming that they properly planned and placed their devices accordingly. Came across several cases already where this has caused issues.

1 Like

Well the mesh is usually the bottleneck, splitting one for zwave and one for zigbee reduces the likelihood that a misbehaving light bulb for example brings your whole house down. While it probably wouldn't speed things up on a hub where all the devices are playing nice, it could create a perception of speeding things up where most of the house is working, and all the misbehaving devices are on another hub not slowing down the rest of the house.

Not true. A "misbehaving light butb", if zigbee, would have absolutely zero impact on your z-wave mesh.

Misbehaving devices put a lot of load on the hub regardless of what network they are on. Which then causes it to slow down in other areas. I see it over and over again just look at someone's hubitat watchdog reports when they're having issues.

1 Like

Correct, unless it's bringing down the hub, but if that's happening you have a issue that needs correcting. I now have two but thats to have 2 ZigBee and 2 z-wave networks. Slow z-wave and rubbish lamps and fast z-wave and ZigBee 3.0 lamps and devices.

And that is not what I am talking about.

If you took the time to read I said that having one hub for Z-wave and one hub for zigbee doesn't make any sense.

I put all of my 65 zigbee bulbs and 22 z-wave plus switches and zwave smoke detectors that I have on one hub and all of my end-devices along with a select group of well-mannered repeaters on the other HE zigbee network. Since doing it this way, my networks have been very stable. Most of my rules are on the hub with the end-devices, which is actually the HubConnect remote hub, while the Server hub has all of the lights making it easier to share with Alexa and my Homebridge hubs. I experimented with having a motion sensor and button controller on the same hub as the lights they were controlling versus having them on different hubs and couldn't tell any difference in automation speed. That said, I conducted this test after all of my end-devices (around 70) had been moved to the second HE. Subjectively all of my automations sped up after this transition. I assume this was due to having double the zigbee bandwidth.