Why would I need 2 hubs

So I see the app to link hubs and my question is why would I need two Hubitat hubs? Is there a device limit or a way to load balance to make sure it does not get "busy" and miss a trigger or something?

thanks

1 Like

I got a second one so I could have all my Iris V1 devices on a separate hub from my Iris V2 and Zigbee HA1.2/Zigbee 3.0/Z-Wave devices. Having the Iris V1 devices on the same hub was causing stability problems.

It isn't just for Iris devices though. The Hub Link/Link to Hub can also be used to link to other hubs from what I understand. Since I don't have any Hue bridges, Sylvania Lightify bridges, or any other bridge/hub, I can't answer how well it works.

The way it works for me is that the second slave hub shares devices connected to it with the controller hub. All the rules are set up there. The dashboard is on the controller hub. When a tile is added, it is adding a virtual device. The Hub Link gets or sends information as appropriate to the slave hub where the physical device is paired. It is pretty seamless in practice. Things just work.

2 Likes

You don't need two hubs. If you're looking at Hub Link, it started off as a way to connect SmartThings hub devices to a Hubitat Elevation hub, which I imagine staff (most if not all of the founders and current staff are ST refugees) found helpful during development and users may find helpful during transition. Some "power users" on Hubitat asked for a way to link two HE hubs, and Link to Hub was added to the existing Hub Link app to create a pair of apps that could do bidirectional "syncing" between Hubitat hubs. Another power user went even further and created his own, HubConnect, to bidirectionally sync HE or ST hubs with each other that supports even more devices and is, in my opinion, cleaner than Hub Link/Link to Hub in that it doesn't create a proliferation of virtual devices on the originating hub, and shared it with the community so we can all enjoy it. You may see a lot of users talking about any of these apps on here, but I'm sure it's a small subset of total hub users. :slight_smile:

That being said, I have three hubs myself:

  • one for development/testing
  • one for most of my devices and automations (it has my Z-Wave radio/devices, my Dashboards, and most automations)
  • a recent third hub I bought just for lighting automations (which I'm also using for all my Zigbee devices since most of them are lighting-related anyway, sending off their events to the other hub via HubConnect so they may be used in other automations).

I have my "lighting hub" since I wanted my lights to be as fast as possible, and I figured separating them onto their own hub was one way to ensure that, especially if I ran as little custom code or non-lighting-related apps, etc. as possible. I'd get by just fine with one (or two if I keep the test hub), and so would most people--some people just like to have multiple to segregate their network/devices for various reasons. Reasons or tactis I've seen include:

  • by floor/area of house if they have a lot of devices to reduce the load on each hub (not that its resources are taxed, but the USB stick on the older models with shared Z-Wave and Zigbee bandwidth to the hub might be a limiting factor if you have a ton of traffic)
  • to cover outbuildings or things on the same LAN but not easily accessible by extending the actual Z-Wave or Zigbee networks--a situation in which you might, in some sense, actually need a second hub;
  • to segregate third-party code in case it misbehaves, as that is often something staff ask you to disable in troubleshooting if you're experiencing odd hub behavior like slowdowns (I confess I originally bought my second hub to put the "naughty"-listed app webCoRE on until I moved everything to Rule Machine and custom apps)
  • a dedicated smart-bulb hub, as most smart bulbs do not behave well on mixed (i.e., with non-bulb devices) Zigbee networks--they tend to be bad repeaters and not reliably transmit messages from/to other devices, potentially compromising your network's reliability. They seem to do fine if they only repeat for themselves. Again a situation in which you might "need" one, but there are ways to avoid this (using smart switches instead of bulbs, using bulbs like Sengled that avoid this problem by not repeating, or using non-Zigbee bulbs or bulbs that form their own Zigbee network separate from HE, with natively supported options including Hue with the Hue Bridge, LIFX, and others). This problem is not specific to Hubitat, but the ability to link hubs make it possible to do do in ways you can't do with many other hubs, all of which could suffer from this problem.

So...you don't really need two. Some power users just like to have two. Or three. Or (I think I saw someone with) four. :slight_smile: There are a couple edge cases where it may be handy, but it's not something I'd say most people need to worry about.

1 Like

Unless you have over say 232 zwave devices you don't "need" 2 hubs......but the more your system expands you will "want" 2 hubs.

I have 3 -

  1. Is the main coordinator hub where the majority of the apps/rules and all wifi/lan/cloud devices reside On this hub both Zwave and Zigbee radios are turned off, freeing up the processing power of the hub to run the app's/rules.
    Instead of just doing a devices on one and apps/rules on the other, I did one of each for devices
  2. for Zwave with the Zigbee radio shut off
    and 3. for Zigbee with the Zwave radio shut off.

This also leaves room for expansion later

And most importantly, if I have a hub crash, I'm not waiting on order to process and shipping to be back up and running the home automation. I've had a previous hub from a different platform crash and it was 2 weeks before the warranty replacement came, That was 2 weeks of hell living in 1920

I'm thinking the one you mentioned who created the HubConnect App, actually has 5....lol

That intrigues me...... Do the devices get shared on the hubs or are they totally separate? So I could have a lighting automation triggered by a motion sensor on hub 1 and an automation on hub 2 using the same sensor for temp or something? I have one of the original hubs, actually hub #6 the first one put online outside the development team but just came back again after the platform matured a bit.

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. :slight_smile:

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.)

1 Like

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.

HubConnect is technically a 3rd party app. However, it is the best app in terms of features for linking hubs.

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.

Here is to crossing fingers!!

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. :slight_smile:

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. :wink:

4 Likes

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?

EDIT: Ordered!

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.

There's so many good uses for multiple Hubs.

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.

6 Likes

thanks for explaining that, I have one hub on the way and started to worry I was in too deep already reading this that I might need multiple hubs.

Thank you for the replies and explanations. Makes me want to order a second just to have zigbee and none stock drivers/apps loaded on

Don't get a separate Zigbee hub just because I did. :laughing: 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. :slight_smile:

I would recommend it if for nothing else to have a spare readily available if something were to happen to your primary.

1 Like

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.

4 Likes