Multi-Hub strategy thoughts

Depends on your circumstances - for me I felt it was better to have 2 distributed hubs that worked the same - handled both Zigbee and ZW devices in a given area + an additional hub to run the funky stuff and cloud apps. I have one hub in the basement and on my 2nd floor. They are NOT be repeaters rather separate networks. Having separate hubs does reduce the # of hops a device takes in a given area as well.

If you feel range is not an issue then you could consider separating by protocol - Zwave hub and Zigbee hub. The idea is that one will not interfere processing wise (not radiowise) with the other if there are issues like a malfunctioning device.

You connect the hubs with either HE's "Hub Link/Link to Hub" apps or more recently (and currently more robust) HubConnect by @srwhite. IF you really want to go crazy you can add a 3rd "controller" hub as we were discussing earlier. This hub would not have any radios active and just be used for app processing. The whole concept here is to distribute processing as much as possible to improve stability and reduce bottlenecks.

I used to have a Hue but took it off the network (and removed the few Hue bulbs I had). Prefer to stick with one type of hub if possible for consistency - though the Lutron stuff looks awesome.

When I am talking about multi-hubs I guess I really mean HE to HE (and tangentially ST maybe as well).

Mulling over the configuration a bit more and now thanks to HubConnect - what is the impact of putting ALL (or as much as possible) apps and rules on the controller hub? The client hub would then in a sense be a device network hub only.

I guess I would still be concerned about a resource intensive cloud/3rd party app causing rules to get flaky on the controller or something.

It's the difference between "Distributed" processing vs "Coordinator/Worker" processing.

Distributed seems more complex to setup and maintain BUT has the advantage of running independently for the most part.

Correct me if I'm wrong, but meshes are stronger with more repeating devices, yes?
Having multiple nodes seem counter productive.

That is true, but people grossly overestimate how many devices it takes to make a solid mesh.

For instance, I adequately cover an >4000 sqft house with only 4 repeating zigbee devices - hub in middle of house, each repeater about 1/2-2/3 way between hub and outside wall. Now, obviously if I LOSE a repeater I would likely be in trouble as I don't have any redundant paths. But that has not been an issue yet.

For ZWave it is even better, as a zwave device can only do 4 hops in an active signal path. So if you have say 30 repeaters, it buys some redundancy, but not a much stronger active path mesh.

1 Like

You are correct. But me having a strong mesh does not stop 'you' from having one too, and that's how I treat my two active-radio hubs... as if they were in two apartments, not just two floors of my house. I must have two strong meshes. But that's all I need, each being strong on it's own.

I have 50+ ZWave devices on my original hub, half are a/c powered. I have 29 Zwave devices on my second hub, 19 are a/c powered. I could have chosen 'left half of house/right half' or 'north half vs south half' but I ended up choosing up half vs down half just so I'd remember which hub a device was on, because otherwise the choices (repeater count) seemed similar.

That's exactly what led me to choose to architect that third hub 'coordinator' -- so that the 'bad apps' would be limited in their impact to just the one hub. In other words, I attempt to make each hub as strong a mesh and unpolluted from 'bad apps' as possible. Rule Machine, Lutron and ZWave Poller are all built-in that's running on both Hubs. For third-party, I have ABC and HubConnect. Those are the minimum apps I can run to have a fully functional standalone hub.

Clearly, HubConnect stands out and I have a total of 62 devices from the first hub and 43 devices from the second hub feeding into 'coordinator' where I have those common and or risky apps.

Amazon Echo
Chromecast
Homebridge
HubConnect
Dashboard
NOAA Weather
Notifications
Rule Machine
Thermostat Scheduler
ApiXU (driver)

6 devices are being fed from 'coordinator' to the active-radio hubs.

I do tend to 'pollute' my radio hubs with drivers/apps/virtual devices as I attempt to help out around here, and every few days I go through and delete them, I know I'm not being 'pristine'.

1 Like

These are actually separate networks with their own setup but maybe pretending to be nodes via HubConnect (or Hub Link). My understanding was the shorter the range from a hub to a device the better/more reliable the performance. If not does that mean a line of 3 devices 10 feet apart going away from a hub has a stronger "network" than 3 devices all at 10 ft from the hub? I get that the reach may be longer..

Right! I agree - which is why I did exactly the same thing. My question is what if you had EVERYTHING all rules etc on the controller and just used the client hubs as well, nodes.. :grin:

In my HE break-in period I was having all sorts of issues, mostly self-inflicted so I can absolutely see how easy it is to "grossly overestimate" things! Lack of Expertise/Understanding, Paranoia and WAF are great contributing factors....

Thank goodness for these forums!!!

1 Like

Oddly, that was closer to my original expectations when I was in the planning stage. It was only AFTER I had built the third hub that I found out Lutron (and thus by extension ABC) supported multihub and were reverted back to the radio hubs. Homebridge does but it's already on the 'bad app' list so it's not going on a radio hub for a while... maybe when Tony completes v2 :smiley:

This is a great post. I just registered my second hub last week but haven't done anything to it yet and another one still in a box. My first c4 hub has 200+ of Zigbee and Z-wave devices and I am starting to see random delay on automation.
I should start the process but so darn lazy :grimacing:

Rather than move all your devices over maybe you could just try and move as many apps over to your 2nd hub.. see if that improves things first. You won't be using the radios in the 2nd unit right away but it maybe a quicker/easier way to see if the apps are having the most impact. You could always rebalance things later.. moving some devices over to the 2nd hub etc. Be careful though you may end up getting another hub - it's kind of addictive.

sorry.. he already has the third!! :smiley:

2 Likes

Perfect!!! (I totally missed that) Of course now he will need a 4th hub for development.. we really should be getting some sort of compensation for all this sales work!!! :rofl:

Not a bad idea. I don't have to leave my chair.

1 Like

I have to admit I've harbored secret concerns about Hubitat's business model sustainability. But reading this thread, those fears have vanished. I never thought "we" would be buying so many hubs on a recurring basis. Hubitat should start a Hub A Month club subscription program.

4 Likes

Plus all the referrals for the Lutron Caseta Pro hubs!

1 Like

Hubitat does have their SECONDHUB promotion/discount. One per customer (so 3rd, 4th, and 5th hubs are full price) and Free Shipping right now too.

Whelp just bought my 4th Hub.. was able to get the "SECONDHUB" discount so yayy.. THIS one will be used for dev work.. I promise.. :innocent:

I now blame @csteele for continuing to enable my addiction...

2 Likes

Same position for me. Hubs still in boxes (bought when they were on "offer".) Made some good progress on starting to measure system response times from an automation trigger being received to a switch being activated. Not sure how valid the measurements are but they are interesting.
Could really use a way of getting all my rules along with the trigger and target devices in a JSON response. Can't seem to find any way to do this with the API so I am building a this by watching/capturing the websocket event stream. Am learning lots... :crazy_face:

I chose a very similar architecture... I still have a few cloud "things" on SmartThings which I either have no plans to port, or prefer to leave them for other reasons.

I'm just now bringing the mobile RV Hub online. For clarity I've only highlighted key device connectivity types and core apps. There are other which are not shown.

Because of the size and previous issues with Zigbee, I split my Zigbee meshes roughly in half.

Hub 1 is on the Second Floor and contains all of the Z-Wave devices and all of the security-related Zigbee devices and about 1/2 of the remaining Zigbee devices in our apartment. This has allowed me to deploy HSM and partition our living space into it's one alarm system.

Hub 2 is in the Basement and contains all of the Z-Wave devices in the basement as well as the 1st floor rental unit. It has all of the Zigbee devices in the rental unit, basement, common areas, attic, and whatever Zigbee devices I didn't connect in our apartment. I have HSM configured for common areas and off-limit areas effectively creating a second security partition.

The speed of multiple hubs gets downright impressive when you have 2 or more Zigbee meshes AND use Group Messaging. I was turning off 4 groups of devices at night which were turned on separately during the day. All 4 groups compromised 35-40 Zigbee plugs. I was able to split the groups across both hubs, with a mode change automation switching off 2 groups on each hub. Man that is fast. Less than a second for all plugs to turn off.. It sounds almost creepy hearing all of the relays click in unison.

For most users, one hub really is sufficient. But as the smart home grows, there's an argument to be made for distributed processing so a hub failure, lockup, etc. has a smaller footprint of impact.

As other have indicated, it's really dependent on how many devices you have. A Zigbee network can easily handle hundreds, if not thousands of devices. BUT.... And it's a big one... It depends on how "chatty" those devices are. For example, 50 Zigbee plugs reporting power a few times a minute can easily clog up a Zigbee network and introduce latency for other devices. Therefore depending on how many devices you have, it may be beneficial to split them off.

You are not kidding! The increased performance on the radio meshes is a good reason alone. Plus distributing the failure points, and also other benefits like multiple HSM deployments for partitions.

And soon, a mobile RV Hub... That's probably a first for Hubitat. :slight_smile:'

Where do I sign up? :drooling_face:

2 Likes