I have a ST (US) hub with several US Z-wave sensors. I'm thinking of getting two Hubitat (AU/NZ) to manage AU Z-wave and Zigbee sensors. One of the Hubitat hubs will be a HubConnect controller to the ST (US) and Hubitat (AU/NZ) hubs.
Will this work, especially to control US and AU/NZ sensors through the controller hub?
Thanks.
It will work for as long as HubConnect is supported by SmartThings.
As an alternative, since you are getting two Hubitat Elevations - why not run one of them with AU/NZ frequency z-wave, and the other with US frequency z-wave? Zigbee uses the same frequency world-wide - and you could use either one for that purpose. HubConnect is guaranteed to always work in this scenario.
Tagging @csteele - he'd know better that I do if this will work.
Yes, as long as ST maintains their Groovy IDE or HubConnect is updated to the new SmartApp and DTH model. A few unknowns there for the future, but definitely yes for now. However, I'm not sure I understand the need for your dedicated "coordinator" Hubitat. You only need one Hubitat somewhere in the mix to act as a server. SmartThings can be the only client, or you could add yet another Hubitat or any combination. Just wanted to make sure you weren't starting out overly complicated.
Second, you may be interested to know that the C-7 hub can change Z-Wave frequency. You'd have to pick one region to use but can change it via software. So, while I'd advocate following local regulations, a second "Australia" (or any) C-7 hub could replace your ST hub too if you only need it for Z-Wave. That would get the ST cloud out of the picture, too.
...or basically what was said above as I was typing. 
I was under the impression a Hubitat was either client or controller. I'm on a crash course in understanding Hubitat and HubConnect.
I'm moving away from US Z-wave, now that everything is operating in AU, just wanting to make the move gradually and not in one expensive outlay.
Much appreciate the sharing, all is so much clearer with the reply.
Yes, @aaiyar it works. HubConnect has no knowledge or interest in the state of your Z-Radios. Enabled/Disabled, 1 device or 100 devices, HubConnect has no need to know. 
HubConnect is interested in Devices (their Attributes) and Hubs.
HubConnect's prime duty is to 'mirror' attributes from one hub to another. But attributes are part of a device, so devices are what get selected and form the focus of 'mirroring'.
Thanks.
That was the intent but I am moving away from US Z-wave and I'm now residing in Australia. Just have a gradually invest in AU devices to stay within local regulations.
That sounds like Home Assistant.
I had a glimpse of the following -
which led to my impression that I needed a coordinator hub.
Thankfully that's cleared up here, so I can start out with a simple setup.
There's many ways people have chosen to architect HubConnect to join their hubs. I doubt one is better than the others because each is built to solve THEIR concerns.
I believe I created that drawing a several weeks before HubConnect was release back in March of 2019. It is/was a drawing to illustrate the architecture that Steve and I had implemented.
The drawing GREW a week later to:
The addition of HubConnect NodeJS proxy Server can make the array of choices quite a bit larger. An 'tutorial' picture would show the NodeJS "hub" in the middle of all the connections, but of course not all hubs MUST pass through the NodeJS proxy Server. It can have from zero to all.
Well, I'm glad I did not see the "grown" diagram earlier. I would have been on a path to hyper-complexity. 
Download the Hubitat app
