I think there's that possibility. However, Z-Radio packets are tiny and there are giant gaps between the bursts of legitimate data. In other words, the possibility of interference is approximately equal to the possibility of no interference. The RF layer of the protocol takes care of those moments of overlap, which effectively increases the possibility of no interference. (Listen before talk + Random backoff.) All of which must be balanced against the known bottleneck of the Z-Radio queue. Gig speed processors knock, knock, knocking on a Z-Radio door of 250k max and slower quite often. Parallelism wins in that balance, I find.
Another way of viewing it is gig speed processors knocking on multiple 250k radio doors. "Two doors" probably means a significant gain over a single door, but not 2x as your interference model suggests. "Four doors" means yet another significant gain over a single door, but not 4x. But what if it's "only" a 3.5x gain? Or (shudder) a 2x gain? Clearly it's still a gain. I get more Z-Radio packets per second, functional ones, from my set of 3 hubs than you can from one hub.
Said yet a third way, I think the interference of multiple Z-Radios is managed within the protocol such that there's no detrimental interference. 60 ZWave devices and one hub are all competing for a single radio channel. Interference is mandatory. Doubling the number of controllers to 2 for the same 60 ZWave devices does not exponentially increase interference. It's just 1/60th more.
I have had very good success with 2 hubs by location (never tried 8 though) - one for the main floor the other for the 2nd floor of our house - since moving to the C-7 I'm still using multiple hubs but these are now by function not location (Z-Wave/Zigbee/Network). Also have used multiple hubs by location for clients as well - it's a great way to extend the coverage over larger and/or interference prone areas while reducing individual hub overhead.
One thing I'm doing recently, and if it continues to show benefit I'll share is related to ZWave Refreshes.
I've noticed that when I have an unresponsive Zwave device, if I go to ZWave Details and click Refresh, the device goes from nonresponsive to instantly responsive. So I built something that goes through all of my Zwave Repeaters each night and essentially clicks that Refresh button. I haven't had a single Zwave issue since I started doing this.
One very important hub indeed. I know all the reasons that we can't have hubs shadowing or mirroring each other...but boy this screams for it.
I've got two for logistical reasons and a fraction of the overall device count...even with that I'm praying that if either ever dies that I'm available to address it expeditiously.
And here's hoping that some % of the responding ideas eventually get incorporated into HE and become system features, or keystone Apps that people are encouraged/guided to use. This to me is in the category of improving fundamental reliability, not a community add on. And that includes the great "haven't heard from this device lately" apps people have written.
Said with total expectation of a full volley of 'but it's all there in the community apps'. If we know it bolsters reliability, and it can be integrated, then just do it for a better off-the-shelf platform and maintain it under the product umbrella. He says after reading folks concerned about 2.2.9's impact to their Apps.
