Google Home with Multiple HE 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.

Steve's post here illustrates that nicely:

Okay, sounds good. I also run a node server on a beefy desktop machine. I'll follow suit once the proxy enhancement is released.

Note: I'm not having any slow downs with socket. I'm having slow downs due to poor performing third party apps.

Happy new year!

Here's the Current states for my two Hubs, as seen from Server/'coordinator':

21%20AM 19%20AM

One shows a savings of about 66% the other is 85% savings.

As previously discussed, Event Socket is "free" to the Sending hub. It's part of the platform and you either listen to it or not. Up until recently HubConnect would listen to Event Socket but would send via http. V1.5 added bidirectional Event Socket. The ideas behind HubConnect Server (proxy) existed in Steve's mind before he went Camping last summer. By moving the filtering off the hubs, you gain benefits of both Event Socket and http (oAuth). Hubs send (for "free") all events to the proxy/Server and it does the filtering that http would have done on the Hub.

With http (oAuth) each Hub pays the price of filtering on sending.
With Event Socket each Hub pays the price of filtering on receiving.
With Server (proxy) no Hub pays the price of filtering, since filtering is done on the proxy.

The "cost" of Server (proxy) is setting it up. It needs an always on computer. Mine runs on a Mac Mini along side Homebridge, although initially I ran it on a Raspberry Pi. While not difficult, getting the config.json is subject to all the hurdles any json has for human typists. :slight_smile:

{
  "hubs":
  [
    {
      "name": "Server Hub",
      "ip": "192.168.7.64",
      "port": 22000
    },
    {
      "name": "ZeeRadioLower",
      "ip": "192.168.7.66",
      "port": 22001
    },
    {
      "name": "ZeeRadioUpper",
      "ip": "192.168.7.68",
      "port": 22002
    },
    {
      "name": "ZeeFourth",
      "ip": "192.168.7.65",
      "port": 22004
    },
    {
      "name": "ZeeFifth",
      "ip": "192.168.7.63",
      "port": 22005
    }
  ]
}

As I've mentioned elsewhere, I have 5 hubs split into 2 sets. A Production set of 3, and a Development set of 2. All 5 feed into one instance of Server (proxy) and the logs are certainly fun to watch. :smiley:

10:13:24 AM  Server Hub --> ZeeRadioLower SENDING: [deviceId: 88, displayName: MultiSenZigbT (garage), name: temperature, value: 63.97]
10:13:26 AM  ZeeRadioUpper --> Server Hub SENDING: [deviceId: 759, displayName: Multisensor6H (masterBath sink), name: lastUpdate, value: 01-Jan-2020 10:13 AM]
10:13:30 AM  ZeeFourth --> ZeeFifth SYSTEM COMMAND: [name: appHealth, value: 1577902411098]
10:13:33 AM  ZeeRadioUpper --> Server Hub SENDING: [deviceId: 759, displayName: Multisensor6H (masterBath sink), name: illuminance, value: 308]
10:13:37 AM  ZeeRadioLower --> Server Hub SYSTEM COMMAND: [name: appHealth, value: 1577902417397]
10:13:44 AM  ZeeRadioUpper --> Server Hub SYSTEM COMMAND: [name: appHealth, value: 1577902419051]
10:13:49 AM  ZeeRadioLower --> Server Hub SENDING: [deviceId: 693, displayName: LaundryRoomWasher, name: voltage, value: 123.877]
10:14:21 AM  ZeeRadioLower --> Server Hub SENDING: [deviceId: 588, displayName: MultiSensor6I (kitchen), name: motion, value: active]
10:14:25 AM  ZeeRadioUpper --> Server Hub SENDING: [deviceId: 749, displayName: MultiSensor6E (upperBath), name: lastUpdate, value: 01-Jan-2020 10:14 AM]
10:14:25 AM  ZeeRadioUpper --> Server Hub SENDING: [deviceId: 749, displayName: MultiSensor6E (upperBath), name: temperature, value: 72.0]
10:14:25 AM  ZeeRadioUpper --> Server Hub SENDING: [deviceId: 749, displayName: MultiSensor6E (upperBath), name: humidity, value: 44]
10:14:29 AM  ZeeRadioLower --> Server Hub SENDING: [deviceId: 693, displayName: LaundryRoomWasher, name: energyDuration, value: 222.58 Days]
10:14:30 AM  ZeeFourth --> ZeeFifth SYSTEM COMMAND: [name: appHealth, value: 1577902471135]

I will mention that if he would have just done it through MQTT he wouldn't have had to make custom proxy at all. What he is doing is basically the equivalent of writing a proprietary MQTT broker.... :wink: A little bit of reinventing the wheel.

Custom Wheels

Popular in the Real World too. :smiley:

07%20AM

1 Like

true

When do we think the proxy server will be available for installation? I'm thinking about rebuilding on this architecture so wondering if I should wait.

It will be an evolutionary change. You will be fine with v1.6 and when 1.7 is released you'll just upgrade and without a proxy, it will function the same.

When you launch the Server (proxy) with a valid config.JSON it will open a WS connection to your hubs. But without the connections re-keyed to use it, nothing special happens. Then as you're ready, you can create and paste in the new key, and as if by magic, nothing happens :smiley: It all just works. No trumpets, no chorus. It's all so pulchritudinous. There's even a new toggle to send the new Key over the old connection. :slight_smile:

51%20PM

Maybe I wasn't supposed to mention that.. aren't teases exclusively @srwhite ?

Stop that. :stuck_out_tongue:

2 Likes

HubConnect 1.7 will be out as a beta within the next week which will include the proxy server. 1.6.4 will still remain the recommended release for a short while until the new release gets some soak time.

I'll let that one slide.. :slight_smile:

+1

+1, beautiful!

Just thought I'd share my setup, though it wouldn't work for everyone. I only have one location, but three hubs. I originally had all devices sent to one hub via HubConnect, and then had that one hub connected to Google Home. But I had some trouble with the repeated devices - mainly my thermostat and sometimes when my hubs were being bad, google home would say Hubitat wasn't responding. Then seconds later the device would respond. Definitely no disrespect to HubConnect, I use it and love it. I believe the delay was the Hubs acting up, slightly compounded by HubConnect.

So now I have 3 google accounts, and each hub is linked individually to one of the Google accounts. Then I've shared all three accounts with each other. This creates 3 "homes". You can put your devices from any of the three hubs into any of the three homes. They don't have to be in the home that was created by the google account / the specific hub.

Downfalls:

  • Setup was a bit of a pain
  • There are now 3 google accounts on my phone, only one of which I use. So I have to be careful I'm signed into the right account / things are saving to my main account.

Benefits:

  • If one hub goes down, I can still access the other two. This is a minor benefit if you've setup your hubs correctly. In my experience, Google Home is pretty stable so it should be on a stable hub. I originally made the mistake of putting it on the "cloud" hub, which was least stable hub of them all.
  • The main benefit - I've significantly cut down on chatter between the Hubs, as most of my sharing of devices was to get everything to the one hub with google home on it. I now share minimal devices between hubs. Google response times are quite a bit better, network chatter is down, and HubConnect doesn't have to put in overtime shifts.
  • The second biggest benefit - with this setup, I have 3 google "home" locations. As described above, any device from any hub can go into any of the three home locations. If you do it strategically, you can "hide" devices. Described below...

Previously, with all devices in one home location, I would need to hide devices. For example, say I have a kitchen light and a virtual switch that controls whether kitchen motion control is on or not. If you name them "kitchen light" and "kitchen motion control", it is likely Google Home will turn both off if you ask it to turn off the kitchen devices. It will definitely turn them both off if you ask it to turn everything off.

But I generally don't want it to turn off the motion control just the lights... Previously, I would name the motion control something funky and place it in a room other than the kitchen so that google home wouldn't recognize it having anything to do with the kitchen. Then I'd set up a routine so that it would only control the funnily named motion light switch if I said a specific phrase. I also set up routines for "everything off" that didn't include that device.

From my experience (YRMV), with this new setup, if I put the google homes and the devices I generally want to control in one home location, and the devices I don't often control in a different home location, I avoid this issue. So the google home speaker and the kitchen lights are in one home location, and in the kitchen "room". The motion control virtual switch is placed in one of the other home locations. Even if I name the virtual switch "Kitchen Motion", if I ask google to turn off the kitchen devices, it only controls the devices within it's own home location and doesn't touch devices in the other homes. If I want to control one of the devices hidden in the other homes, I just need call it specifically by name.

Hopefully that makes sense! Not for everyone, and the way google operates and changes things nightly I can't guarantee it will work for you... but it's working well for me.

1 Like

This is very alarming as I was going to setup my house this way. Is there an issue with HubConnect when using Socket when causing the Google Home to not respond quick enough or did you have a different slow app running on the hub? I think this is why we should have all other running apps on a different hub and only install HubConnect and the Google Integration on the actual HubConnect hub. It should keep things running nice and quickly.

I don't think it was hub connect. My biggest issue was most definitely the Chromecast integration. And worst of all when I had that setup, I had Google Home on the same hub as chromecast. Also I occasionally experience the hub slowdowns reported. So when you have hub(s) that are acting up and then want them to communicate to each other and Google home... I think Google home was just timing out thinking commands hadn't been received. I would definitely try the setup you are suggesting. I don't think there is any one right way when we all have different needs/setups... Trial and error until you find what works best for you.

Hi, I recently just got my second hub to cover a blind spot in my house. It works fine until I realize you can't add two Hubitat hubs to one Google Home account. The HubConnect setup seems too complicated for me, so I come up with a solution that doesn't require HubConnect. I know it's been a long time but this thread is still on top of the search results, so I thought it may still be helpful to share my setup here.

All you need is Hubitat's Hub Mesh function, a built-in app called Mirror, and a powerline Ethernet Adapter if the second hub is too far away from the Router.

Let's say Hub1 is connected to google home and the Bedroom_Switch is connected to Hub2. Our goal is to control Bedroom_Switch by google home. Below are the steps.

Step 1: Share Bedroom_Switch on Hub2 using the Hub Mesh. This will create a virtual switch on Hub1 called Bedroom_Switch_on_Hub2, which will mirror the behavior of Bedroom_Switch.

Step 2: Create a virtual switch on Hub1 called Bedroom_Switch_Virtual. Then on Hub1, use the build-in app "Mirror", let Bedroom_Switch_on_Hub2 be the source switch and Bedroom_Switch_Virtual be the slave switch. That way, Bedroom_Switch_virtual will mirror the behavior of Bedroom_Switch_on_Hub2.

Step 3: Share Bedroom_Switch_Virtual on Hub1 using Hub Mesh. Then a virtual device called Bedroom_Switch_Virtual_on_Hub1 will be created on Hub2, which mirrors Bedroom_Switch_Virtual.

Step 4: On Hub2, use the app "Mirror" and let Bedroom_Switch mirror the behavior of Bedroom_Switch_Virtual_on_Hub1.

It may sound complicated because of my lengthy explanation (forgive me about my English I'm not a native speaker), but it's really not. Essentially, we created a loop of four devices, each of which always mirrors its previous one. That way, Bedroom_Switch and Bedroom_Switch_Virtual are identical. Now Bedroom_Switch_Virtual is available on Google Home and can be used to control Bedroom_Switch.

Finally, I need to emphasize the importance of the Powerline Ethernet Adapter. If the second Hubitat Hub is too far away from the Router that you can't connect it with an Ethernet cable, there are solutions that can be found Anyone Using Hubitat Connected via WiFi?. However, the Hub Mesh doesn't work with the universal wireless adaptor. The hubs cannot find each other on the network. But Powerline DOES work! The Powerline technique uses the electric wire in the wall as the cable, so it works almost the same as the wired connection.

I hope that helps!

1 Like