What are others with multiple hubs doing for Google Home integration?
So far I've been using HubConnect to get devices all on one hub, then just have Google integration on that one hub.
That works fine for simple devices (lights, switches), but last time I tried it with a repeated thermostat it didn't work well (maybe things have changed, it's been a while).
If I remember correctly you can't link multiple HE hubs to a single Google account.
Other thoughts / options?
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.
I use hubConnect and have a separate ‘media’ hub.
This works really well for me
The hub has:
GH minis (6)
Echo speaks devices (6)
Sonos Speakers (2)
All along with all my ‘speaking’ apps (message central, speaker central & mp3 player)
This means if any of the devices or apps pull the hub down then it does not affect any other hub.
Andy
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.
Do you guys put the Google assistant integration on the HubConnect server itself or do you have an isolated hub just for cloud services? Likewise for Sharptools.io?
Everyone does it differently.
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.)
But it seems to work fine.
So basically you share a zwave device from a dedicated hub to the HubConnect server hub and then push the same device to your "cloud" hub? A to B to C, right? Thanks Jason.
Yup.
Radio hub <--hubconnect--> Server Hub with Google Home integration installed, and I add the virtual devices hubconnect creates on the server hub to the Google Home integration.
Examples of things I stick on my server hub:
So basically anything cloud based, user driver/app, or LAN connections.
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?
I run RM on both hubs. That said, I typically put the RM rule on the hub the device is physically on.
So if it is a rule only for LAN/cloud integrations (like pool bleach tank alarm via Hubduino) I would put the rule on my Server hub.
If it were something like a Goodnight rule and mainly lights/locks, I would put it on my radio hub.
If the rule uses devices from both hubs, I usually put it on the hub that has the most physical devices used in the rule.
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.
That makes sense. I don't use any virtual switches w/google home, but if I did I would probably do it like that too.
Thanks Jason. Curious, do you run RM on the HubConnect hub itself for any use cases?
As I mentioned, I use RM on all of my hubs.
If it is a rule only for LAN/cloud integrations (like pool bleach tank alarm via Hubduino) I would put the rule on my Server hub. (my server hub is probably what you are calling the "HubConnect hub")
If it were something like a Goodnight rule and mainly lights/locks, I would put it on my radio hub.
If the rule uses devices from both hubs, I usually put it on the hub that has the most physical devices used in the rule.
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.
Steve's post here illustrates that nicely:
Download the Hubitat app
