Multi-Hub strategy thoughts

Now that I've added a 3rd "controller" hub an installed @srwhite's excellent HubConnect I am trying to figure out a good strategy for how the apps will be distributed etc...

The general idea with using multiple hubs has been to increase stability by distributing the processing to separate hubs while strengthening the communications to the devices themselves.

In terms of basic layout there have been different ideas - some prefer to separate via device & protocol (Z-Wave hub + Zigbee hub) in order to minimize interference and strengthen the networks respective meshes. Seems easier to troubleshoot specific device issues.

Others have split things by "area of effect" - having a hub in two or more locations supporting both Z-Wave & Zigbee devices. The idea is to provide as strong a signal to devices as possible reducing hops.

In addition some have opted to add a 3rd (or 4th!) "controller" style hub which does not connect to physical devices but is used instead to hold all the custom apps / cloud services. The idea being dedicating a hub for this reduces processing issues even further by isolating possibly slow or cumbersome apps that could adversely affect device communication and event handling.

In my case I have 3 hubs - An upstairs hub which controls (ZW+/ZB) devices, a main floor hub that controls my basement and main floor (ZW/Zw+/ZB) devices and a 3rd hub which I was using for development but have decided to also include as a "controller" hub.

When I had 2 hubs - I used HE's "hub link" and tried to keep things as simple as possible by only exposing a couple of virtual switches. I did this because I was still not sure about how things would work.

Moving to 3 hubs got me thinking about what to put on the controller hub vs the client hubs. I have a bunch of different devices a lock, thermostats, leak detectors etc. Some rules like motion activated lighting I feel should stay on each hub with the devices they control for optimal speed/reaction + reduce error potential. Others like APIXU weather app or the Nest app seem good candidates for the controller hub.

Be curious about others thoughts on this..

1 Like

My original idea was to split protocols and use a 3rd ‘controller’ hub to run everything.
However; since doing that I’ve found that sometimes it’s better to add the odd app to the ‘hardware’ slave.

For example:
I have 6 aeon hems on my z-wave hub
Apart from whole house monitoring of consumption and generation (I have solar panels)
I use 3 of the Hems for laundry announcements, and one to monitor my big UPS.
So, it seemed sensible to put the app that plays the announcement mp3s, and screams if the UPS loses power, on the z-wave hub.
No point in ‘pushing’ all the data from these very ‘chatty’ devices to my controller hub just for this.

After realising this, I’m starting to look at my other apps to see where they are best suited.
The one thing I am concerned with, however; is ‘loading’ the zigbee hub too much and having the zigbee ‘fall over’ if the hub works too hard (something I have noticed - if the hub works too hard then the zigbee stack is the first to fail)

I also now do all dev work on my ‘test’ 4th hub so I don’t disrupt WAF :slight_smile:

Edit:
Btw. I only have the relevant sticks in the relevant hardware hubs (i.e only z-wave stick in my z-wave hub) and no sticks in my controller hub (both sigbee and z-wave are disabled on this hub)

Andy

Yeah I agree with that - local apps to keep things distributed for certain things. I do like the cloud apps on one hub idea.

I have 2 C4's and a C5. The C5 is the controller/dev hub right now - too lazy to port devices from a hub over. I "may" get stickless C4 to be the controller as that seems to be a cleaner way of doing things..

Originally the only communication between hubs was for illuminance testing and lighting - have a powered Aoetec MS6 in a clear weatherproof box outside as cheapo weather station. I was using APIXU weather driver which was working well too but not as accurate - I still may incorporate APIXU on my controller hub for giggles.

My whole reason for starting down the multi hub road was because my zigbee stick fell over on a regular basis.. usually at 4am when it decided my cars had been stolen and screamed the house down.
Too many apps mixed with too many devices. :slight_smile:

Since moving the apps away from the zigbee stick all is well!

I also have my weewx/wu weather driver on the controller, along with all my hue devices.
I must confess though, that I’ve considered using a 4th hub and splitting the apps/control
But maybe that’s just fantasy :slight_smile:

Andy

I also use my weather station, along with a couple of aeon multi6’s and my ‘average all’ app to control a single virtual ‘home illumination’ device.
This then controls all my lux related apps etc.
Like sending my controller hub into ‘evening’ mode when lux is below a certain level and it’s within 60 minutes of sunset :slight_smile:
Evening mode then switches relevant lights and automations on

Andy

1 Like

That's cool. I like your AverageAll app - had fun with temp averaging with all my upstairs motion sensors (mostly in closets for lighting).

To your point - that's where I think the controller hub can really help - device aggregation and cloud apps. I have 2 virtual switches that handle night time and daytime low light illuminance checking but I think I like your idea better.

I do things by ‘mode’ because I only have a few.

Early weekday morning - starts at 6:30am
Morning - (controlled by lux and proximity to sunrise)
Afternoon - 12:00 trigger
Evening - (again lux and sunset) - turns on various lights
Night - (virtual switch controlled by Alexa in a ‘goodnight’ routine to turn everything off)

I use ‘modes plus’ app for this mode switching.

I just make sure that certain lighting apps etc will only work in certain modes.
Then I also have things like the ‘morning’ mode turn off any lights we may have left on before going to work. (Controlled by ‘mode switch’)

Lol, I actually use the apps I write on a daily basis.

Andy

3 Likes

So I guess as a general strategy to follow is for any "shared" thing like an app or devices to be used on the controller while specific things like lighting control that affect only one hub should be kept local to that hub.

Controller Hub:

  • Cloud Apps and Devices
  • Shared apps/devices between hubs
  • Shared RM rules between hubs
  • Shared or high cycle 3rd party apps/devices
  • "Mode" and other things that impact the whole system vs individual area or hub.

Client Hub(s)

  • Locally connected devices
  • Local apps that impact related hub only.
  • Local rules that impact related hub only.
  • 3rd party affecting apps/devices on related hub only. **

**For 3rd party apps, IF appearing on more than one client hub then consider moving it to the controller hub.

Something like that..

2 Likes

For the real multi-hub experience maybe I should double up on the hubs - 2 for upstairs (ZB only hub + Zw only hub) and 2 for downstairs (ZB only hub + Zw only hub) + one controller hub (no radio) to rule them all. This would enhance both area AND mesh networks!!!!!!

:rofl:
:rofl::rofl:
:rofl::rofl:

2 Likes

I like the way you think.
I’m realising now that this is the way to go.

Andy

So any thoughts on the "optimum" number of devices per hub/mesh ? Sounds like you are getting to a hub per "zone" - and becoming "ultra-local" in terms of mesh communication. Am still hesitating to enable the extra hubs have waiting to be connected until I can measure performance benefits objectively. Maybe I'm just too risk averse.... did you guys measure any performance metrics?

The only issue I have is the occasional (once or twice a day) "lock-up" of the system - the normal instant responses get delayed for several seconds until things start again (no intervention needed from me). Not sure any of the logging I am trying will catch this as the logs are silent when this happens as far as I can see.

This is one of the issues I had.
Hub gets bogged down trying to do too much with either too many devices or too much code.

Instantly better when I converted.

Andy

1 Like

I am not sure - it may depend on what is good for Zigbee vs Z-Wave. There was an issue with too many Zigbee devices but I think recent firmware updates have resolved that.

Having multiple hubs not only improves reliability, also adds some protection if you have a lot of devices (150+ mixed). If you ever have to reset your hub and re-pair devices you will be MUCH happier if you don't have to do all your devices.

Another approach that people are doing if you don't need a large area covered is having 2 hubs split out by protocol. So one for Zigbee and one for Z-Wave. That way issues with one won't affect the other (hang ups etc).

Still like the idea of a controller hub. All things considered the price of these hubs are not bad vs the functionality/stability you gain. I do have to say I have not quantified things but have generally noticed improved performance (increased WAF, less downtime etc).

I think I said this somewhere else, maybe even in a response to you...

The Hub, when it's working well, is fast.. whatever number that is.. maybe 200ms (1 fifth of a second). Multiple hubs is not going to change that speed. What multiple hubs do, however, is:

shorten the queue. If 20 devices need to be turned on/off at 9pm, then 9pm is a choke point. If it happens that those 20 devices are split between 4 radios (2 Zigbee, 2 Zwave) on two hubs, then clearly the 20 devices are going to be 'touched' much more quickly.

Pile on some more "9PM" automation in the form of background Weather, sending all 20 changes to Homebridge, etc. then more processing seems to be potentially large net positive.

Of course, "9PM" is just a placeholder for one of hundreds of events per day we are happy to have our hubs do for us. :slight_smile:

2 Likes

Thanks. I'm about 160 z wave and only minimal zigbee devices (but with a good very functional mesh). The idea of splitting to two z wave zones seems to make sense. I'm going to play with recording response times under system stress and in response to the rule based automations over the course of a few days to set a baseline and then go for it! Nearly there with some very basic tools to do this from my pc - learning a lot about javascript and how to communicate with the hub (so has some benefits for me).

1 Like

Well certainly report back what you find - I would be very curious.

I know HE's position (at least it was) is that multiple hubs shouldn't really be necessary.. and indeed I believe from following these forums that there are (many?) users who are happily running with lots of devices (100+) under one hub with apps etc.

It's probably true that with what I know now I could put together a stable hub that covers the medium/medium large size house (2500+ sqft).

It's just that based on personal experience I feel more comfortable recommending at least 2 hubs to people especially if I am going to be the first line of support.

1 Like

I believe that too.

There are very few of us that have considered a multiHub solution. I purchased my first Hubitat and JOINED it to my already existing 4 hubs. I then worked to eliminate all hubs except Hubitat successfully. Multi hub is maintenance heavy... if only remembering which hub which device is on. :slight_smile:

But my life to that point was 'hub full'.. it's no wonder that I gravitated to multiple Hubitat hubs. :smiley: A single Hub just isn't complicating my life enough :smiley:

I think a big component of satisfaction is something @april.brandt mentioned, I believe... she suggested to a new user that they may want to move their Motion sensors closer because Hubitat is so fast. That perception of exactly when the automation should kick in, and the ability to adjust that, is a big factor. I have a couple of places where I can't adjust the 'trip zone' and I really just need a consistent speed. And at $50 a motion sensor, a Hub is not a dreadful alternative :slight_smile:

2 Likes

Its that final few yards that make all the difference - the system is "almost" perfect, reliable, fast rarely needs intervention. Just that occasional time a door is opened and a light does not come on instantly or I walk into a room and nothing happens drives me (and my wife) nuts!

Today I've not had to use a single switch or ask Alexa to do anything other than select music for me. No dashboard - not thinking! I don't want to break it but somehow think I need to experiment .

I think at the very worst performance will be similar but based on others experiences it should be improved - but to your point (and definition of 'improved') I can't say conclusively.

Let's not forget the other multi-hub strategy, using a Hue hub to isolate bulbs and Caseta for button controllers. Both of those offload device management and in the case of the Hue hub makes for a more reliable ZigBee mesh on HE.
On another note more on topic, I already have a three node mesh Wi-Fi network it would be easy to hang another HE hub off the other two nodes to give me three micro cells for my Z meshes. Would they be three separate Z-wave / ZigBee networks or would the other two hubs just be node/repeaters?