@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.
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?
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
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
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.
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. 
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 
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. ]
2 Likes
... 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.
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... )
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
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
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.
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.
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..
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? 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
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 ) 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.
7 Likes
So if the challenge is only distance perhaps repeater devices are the "better" (simple+effective) solution.
If the challenge is a large number of devices or a large amount of processing multiple hubs may be better.
Over-simplified?
Yes, for an oversimplification, it's a winner. 
1 Like
Distance is not the issue. The mesh is the issue (I think). I have 120+ zwave devices - mostly wall switches and plugs that are always on and repeat.
I believe my mesh is too noisy maybe? I have run zwave repair - many times - but that doesn't seem to get the slow reporters to work any better. I'm actually replacing one zwave dimmer with a zigbee repeater tonight - because my zigbee network is MUCH faster.
Amazing response - thank you very much!
Sounds like I need to split my house in two and add a second hub (maybe a third). Is there a way to set a zwave channel? I know how for zigbee. I don't have any hue.
Makes sense on the Hub Link and Link to Hub - even for devices that don't relate.
What about automation - all on one hub? or half on each? I would think managing as much as possible from one would be better - though if it died, you'd have to recreate everything on the other.
Here's another thought. Would it make any sense to use an old ST hub as a second hub? I'm thinking just for radio traffic and do all integration and automation on the HE. Thoughts?
My design is three hubs. One for each floor, rather a lot like @erktrek but there's no such thing as basements here. Just down stairs and upstairs. I call my third hub 'coordinator' because my initial reason for architecting it was to hold all of those 'bad apps' that cause slow downs. Rule Machine and it's brethren have never made it to the 'bad app list' and so I have them running on EACH of the 'floor hubs.'
[ Link to Hub in the drawing is bidirectional]
All of the automation is running on the 'floor hubs' with practically no automation that needs elements/values/data from any other hub. It's pretty easy really, bunch of motion / door sensors and their lights/sockets. Easily 90% would never need to go hub to hub. Although you're going to split the home 'side to side' the same applies. Open a door or window here and the other side (other floor) of the house has no need to know.
Same with the 'coordinator' all of the automation on it is related to the devices that are attached. I do not have a ZWave Thermostat, mine's WiFi and although I do have a driver for it, my need is simply to automate the one missing feature.. seasons... where the thermo needs to change from heater to A/C and then 6 months later, back again. I have ApiXU on it, because it's on the 'bad app' list (even though it's just a driver) and I have automation to set virtual switches for things like "gloomy day".
You will note from the drawing, there's no 'side to side' communication. The two 'floor hubs' cannot speak to each other. This is another limitation to Link to Hub. But truthfully, it's a miniscule limitation, I simply route from one 'floor' to another via the coordinator. As I said above, that side of all of this is super speedy.
2 Likes
