I haven't seen much discussion on Hub Mesh strategy in a while, so I thought I'd start a new thread. I'm embarking on a move from a single C5 hub to a three-hub mesh (C5, 2x C7s). I've seen past discussions debating how best to distribute & share over mesh systems, and I was wondering if there is any new experience out there.
One topic of interest: I'm thinking I'll use the C5 for slower/less-reliable network services (Sonos, Noonlight, Life360, etc.), hub variables, and other 'centralized' stuff. Its radio might be turned off. Then the two C7s will get the z-wave devices (I have no ZigBee). Devices can be grouped by how they work together - 1st floor, basement, security, outdoor, etc. These generally only overlap (device-wise) with a single contact sensor on an adjoining door. What does anyone think about putting Rule Machine / Room Lighting rules for device management all on the C5 centralized Hub vs. on the C7 hub that serves them? The first way simplifies things, but the second way may allow me to send less device traffic back to the C5.
Second topic of interest: I'm doing this because the traffic on my lone hub is overwhelming to the point of slowing things down. If I move devices to the other C7 hubs and share those devices back to the C5 central hub, am I really cutting down on traffic at the C5? Will all the syncing of devices create just as much chatter as the devices talking directly to the hub? The answer to this might inform me about the above topic - it might provide an advantage to 'hiding' devices from the central hub by putting their automation with them.
Third topic is related - what about dashboards? If I want all my dashboards on one hub (for quicker/easier access), then I'll have to share everything back to it. Possibly defeating my traffic-reduction. If I don't, then I have to open different hubs for different dashboards - sure to get frustrating. Anyone mess around with dashboards in a hub mesh environment and have any tips?
There's not really a right/wrong answer for where things should live. Some will say that keeping the automations closest to the devices they manage is the best way. Some will say that keeping them centralized on one hub is the best way. In the end, I don't think it really matters.
From a processing standpoint, there is a difference between a device that is connected to a hub vs a device that is replicated using hub mesh. As far as I understand it, hub mesh just replicates events such as switch on/switch off. Whereas the hub the device is paired to has to deal with all the backend communications as well (e.g. sending the command, processing the ack from the device).
I don't know that there's any way around having dashboard items centralized. I suppose you could nest the dashboard though. Like having a dashboard from the "main" hub with tiles that link to dashboards on the others. Personally, I use the Android dashboard app which relies on Maker so anything I want in the dashboard is connected to my main hub via hub mesh to suite that purpose.
I have a setup using 3 hubs + a spare (to test stuff).
One is my main hub where all the rules are run and dashboards reside, and which is integrated to Hue, Lutron and the other 2 hubs vie Mesh. The radios are off on that one.
The other 2 are:
Is only used to connect to compatible radio (Z-Wave and Zigbee) devices.
Is used to connect to processor intensive apps or non-supported devices (Aquara, Echo Speaks, Tuya, devices incompatible with 700 series Z-Wave, etc.)
Substitute "HubConnect" for "Hub Mesh" and this discussion was quite extensive back then. The choices seemed to be straight forward, By Protocol (ZWave on one, Zigbee on another, LAN/WAn/Internet facing on a "central'ish" hub that probably had it's radios off;) By Physical (Upstairs, downstairs, and a "central'ish" hub that probably had it's radios off;)
We are very fortunate to have multiple "Execution Engines" available: Rule Machine, Node-Red, Home Assistant, and now, more than ever, WebCoRE. There might not be a need for all, but I'm in favor of more than one. I personally relegate Rule Machine to Single Hub. I use Node-Red for multi hub. And while I still use HubConnect, Hub Mesh will get all your devices to a single "central'ish" hub where Dashboards and other "whole house" actions will take place. Weather is a good example... values are acquired via an Internet connection and if those values are going to influence a Thermostat or a Sprinkler system or just notification that windows are open when it's raining, a central set of rules might be best.
The speed of the Ethernet connection between hubs far, far exceed the Event speed of Z-Devices. So there's no need to worry about interconnecting hubs in the equation. My "system" looks like this:
One thing I'm hearing is that no one is worried that moving devices and meshing them back again is a bad idea. As @FriedCheese2006 indicates, there are savings in traffic to be had by pushing the 'backend' communications to the slave hub. This, I take it, is what would retain the traffic improvements even if all rules were on a single hub. And I suppose the superior speed of the Ethernet connection noted by @csteele would even make the state info that is passed faster than if it were acquired via radio. Thus, simply moving the devices to slave hubs while doing all processing on the master hub should reduce congestion.
It seems like you all like keeping your non-z-wave/ZigBee compatible stuff (including, I presume, web service stuff) away from the straight-up radio stuff. Likewise, you put all your rules together on one hub. Anyone see an issue with those two things (out-of-network services & rules) being on the same hub? Web services (like IFTTT, weather, etc.) seem like they can be dodgy. I'd hate for them to slow down rule execution. It won't matter how fast the devices report in to the master hub if they're stuck in a queue behind a web request.
