Multi-hub setup

🛎️ Get Help
1

Before I start growing my Hubitat devices and automation much larger, I'm planning on setting up a multi-hub configuration using four C-4 hubs. From the reading I've done so far, HubConnect seems to be the best option.

The Server is where I plan on eventually running most of the critical apps. But if I have a working single Hubitat, I can just set it up as a client and leave the current processes in place as I begin testing/migrating them. Correct?

I plan on putting 4 hubs online. The server, a Zigbee hub (the current hub since it has ~60 Zigbee devices connected), Z-wave hub (I'll move the Nortek stick from the current hub) , and a 4th for other apps and testing. Since my home is physically small, I don't see a point in segmenting it by area. Is this what would be considered the best way to generally divide the load? I would consider setting up a second Zigbee mesh for bulbs. But since I have standardized on Sengled that do not repeat, I don't think that's needed.

Any suggestions, tricks, traps for a newbie delving into a multi-hub setup?

2

After registering the new hubs with Hubitat and setting them up as normal...

When I first split my hub up onto multiple hubs, what I did was take a backup of my existing hub.
That then became my zigbee hub and I removed all the apps and z-wave stick. (I’m in the uk so have two usb sticks)
Then I uploaded the backup to the next hub and added the usb stick
This gave me a working z-wave network and I just removed the apps and the zigbee devices and turned off zigbee
Obviously, when I restored the backup I changed the hostname and made ip reservations etc.

Next, I restored the backup to a new hub and removed all the devices etc but left the apps intact.
This became my ‘apps’ hub
You can now put hubConnect on this hub and the ‘slave’ hubs and get all the devices from the zigbee & z-wave hubs into the new master/apps hub you just created.
The devices can now be put back into the apps configuration.
The final hub can just be registered etc as normal then you can put hubConnect on it to use for testing and different apps etc..

This is pretty much how I did it except I used a separate hub for the hubConnect server

Hope this gives you some ideas

Andy

2 Likes
3

Did you have to put each device from their corresponding hub back in to the correct apps or did they connect automatically. Meaning does each app need to be redone with the same device but now located on a different hub.

4

You have to manually edit each app and re-add the devices (After sending them to the master/apps hub with hubConnect)

5

Aww mannnn that's what I thought, I bet you had a lot of apps/devices to reconnect.

6

I had 75 zigbee devices to add to a load of custom apps!
But only about 10 z-wave at the time

7

Andy,

Would you suggest that HubConnect Server be on it's own hub and just use the 4th hub as an primary apps hub? Is there a particular reason you have Hubconnect on it's own hub? It won't kill me to buy another hub (or 2) for testing and other apps if needed and that can be added after I get all the basics stable on the new setup.

Thanks for the info on migrating. I had though about moving the Z-stick, but hadn't considered using a backup to move the apps. There's not a great deal of automation setup and none of it is really that complicated yet, but it'd be a lot easier than rebuilding what little there is complete.

8

I’ve just found it easier to organise that way... everything goes through my “Messenger’ hub with hubConnect server installed.
I do have a couple of apps on there too but they are only my Modes Plus to control modes, and Average All which averages the output from a few devices. That way I can control modes and my ‘average’ devices all from one hub.
I believe that the author of hubConnect (@srwhite) also has his server on a separate hub (I believe he has a lot more devices than me) but I’m sure that now I have tagged him he will be along soon to confirm or deny that. :slight_smile:

I actually have 8 hubs but two of theses are test/dev hubs and one is a SmartThings hub

Running my automations, I have 5 hubs.

  1. Zigbee hub
  2. Z-wave hub
  3. Apps hub
  4. ‘Media’ hub with all my speakers and speaking apps like the chromecast beta that have been known to pull a hub down.
  5. Messenger hub (hubConnect server)

Andy

1 Like
9

Placed an order for 2 more although I only need one. Why buy one when you can get two for only twice the price?

4 Likes
10

This is true.. I have a hub dedicated to HubConnect server plus some LAN integrations which I'm slowly moving to a third hub to reduce the strain on my server hub.

Showing 1 to 559 of 559 entries

My server hub has just over 550 devices, most of which are HubConnect virtual devices from other hubs.

HubConnect Server
	|
	+---Dev 1 (socket)
	|
	+---Dev 2 (socket)
	|
	+---Homebridge (socket)
	|
	+---Hub 1 (socket)
	|
	+---Hub 2 (socket)
	|
	+---Hub 3 (socket)
	|
	+---RV Hub (http)
	|
	+---SmartThings (http)

HubConnect Server is the hub which runs HubConnect server and some LAN/Cloud integrations plus dashboards.
Hub 1 hosts the Zigbee & Z-Wave networks concentrated on the 2nd floor and attic.
Hub 2 hosts the Zigbee & Z-Wave networks in the basement and 1st. floor.
Hub 3 hosts the more recently added Zigbee & Z-Wave devices and is also taking on some of the LAN integrations moved from the server hub.
Dev 1 is my development hub.
Dev 2 was earmarked for my cabin, but for the winter it is my second development hub.
RV Hub is the mobile hubitat hub for my 5th wheel.
Homebridge is my connector from HubConnect to @dan.t homebridge client.
SmartThings is my legacy hub for which I integrate my Arlo and Ring devices throuh SmartThings as well as test the HubConnect client ST.

You only need 2 hubs for HubConnect, one has to be Hubitat, the other can be either Hubitat, SmartThings, or a Homebridge server.

With all of the devices on my system there are a lot of events between the two hubs..

Hub 2

  • proxyDuplicate : 24656
  • proxyFiltered : 3903
  • proxyReceived : 125565
  • proxySent : 96528

Inevents to the server hub, and received over 125k. If you have a lot of devices I strongly recommend using a dedicated Hubitat hub for the server...

Welcome to the wonderful world of muli-hub home automation!

1 Like
11

I am currently only using 2 hubs: A server, and a remote hub. However, I plan to split things by floor/zone. My meshes are pretty spread out, and the farthest devices could use a little help. I also prefer to keep my devices on the same hub as their associated rules. While HubConnect communication is blazing-fast with imperceptible latency, I like to keep them on the same hub anyway (to satisfy my own obsession). This is only one way to do it though, and splitting Z-Wave from Zigbee is a perfectly valid option if you don't need to split up your meshes into zones. I have about 145 devices and rarely experienced major issues with 1 hub, so absolutely none of this is a necessity for me - just having fun optimizing.

12

I just switched over to using 3 hubs.

Hub 0 is the HubConnect server. The only devices are the HubConnect Remote Hubs and the devices from either Hub 1or Hub 2 that need to be referenced on the other Remote Hub. The only apps (other than HubConnect) are two RM rules dealing with system startup and announcing mode changes.

Hub 1 is where all my Zigbee and Z-Wave devices are attached. There's also a Lutron Integrator (Radio RA2) there, my Simple Lighting rules, and the majority of RM rules dealing with presences and with other devices around the house (button presses, etc.).

Hub 2 is where my two Konnected devices (monitoring power and HVAC) are connected. The Lutron Integrator is echoed there, along with the majority of RM rules dealing with time-based operations (lights on at dusk, and that kind of thing).

I just made the switch from 2 to 3 thanks to the Black Friday sale :grinning:, and so far, I couldn't be happier. When I had Hub 1 as the HC Server, in addition to everything else going on there, there was some occasional lag, especially in the web UI; with 3 hubs, everything's nice and snappy. :smile:

1 Like
13

Thanks folks for the useful information!

Will do even though I doubt I'll get so many devices as to require it. With 61 Zigbee and 22 Z-wave devices I don't appear to be currently pushing the single C4 hub too hard. One reason is that I don't have all of the automation I want in place (by far) and most of what I do have is rather simple automations at this point. That will change with time.

I'm still reading the rather long HubConnect thread and have likely forgotten more than I remember at this point (it'll take 3-4 reads to sink in and 2200+ posts is a rather long thread), but I don't recall offhand if all of the events are shared between the hubs. So if I have NodeRed connecting to a websocket (which is how HubConnect will be communicating), should I be attaching to the Server hub or would it be better to use one of the Client hubs?

1 Like
14

I recently bought a second HE and put all of my zigbee end devices (about 60) on it plus Samsung and Sylvania plugs for repeaters. It has been very reliable since. I did notice that lights respond faster when the rule is on the lights hub versus the hub with the controllers. All button controllers are on the end device hub.

15

HubConnect has changed significantly in it's year of availability. @srwhite is constantly tinkering and has new ideas every 2-3 hours. Therefore, some of the most useful messages in the Thread are from mid-November to today... Those deal with the specific changes that got us to where we are today and v1.6. Therefore, I'd suggest reading the first 5-10 messages of the thread, then skip to mid-november and read to the end.

Take a look at the Videos and Installation instructions at:

15%20AM

Not automatically, you must identify which devices are to be shared.

There are two methods available to interconnect hubs: http (oAuth) and Event Socket.

http (oAuth) is ideal for interconnecting hubs on different subnets.. or over the internet. There's two simple examples: SmartThings, which only has a cloud interface. Messages to/from SmartThings must use their Cloud and http is the only option. Second, hubs that are physically distant. If you use @srwhite as an example, his RV would be exactly why the feature exists. The only way that 'mobile' address space is available is via Hubitat's cloud and http.

EventSocket is using Hubitat's (not publicly) supported service that is intended for Dashboard. It's not so much 'at risk of going away' as it is of being altered, to add new features to Dashboard. Hubitat certainly knows of it's use for several projects and won't remove it without a) a replacement and b) an announcement. The BENEFIT of EventSocket is that there's no 'per-event subscription' that consumes resources.. especially when doubled or tripled. Every event gets sent to EventSocket (if only) for Dashboard. It's unfiltered and from a processing / resource consumption viewpoint, free, it's 'always on'.

HubConnnct listens to the Event Socket stream and then must filter and de-duplicate. The presumption is that the time critical tasks of automation would run on 'this hub' and the tasks of distributing the events would fall on 'that hub' -- a hub with far less to do and thus able to filter.

This model is certainly working well for me, and by the 'sounds of silence' in this forum, the vast majority of homes using HubConnect. The result is the same though... the difference is in the minute details of where the filtering takes place. For my system of 3 Hubitat Hubs + SmartThings + Homebridge, both methods are used. EventSocket for everything but SmartThings, which must use http (oAuth). I have two more Hubitat hubs for development and they change how they are interconnected every few hours as I look at this or that.

The shorter version of the above would be: Small numbers of interconnected devices can use http (oAuth). Above a certain point, and I'd say 50-60 is a good evaluation number, Event Socket helps a little bit more. For extremely large systems, over 400 devices shared, is where some additional features of HubConnect can really help. (I'll leave the tease to @srwhite :smiley: )

16

Extremely helpful post. Especially this part since I'm still on the April (in the 700s range) portion of the thread.

Since I keep everything possible local and only thing to keep me from tossing the SmartThing hub into a dumpster is my aversion to waste and the possibility I might want it to update the firmware on a device, the only think I currently plan on interconnecting is multiple Hubutat hubs. I'd planned on using the event socket but was unsure if I needed to connect to each Hubitat from the Raspberry Pi with my current setup of NodeRed/Influx/Grafana. While I'll eventually replace it with a better system, I'd rather invest in other hardware right now.

Bill

17

Thanks for that great write-up @csteele. To clarify about the Node-Red linkage, do all the websocket events also come through the server hub? My Node-Red is currently connected to the remote hub where all my devices are, which is still working fine for my Grafana purposes. In which scenario would we want to direct Node-Red to listen to the server hub instead?

18

You want to listen where the devices are. :smiley: if the server gets ALL the devices then it becomes the single place to listen. If not, then you’re stuck listening in multiple places. Conversely, if Server already is listening to 90% of your devices, go ahead and add them. But for just two hubs, then it won’t matter too much