Two (or more) Hubs questions

šŸ“¢ Feedback Feature Requests
35

My Third hub doesn't have much to do. It's primarily got the task of receiving the flood of events from the other two and distributing that to the subscribers. And, no surprise, the subscribers are all pretty much the same. Dashboard and Homebridge Fundamentally do the same thing... "Rec: SwitchX on" and then either change the color of a tile or spit out a message to the Homebridge server. Alexa.. same.. but different. Message format is probably the entire difference :slight_smile:

I have almost no rules, which is a surprise, I had been thinking I'd do more with all these "common apps" but mostly just the annual Rules for the Thermostat.

I guess the 3rd hub has little to do OTHER THAN protect the other two from clogging up :smiley:

36

The idea seems really compelling - yes maybe a little overkill but worth it for stability and issue separation. Also I would prefer to keep my internet/cloud apps isolated to just that 3rd hub.

I am really all in on the "keep it local" mantra..

Distributed processing FTW!!!!

37

Yeah I am only really using it for illuminance triggering nothing else.. maybe temp or weather conditions in the future.

38

I decided to overcome the limitation in the Garage Door Opener in this Three Hub scenario.

The problem is Link to Hub will only add the Garage Door Opener under the Contacts heading. In other words, it transfers the status of the Garage Door Opener and doesn't allow the Dashboard Tile on the Third Hub to be a button, meaning I cannot open / close the Opener.

Inspired by a driver @ogiewon created, Virtual Illuminance Sensor, which @Cobra modified to become a hybrid presence sensor... I created a hybrid Garage Door driver. It combines three Capabilities:
capability "Garage Door Control"
capability "Sensor"
capability "Switch"
and all three are interlocked and activating any one, activates all of them:
sendEvent(name: "door", value:"closed")
sendEvent(name: "contact", value:"closed")
sendEvent(name: "switch", value:"off")

Then I created, on the Third Hub, a Virtual device and initially picked the builtin Virtual Garage Door Controller. I then changed to use my hybrid driver. Now, I was able to add this to Link to Hub as a Switch to send it to the Downstairs Hub (where the real Garage Door Opener is Joined.) A simple Rule tracks the Switch setting and causes the real device to open or close.

Then in Dashboard, (which exists only on the Third Hub) I was able to add the Virtual Device as a Tile using the garage-control template. Now it Looks Like the tile I had there, but actually works.

I felt I had to do this because I looked at the Dashboard the day before and saw the Garage Door is Open, yet pushing the tile does nothing.. natively it's a Contact so of course it isn't two way. I had to go into the Downstairs Hub's device page and push the button there. (So much work, yea, I know.. spend a hour to save myself 20 seconds.)

The builtin Virtual Garage Door driver mimics the physical garage door by going through the phases.. closed, opening, open, closing, closed. My hybrid driver isn't doing that because it's just a mimic, not real, but it's on my wish list :slight_smile:

3 Likes
39

@mike.maxwell any update on how having a separate HE for hue is working out? Any definitive advantages/disadvantages?

40

It's not just hue over there, it'a all my zigbee bulbs.
So far I have the following (all the groups have zigbee group messaging enabled)

First Floor (the bulb hub is located here)
Living room:
4x LEDVANCE (sylvania) BR30 RGBW and 1 OSRAM LIGHTIFY BR RGBW in a group
2x Philips LST002 (hue RGBW strips) in a group
2x Philips LLC010 (hue Living colors) in a group

Second floor
Office 1:
1x Philips LCT001 (hue lux)
1x IKEA of Sweden TRADFRI bulb E12 W op/ch 400lm (candelabra bulb)
Office 2:
2x Philips LLC011 (hue bloom)

There's one final group that includes all of the above bulbs and is only used to turn off all the lights
That's it, no repeaters so far

I've lost control of the lux in the office once or twice, it's come back on its own, so I could probably use a repeater near this room at some point, I'm specifically avoiding adding one right now as I just want all these bulbs to play together for the time being and see how well they do.

If all these bulbs were on my main hub with all the zigbee sensors, and the few zigbee actuators I have it would have been a disaster, i know this as this was the case a year ago, with half that many bulbs...

I've not had any issues with group messaging, and other than the office, no control issues.
There are no automations on this hub, just the devices, the group app and a custom hub sync app I've been poking at in my spare time.

I have a lot more bulbs to deploy. just haven't had the time to add much more to the mix.

41

@mike.maxwell
I've read that @srwhite is working with @chuck.schwer on 'improvements' to the Zigbee implementation and that something to do with # of Repeaters and something about Route Discovery are being explored. I'm wondering if you're testing that version? I'm wondering because "lost control of the lux in the office once or twice, it's come back on its own" isn't hugely different from srwhite's reports 2-3 weeks back.

42

Sounds promising, do you find the communication to be faster or more reliable than the hue integration? I realize that firmware updates would be the key advantage to using the bridge, but other than that it seems like a needless extra link in the chain if HE can handle it directly?

43

I've been running the zigbee improvements for for the past week or more and did much of the lab testing of it. The bulb hub currently doesn't have enough of a bulb count to hit the issue that we fixed.

To hit this issue one needs 20 or more zigbee actuators, then a group with no group messaging, that fires commands at the lot of them...

2 Likes
44

It's a mite faster maybe, nothing noticeable, reliability seems same, I never had reliability issues with our hue integration. It's nice to be able to do group messaging without having to do them in the hue app.

1 Like
45

So I'm planning to experiment with a 3 hub set up this weekend (having taken advantage of the deals before the new hub launched).

Although an almost entirely z-wave (plus) system which work very well with 160+ devices, there are occasional times when the system walts for several seconds (and occasionally up to a minute or 2). I'm not sure if this is a z-wave mesh issue but realize I'm getting to the edge of the usual size of a single z-wave set up.

My proposed set up to cover our 4,000 ft house - with attic and basement is to separate into 2 independent zones (ground floor and basement and upper floor/attic) with a centrally located hub with z-wave and zigbee active. A third hub without zigbee or z-wave will act as master controller for complex automations (whole house or multiple zones) and dashboard feeds.

Any simple automations controlling single devices or groups on the same floor will be controlled from the dedicated hub. Each hub will be linked to the controller hub and communicate status only back to the master hub.

Any thoughts on how to optimize this or pitfalls you can see as I embark on this?

I know there's the if it isn't broken break it instinct at play here - but this is a hobby after all and I've been getting bored with the amazing reliability over the past week and increasing ability to have useful automations. This will also allow me to introduce more sensors which seem key to making the automations user friendly and reliable.

46

I can tell you what I've done and can point out the restrictions.

The split wants to to be imagined as if the property was "two tenants" ( a pair of rental properties.) The Rules are going to work best on the same Hub as the devices. In a few cases, a specific device will need to be on the 'wrong' hub. Example: A stairway between floors with a motion sensor at the top and another at the bottom. The light is controlled by the motion. But a strict "split by floor" design would have one motion and the light on one Hub, with the other motion on the other Hub. This is an easy example of putting all three devices on a single hub and make the Rule a fraction clearer. (I want to be clear: it's not a 'sin' to leave them split across two hubs, but as you'll read later, it uncomplicates Events.)

Splitting also needs to accomplish a pseudo load balance. You've paid for the Hub, keep it busy. :slight_smile: Or better said, try and keep them equally busy. It's the Radios that are the current limitation, try and be aware of the impact of having a lot of devices 4 hops away.

Many more "External Apps" than I initially predicted, work fine deployed on both 'active radio' hubs. It is clear that google, and alexa aren't happy to have 2+ hubs on a single account, but I expected the same with... Lutron, for example. Wrong :smiley: Lutron not only works, it works as spectacularly on multiple hubs as it does on a single. Homebridge surprised me too, works on 2 hubs. (But I use it only from 'coordinator')

Amazon Echo Skill, Chromecast, Homebridge, Dashboard all live on my 'coordinator hub' along with NOAA Weather Alerts, Homebridge, ApiXU.

Link to Hub and it's mate Hub Link have two important restrictions. First, you would put Link to Hub on both of your 'active radio' Hubs and Hub Link on the 3rd (coordinator) and send events to the coordinator. You choose the "real" devices on the 'active radio' Hub(s) to send to the coordinator, But sending events
the other way: from the coordinator to the 'active radio' hubs is a problem. Link to Hub is a single instance and so it can only send to one Hub Link instance, not two. You will want to plan which 'active radio' hub needs the most traffic from the coordinator. Said another way... Link to Hub can be deployed a total of once per hub. It sends to one Hub Link, (which also can be deployed once per hub, but IT will listen to multiple hubs, which is how this works at all.)

The second restriction with Link to Hub is that it sends a limited set of Events/Attributes. Switches, Contact Sensors, Dimmers, Motion Sensors, all work great. But Locks and Garage Door Openers don't.

A Garage Door Opener, to take an easy to describe example, has two Attributes shown in the Device Info page:

Current States
contact : closed
door : closed

So it's a dual device, a Contact Sensor (think: tilt) and a door device (think: open/close), yet on the Coordinator, it will show as ONLY a Contact Sensor. You can display that it is open/closed but you can not make the Garage Door Opener operate. (Virtual switches and some RM works around it.)

Therefore, be prepared for workarounds to overcome the two Link to Hub restrictions.

[ giant long answer already... I'll stop now. :slight_smile: ]

2 Likes
47

... Link to Hub can be deployed a total of once per hub. It sends to one Hub Link, (which also can be deployed once per hub, but IT will listen to multiple hubs, which is how this works at all.)

But this is expected behavior correct? In other words - it would only be an issue if you were trying to send stuff from one remote hub to another directly. From any remote hub to the coordinator is okay?

I currently only have 2 hubs talking to each other but I do have a 3rd and your setup is very interesting especially for the cloud apps.

48

Yes. It's a restriction, that's all. Something to be aware of and work around.

Hubitat Staff are more than aware of this, yet any fix has the lowest priority because it applies to so few people (so far... :smiley: )

49

I have been preparing for the switch to multiple hubs for a while now.

One thing I have noticed is that (at least with a C4 hub) if the hub gets too stressed the zigbee shuts down. (Sometimes requiring a reboot to get it back)

Therefore, my design is slightly different.
I have quite a lot of zigbee devices (around 80)
I have only a few z-wave devices. However, 5 of those devices are very ā€˜chattyā€™ aeon hems which work best when joined securely (this causes lots more traffic than an insecure join)

So, for me..
One hub for zigbee devices only (no apps to stress the hub apart from link to hub)
One hub for my z-wave only (with a dashboard showing my hems and link to hub)
My third hub will be my ā€˜coordinatorā€™ hub with app my custom apps and cloud apps on (and no usb sticks)

Iā€™ll use a combination of link to hub and maker api (with an easy to use http driver Iā€™m working on) to allow the coordinator to control everything (although some maker api ā€˜failingsā€™ are making this a little difficult)

My fourth hub, yeah, Iā€™ve got 4 of the damned things, is my dev/test hub
(Actually I have 6 but two are UK C5ā€™s and have bad firmware on them so are bricks. As far as Iā€™m aware they were the only ones in existance until I trashed them.)

As Iā€™m in the UK, we get separate usb sticks for z-wave and zigbee so my ā€˜deviceā€™ hubs will only have the relevant usb stick inserted and enabled.

It takes a lot of work to plan and get everything right but I hope to complete this very soon

Andy

1 Like
50

Thanks - I read your story carefully. I'll reach out when I get stuck! I am wondering if there is a way to test performance before and after the changes. Would timing of response from a command issued to a response returned be a useful measure? Any apps that manage this? Should we create one?

I'm a research scientist so I like hard data / measurement rather than relying on my subjective opinion.

1 Like
51

How about we design a small app to measure our response time and perhaps other metrics before and after we give this a go? I know you have the programming skills and I am dangerously ambitious when it comes to my javascript attempts.

52

What is the purpose of having multiple hubs?

How does it all work with more than one? Do the hubs run separate Zwave/Zigbee networks? Or are they both in the same one? Who sends/receives commands?

I may want a second (or third) hub in my house. I have fairly large house - single floor - and I have frequent issues with commands NOT getting to the hub i.e. turn on Master Bath Light from switch and hub never "sees" the event. Thinking maybe second hub on opposite corner of house might help, but not sure what that "looks" like when done. Do some devices connect to one and others to the second? Do automations work across both? Lots of questions, sorry.

53

In my case (2 hubs - basement & 2nd floor) it was to hopefully make things stable as possible by distributing processing, devices and the networks. Yes each hub has it's own unique ZW/ZB networks (you can set the channel for Zigbee if you want).

You connect them via "Hub Link" and "Link to Hub" apps.

You will still have to connect each up to your regular network - if you don't have wiring to the remote hub you can use something like Powerline Adapters to extend your wired network.

The current drawback with using hublink/link to hub is the limited devices you can expose things like switches but no thermostats etc.

I try to keep all my rules and apps related to devices connected to each hub on those specific hubs - meaning my 2nd floor hub rules/apps control my 2nd floor devices and my basement hub rules apps control my basement, first floor and garage devices. I only have certain virtual devices that talk between hubs.

In your case it may be a little trickier since you will likely have more devices communicating between hubs - I know there are people here that have done it that way..

54

Begin by imagining two hubs that are completely independent. Say one Hubitat, one Wink. There's no confusion there, ok? They have independent ZWave and Zigbee mesh networks. They all share the same radio frequency band, but by managing Zigbee channels, WiFi channels, Hue channels, they can all be made to play side by side. I think that answers the "Who sends/receives commands?" right?

Now in your mind, replace that Wink with another Hubitat. Everything else is the same.. they are fully independent. You pair/join devices to their respective hub and never the twain shall meet. If Hub A knows about Device 33, then Hub B does not.

So far, everything I've written is focused on the RADIO side of the hub. Two Hubs, equals Two Zigbee meshes + Two ZWave meshes. And this is important because you must manage the repeaters for all 4 of the meshes, just as today with one hub, two meshes to maintain.

OK, now it's time to throw in the linking of the hubs. As @erktrek said, Link to Hub and Hub Link are paired (sender/receiver) builtin apps. You identify devices in Link to Hub and they will appear on the hub that is running Hub Link. If you flip it around, and have each hub run one of each, you get bidirectional linking. All of this is occurring on the LAN side of the Hub(s), completely unrelated to the Radio side of the hub(s)

This alone is not a reason to get multiple hubs. Mesh management 'should' take care of this. A perfectly square 5000 ft home is 70 ft on a side and if the Hub is in the center, 35ft to 45ft radius can be achieved with a routing device in each quadrant. But then who as a perfectly square house? :slight_smile: The point is it doesn't take much to get a decent mesh in all directions. There's a 4 hop limit with ZWave, BUT the mesh is built by the hub with the intent of making the mesh 'reach' as far as possible.

Imagine three routing outlets... in a line, 12 ft apart, the first 12 ft from the hub. The hub MIGHT choose to route through the Last outlet. All 3 are within range of the Hub, so it chooses to route through the most distant device. Someone on this forum said "we need RF goggles" and WOW would that help :smiley:

But now to the final part.. how to implement. For @erktrek and I and probably most others, we started with one hub and connected everything to it. Perfect. But the limiting factor of any hub is the radio because (relative to everything else in our tech lives,) ZWave and Zigbee are slow. Thus the radios simply cannot crank out zillions of packets per second. By doubling up on hubs, we double the radio's ability to crank out packets. We probably reduce routing hops and that improves performance too.

Split your existing collection of devices along logical lines. You want to begin with them being as independent as possible. Then via the Link, you can push status to the opposite hub to be evaluated in Rules and affect your automations. Because the Linking part runs over the LAN, which is usually gig speed, (your home may vary :slight_smile:) you can pump a lot of status back and forth.. BUT as has been mentioned, you can't move ALL status. Some devices will only transfer a single attribute. That drives the restriction of being as independent as possible. Let's say you have a device that gives you Humidity readings BUT Link to Hub doesn't include that... then you cannot use that Humidity value on the opposite hub. It doesn't get there. {Workaround is to put the humidity value in a virtual dimmer and use Link to hub to get the value to the opposite hub. }

Long enough, I'll stop now. :smiley:

7 Likes