My 2nd hub is still sitting in its packaging. Its role will be to host my Aqara stuff with their compatible repeaters.
I assume the best way to integrate both hubs is with Hub Mesh app? What is the best order to do things in? Set up the new hub as standalone, and then install Hub Mesh on both (does it run on both?) and link them? Or install Hub Mesh almost as soon as the new one comes online and take it from there?
Will be using the new hub for its zigbee mesh only and all rules and apps will continue to be run from the original hub. Will events from my Aqara sensors be pushed to the master hub in a timely way - they don't wait to be polled do they?
You’re close. Don’t actually need to install Hub Mesh, just turn it on for both hubs after making sure that mesh Communication Protocol for both is either TCP or UDP. Then it’s just a matter of sharing the device from the host hub, and asking Hub Mesh to create it on the recieving hub.
And what sort of traffic is there over the LAN? Are they polling each other constantly to stay in sync or do they keep themselves to themselves until an event causes them to need to talk?
Haven’t put a sniffer on it but my impression is that traffic is fairly light, and seems to be event driven. Having said that there is also a configurable full device sync interval (default every 2 minutes) that runs.
I made the mistake originally of meshing all 500 of my devices (many virtual) from one device to the other. Had I read the documentation first I would have discovered there's a practical limit of about 200 devices otherwise it may generate excessive load on the source hub. I also noticed when I reduced my number of devices from 500 to the 50 or so I actually needed, hub performance improved and I stopped getting unexplainable Zigbee radio shut down messages.
UDP should theoretically yield better performance than TCP so if UDP works go with that.
Hub Mesh is ultimately just a way to share devices (or modes or variables) from one hub to another over your LAN. From your first post, it sounds like you plan on leaving all apps on the other hub. So, there is nothing you need to do besides share the devices from the new hub via Hub Mesh, add them via Hub Mesh on the original hub (devices you share don't get automatically added on other hubs), then use them in apps and whatnot on that hub. By that point, they are just regular devices on the other hub as far as apps are concerned.
There is no need to share anything from your original hub unless you want to use something from that hub in an app on your new hub. But again, you will still have to go into Hub Mesh on the original hub to link the shared devices to that hub.
Another way of interpreting "UDP" is to say: "I don't care if sometimes it's ignored or lost"
Because that's inherent in UDP, there are many messages here suggesting this or that person try TCP. I suspect that, over time, UDP will be reduced as an option for HubMesh.
Hmm perhaps. On the other hand UDP is more like "here's some stuff" vs TCP which is more like:
Hub 1: hey I'm gonna send you some stuff
Hub 2:OK you can send me some stuff
Hub 1:Sending you stuff
Hub 2:I got the stuff
Hub 1: Did you get the stuff in the right order?
Hub 2:Yeah I got the stuff in the right order.
Hub 1: Thanks, have a good one!
Hub 2:You too!
(For illustrative purposes only. Not mean to actually describe the TCP data flow.)
It also depends on how you plan on using your hubs. "By location" - two hubs in separate parts of your location is a good way to go.
You can pair each hub with devices closest to it which provides stronger localized meshes and less hops per device.
You can keep local rules local to each hub which helps with your automations should one hub go down and reduces overhead on both hubs. Migrating or rebuilding is a lot easier with less devices
You can use HubMesh for rules or dashboard that might need access to devices on both hubs.
Downsides:
you need an ethernet connection for each hub location.
Smaller areas may not benefit as much with this, instead consider by protocol - one hub running Z-Wave the other running Zigbee and Internet/Cloud apps.
A number of people have suggested this and your have to explain why? Because to me it absolutely pointless, they are two separate radios each with there own and separate IO limit. The hub is more than powerful enough to run them both so why would you have two hubs one using ZigBee and one with z-wave. In terms of possible speed that's exactly the same as one hub.
Now two hubs in two locations doing there local z-wave and ZigBee devices, hell yeah great idea as you doubling your IO limit and each area has its own processing power.
Even a hub with the radios off doing all the heavy lifting to the cloud ect makes sense, just not only using single radios per hub.
Nice ideas but not really applicable in my case as the 2nd hub was specifically to ringfence my Aqara stuff to stop it making the rest of the system unstable.
Yep they're both on the latest. Interesting discovery is that what you put in the Label field for a device on the host hub becomes the Name field on the receiving hub (with "on [Other Hub]" appended) and can't be edited on the receiving hub. But that's fine I have learnt how to use it in a way that works for me. Just strange that name field !-> name field!
