Two (or more) Hubs questions

šŸ“¢ Feedback Feature Requests
33

Thank you for your followup!!!!

My upstairs/downstairs setup is also working great! The goal with this has always been stability and simplicity first then adding features as I go along. The less impact on the "device" hubs the better so now I'm curious about getting a 3rd hub as a controller type setup.

Currently my hub link only flips a couple of virtual switches and a water sensor. Have HM running on the main hub. Don't have pushover but using my old sendmail notification device/node app for texts and email.

It's too bad they got rid of the Nest app or I would consider putting it on a 3rd hub as well instead of the upstairs/downstairs ones.

Also I am using ApiXU but have not experienced issues - unless I have without knowing it.. where did this get reported?

34

ApiXU gets a large string and then slices and dices the result into individual Attributes. 24x7 Hubitat designers were expecting Attributes to be small strings, not URLs or images. DB design gets tricky in those circumstances when you're expecting "true", "false", "90" and get results 100 times bigger. Choices made about indexes etc. probably fall apart and then performance falls. I'm extrapolating here.. I have not been given any kind of detailed explanation. Just hints and the hints lead me here.

I've given Bangali the code I worked on to make each attribute optional. Because for the most part, we tend to find answers to our weather needs in 10-15 vs 50-60. The code I created was brute force and not elegant, and I'm assuming he's working on the elegant version :slight_smile:

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.