GH is a mess if you try to put multiple properties into it. Although it supposedly supports multiple "homes" I've found it sucks at demarcating the devices so that if you are at one property you don't inadvertently activate a device at the other property. Maybe this is just me or because I have the same WiFi SSID at each location. In the end I've set up 2 separate Gmail accounts, one for each property and am managing them separately, with 1 hub at each. Now I just wish the Hubitat account properly supported multiple locations/hubs instead of only supporting a single location and getting confused as to which location applies to which hub for the geolocation service.
That's pretty close to what I'm doing, too. Although Google integration is on one of my 2 'radio' hubs. I have thought about moving it to my 'cloud integration' hub, where it belongs in my architecture, but have been too busy to do that.
Not sure I really need to change anything, per se, but while I was setting up the CATT app to use dashboards on my Google Nest Hubs it made me wonder what other multi-hub owners do.
I have one hub I use for all cloud connections, and one I use for my zigbee/zwave devices (they are connected via HubConnect). But it doesn't "have to" be done that way.
The downside to having Google Home on the "cloud" hub, is I basically have to repeat EVERY device from my radio hub to the cloud hub so that Google can control it. That's a lot of devices to share back and forth.
(EDIT: I guess not EVERY... Just every device I want Google to control... For instance I don't share my leak sensors, smoke alarm, locks, etc... Mainly just lights, ceiling fans, and thermostats.)
Nice, one more question. Which hub do you create general virtual switches that connect all devices on (.i.e. birth switch) ? Like a good night switch.. Do you run rule machine on your hubconnect server for use cases that touch multiple devices across different hubs?
Okay, that makes sense when logically assigning rules to hubs. I think I'm going to to create my shared virtual switches on the actual hub connect server and share the switches with the child hubs for RM rules running on those hubs.
Okay, I didn't realize your HubConnect server and the hub you run cloud services on are actually the same physical hub. I was thinking of breaking these apart to keep the HubConnect server running fast isolated from slow running cloud service apps.
You obviously COULD do that - no technical limitation there. Not sure it is really needed/useful though.
Especially when you fast forward to the next version of HubConnect where you may choose to do the HubConnect proxy/broker/external filtering server (whatever steve is going to call it). I'm fairly sure that is how I'm going to architect mine, once hubconnect 1.7/2.0/version.next comes out.
Roger that. I didn't realize these events were being broadcasted to all hubs regardless if I'm sharing a particular device. I think in my use case I am protecting from bad apps causing slowness, so basically I'm going to have a dedicated hub for CPU hungry apps.
That, of course, depends on how you setup HubConnect. If you use the "socket" connection, all device events for all devices go between the hubs. It can be a great way to do it if you are sharing a LOT/all of devices between hubs.
If you do the HTTP connection method it only sends relevant events, which is a lot less overhead if you are only sharing a smaller number of devices, but doesn't scale as well if you are sharing dozens of devices.
The upcoming proxy server is kind of the best of both, but its negative is that it requires the proxy server to run outside of HE - on a raspberry PI, docker, etc.
I'm using the socket method, it appears to be lightning fast. Personally, the whole point of setting this up was to increase performance and to prevent slow hub periods. I'll take a look at the article. Which method are you using? Any delays when using HTTP connection type?
I currently use socket on all 3 hubs, but I have one hub that only needs to share 2-3 devices so will likely switch it to HTTP instead. HTTP is just as fast.
I'm actually testing an issue right now that seems to kill the hub when using hubconnect via socket method due to a different integration - MQTT - making such a high volume of events that the other hub can't process them fast enough.
If I implement the hubconnect proxy server (when it is released) then I'll probably do all of them that way instead of having some socket/proxy connected and some HTTP connected.
I like the idea of an external proxy processing/filtering the events and then sending only relevant events, as the machines I would run externally are MUCH faster than the hubitat hardware. So it should reduce hub loading overall pretty substantially.