2 Hubs 2 Locations 1 Alexa

I was thinking that with a 3-way connection with HubConnect involving remote internet access maybe the latency between the remote servers would cause the issue. Something about the server having to ping all the hubs which could cause a delay or some such.

I have not heard of going through the HE Cloud for sharing data but I haven't had the need yet - wouldn't that add an extra hop instead of connecting directly? I do not really have experience with this so apologies..

I could connect directly if I used a VPN, but HubConnect allows you to go via the Hubitat cloud, so that was easier.

That's good to know thx!

Have you tried keeping the remote hub (US) disconnected and test it that way? Also maybe switching over to a VPN. Just some ideas..

In the issue with the fridge/freezer everything was local in Ireland - so the fact that I have hubs in the US I don't think factors into this issue.

The only reason I bring that up is if there is some sort of 3-way connection between the hubs with HubConnect maybe an extra slow client (like the US hub) can cause delays in the overall process which could muck up timing with Alexa stuff for the local processing in Ireland. Maybe the server is being impacted somehow is what I'm suggesting.

HubConnect is Event Driven.

The two apps: Remote Client and Server Instance, each Listen for Events and 'mirror' them to the connected hub. That's it. No polling, no caching.

There's a 'ping' process running to let us know of the health of the Connection:


That 'Online' word is the grand result of the health check ping.

We all know "Newton's Cradle" right?


That's HubConnect.. Events go in one 'end' - come out the other.. bidirectional

:smiley: :smiley:


Yep that makes sense! :grin:

So any delay in the "mirroring" process wouldn't impact the sender or receiver?

I use that configuration in my RV.. It frees me from worrying about managing a VPN connection. There is not a lot of devices in it so the traffic is minimal.

The communications are over http, so there's a bit of related protocol lag, but the real delay is mostly a direct correlation to the IP RTT latency between the two hubs and the cloud infrastructure in between.

Sending over http is asynchronous so the sending hub never sees any lag. Attribute updates are never acknowledged, so the recevier hub gets the update and moves on to the next message.