[RELEASE] HubConnect - Share Devices across Multiple Hubs (even SmartThings!)



Yes, assuming there’s not a loop that has A then setting the mode back to Home.

HubConnect has protection within modes, but not for Rules that set modes to ‘arguing’


Makes sense. The rules I use to trigger mode changes are that - triggers on finite events (door unlocked with code, for example). So I wouldn't expect it to get in a loop fighting with each other.

We'll see. :smile:


The looping of mode changes shouldn’t be an issue as there’s already filtering in place to prevent a hub from accepting a mode change then triggering one in its event handler. Should be good to go.


This is very cool. Thanks a whole bunch.
I am currently migrating from ST to HE.
Warning this app will slow down the migration!
This works so well I don't really need to migrate a lot of my devices anymore :slight_smile:

Question and I am sorry it this has been covered but this is a very log thread.
As I understand it HubConnect goes out to the cloud to control to Smartthings devices. Does it have to do this for locally controlled Smartthings devices?
Most of my Smartthings devices are Zigbee Bulbs which as I understand it are local.
Also just to confirm if there are 2 Hubitat will the traffic remain local or is the cloud still needed?


Hubconnect talks to both HE hubs and ST hubs locally.


No, all custom code on SmartThings runs in the ST cloud (as does most native code, for that matter--just how they designed the platform). The other poster's suspicion is correct: it needs an internet connection for all ST devices.


It talks to ST through the Remote Client app installed on ST, i.e., custom code on ST and therefore cloud execution. :slight_smile: (Don't be fooled by the local IP you put into the server app. That's about where it stops. Try unplugging your internet connection if you want to see for yourself.)


Thanks, that is what I was afraid of. One of the reasons I am switching is that I find light switches too slow on ST because they have to use the cloud. I was hoping to connect my switches on the HE to control my lights on ST. Guess, I will go back to the original plan.

With 2 HEs does HubConnect also use a cloud Remote Client?


No that's local, it's only stuff too and from ST that is cloud.


Good to know. Thanks


This is exactly what I wanted to do however according to bertabcd1234 Hubconnect uses Remote Client over the cloud.
Under this scenario the devices are local but the controls are still cloud.

So if bertabcd1234 is right it would I not be just as cloud dependant?

The goal of getting away from the cloud was also reinforced by what happened at Google over the weekend i.e. Google cloud is down, affecting numerous applications and services


Sorry, but as I mentioned above, that is not the case. You can see for yourself by disconnecting your Internet connection (while leaving your local LAN in tact), or you can verify that HubConnect Remote Client has cloud execution in the ST IDE (this is, of course, the app through which all HubConnect communication to ST takes place). All SmartApps run in the cloud on ST except some Smart Lighting and Smart Home Monitor child apps, depending on certain conditions like whether all devices involved have local DTHs. See here for more: Local processing – SmartThings Support

I know, it seems like these things should be able to run locally. But that's why many of us are on Hubitat: because they don't. :slight_smile:


My bad, deleted.


Allow me to clear up some confusion here...

On SmartThings, ALL custom code, regardless if it's a SmartApp or DeviceType runs entirely in the cloud. Therefore, the RemoteClient for SmartThings runs completely in the cloud.

The ST RemoteClient uses cloud-to-cloud calls. If you have a SmartThings hub, that is used as a bridge to the cloud for local Zigbee, Z-Wave, and LAN devices. If for example, you have only cloud interactions on SmartThings (i.e. Ring, Arlo, etc.) you don't even need to use the hub anymore.

I hope that helps.


On the remote hub, Select Motion Sensor has 3 sections. I added a sensor to the 3rd section (the one with motion, temp, and illumination). The count does not update for number of devices shared.


"Found and fixed, next release"

(doing my best @bravenel imitation) :slight_smile:


Another weird issue. Added a contact device, but it only showed battery status (no contact status). I had to remove and re-share the device to correct. Only 1 out of 4 of my contact devices did this.

Also, unit attribute does not seem to be shared. The original device driver shows battery with %, but virtual device does not.

Last issue noticed is that the virtual device in a dashboard does not seem to "finalize" the event. If I click on the HubConnect Switch, it triggers, but the dashboard tile never gets to changed state (e.g. on to off, off to on). It gets stuck in the changing state.



Saw this and hoped it was the issue for my RGB bulbs not working correctly...so I removed one and deleted the device on the server end...re-added...still same result. I was so hopeful! :relaxed:


I'm guessing that the root issue was the contact status wasn't available in the original.. and then it was. The length of time between first selecting the device and the second... with all the removal, etc. was just long enough for the contact sensor to report in and give an accurate status.

HubConnect doesn't push 'potential' attributes, just the ones that are there. The Sync button is a mechanism to tell the remote to update all the attributes. When new attributes 'arrive' they get pushed across. Thus either time or Sync will 'catchup' all the attributes.

That's what I THINK happened, but of course, I could be wrong. :smiley:


While I appreciate the amount of work put into HubConnect, I think the biggest issue right now with HubConnect is that it doesn't work in Dashboards, at least not for me. Contact sensor changes do not reflect in the dashboard and switches do not actually toggle state (gets stuck in the press). I hope you can figure these issues out quick so I can start using it. Thanks.