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

In my case HubConnect sped things up because previously my hub would get bogged down. Leaving devices on one hub and using HubConnect to connect another hub that runs rules and cloud devices made things noticeably faster for me.

5 Likes

Question: I seem to be getting a Warning when trying to sync to a ST Hub.
From the logs of the Hubitat server hub:

Is there something that I should be doing?

The device is 'orphaned'.

Delete the virtual Device (has a HubConnect universal driver.) Then pretend to select it again from the hub with the real device. Click Done all the way out and it will be recreated.

The error message is saying, "I need to make a new mirrored device, but can't because the old one is in the way."

Any idea on how I can select the right one?

(If not, I'll just delete all of them, since they are all just "shadows").

"Sync" is on a Device Info page. So.. that device... just scroll to the bottom and click Delete.. taking a detour along the way to memorize any Used By items.

A quick note to the beta group. I have been a bit preoccupied with work and home obligations and will address any bug reports shortly.

Here’s an update on v2...

The SmartThings side has received a significant overhaul. Hub IP address changes are now supported as they have been in Hubitat for some time. More significantly, direct hub-to-hub (HubAction) communications will be supported in SmartThings, in addition to cloud-based oAuth http used today. This will remove the requirement of connecting through the Hubitat cloud servers. It also slightly improves response times as well.

Beta 4 will be coming out on Thursday (or Friday) and will include the updated SmartThings integration and will feature the launch of the new HubConnect server too.

4 Likes

Wow! Potential game changer for those folks whose locks worked fine with ST but not HE.

2 Likes

I don't want to derail this, but I've always wondered what the difference, if any, between HubAction and the async HTTP methods is. Basically the same question here, where the consensus (and I don't see anything in the docs or elsewhere on the forums, including the post that introduced these methods) seemed to be there wasn't one: Hubaction vs HttpGet/Post etc

Or maybe they're the same on Hubitat but the difference matters if it originates on SmartThings? We can move back to the other, older thread if that's a more appropriate location to continue this discussion. :slight_smile:

On Hubitat there is probably little difference. On SmartThings the httpGet/httpPost originate in the cloud. The only way to talk to LAN devices on SmartThings is to use HubActions.

For SmartThings connected hubs, communications currently follow this path...

ST Hub <--> ST Cloud <--> HE Cloud <--> Server Hub

The new HubAction support simplifies that communication path by removing the Hubitat cloud dependency...

ST Cloud <--> ST Hub <--> Server Hub

It also gives a slight boost in device responsiveness by doing away with the one extra hop.

8 Likes

I know v2 is yet to be released, but what would the process be for switching to HubActions for SmartThings? As it stands, the few devices I mirror to ST work fine, but anything that can be done to eliminate the ST cloud component is a welcomed addition.

It doesn’t eliminate the ST cloud, just the HE cloud part in the communication process.

1 Like

OK, bad wording. Just wondering how we'd switch from one method to the other.

I'll find out tomorrow or Friday. @srwhite has done a lot of work making everything easier to configure and use in HubConnect. I imagine it will be a different driver or a toggle.

1 Like

I am trying to make that as easy as possible... Basically change the setting then copy and paste the key. I may add support for automatic connection settings updates for ST.

3 Likes

I know that V2.0 will work faster with ST, but I have to tell you:
I'm now using my old ST (V2) Hub as an interface to SharpTools.
Works great! Even using it to control locks, it's acceptable response.

dashboard -> Sharptools.io -> SmartThings -> Server Hub (Hubitat) -> Remote Hub (Hubitat)
(and back again!)

SmartThings is a good resource for deploying multi-hub with a lot of cloud components. Any cloud integration that happens to work 'better' on ST is a legitimate reason to continue to use it. It happens in my house, there's nothing 'better' -- but my ST hub is always on, although to be truthful, it's on just for 'you guys.' :smiley:

I've said multiple times that my family has no idea there are Dashboards for the house. I know they have seen them, just found them to be of no interest and thus have not asked "what is that?"

However... IF dashboards would have improved FAF (Family Acceptance Factor) I'd be all over Sharptools etc. :smiley: (AND possibly via ST.)

1 Like

SUCCESS!!

I just wanted to let the development team for HubConnect know that I've now had it up and running on 4 hubs successfully for several days now and it has been working phenomenally.

Dev team: Nice work! Thank you so much for all your efforts on this project. Great design, great implementation, and extremely useful. Thank you!

I did want to let you know of a problem that I ran into but was able to work around. I kept running into a situation where I could get Hubitat <-> Hubitat working using http, but when I'd switch to Event Sockets, things would break down. Interestingly, both the server hub and the client hub would claim to be connected, but I'd see repeated errors in the logs and when I'd share a device, the corresponding device with the HubConnect driver would not be created.

The problem seemed to surface when I would use host and domain names (for example habitatA.mydomain.com) for the hubs rather than their IPs. I didn't do enough testing to be certain this was the case, but I was able to resolve it twice by removing the misfiring instances and try again from scratch, with the only change I (knowingly and purposely) made was to use IPs instead of names.

I don't have the full messages from the logs. But basically, in the logs of the server hub, repeated every 10 seconds I'd see:

(info) Attempting socket connection to Hub B (0)
(trace) Initialize virtual Hub device...
(warn) Connection to Hub B has failed with error [failure: hubitatb.mydomain.com: Name or service not known]. Attempting to reconnect...

I'm not seeing this any longer-- I no longer have a deployment leveraging names instead of IPs. However, it would be nice to be able to use names for anyone that might have them working so I wanted to pass this along in case it really is the source of the problem.

Thanks again for some amazing work on this project.

2 Likes

This is AMAZING!!!!! Thanks so much for all this effort. I'm switching my house (over 100 devices) from ST to Hubitat. I'm already happy I'm making this choice.

Something to think about: The remote client app for ST doesn't show the place to enter the LAN and the Connection Key if using the NEW S.T. app, I'd abandoned the Classic app as everything otherwise seemed to work. Just wanted to let y'all know. No complaints, as I got it to work (after about 20 minutes, then realized that might be a thing!)

1 Like

A lot of work has gone into v2.0 which is in Beta test. (I personally have never tried the new ST APP...) I'm told v2.0 works. The upgrade will be 'wide' (meaning many apps and drivers to update) but Importing each will be as simple as it is for each piece of v1.6.

FQDN's are not supported. The input's are specifically labaled "IP Address" because HubConnect requires the use of IP's for a variety of reasons, one of which are also used to identify virtual devices that are associated with each hub.

I have fixed the issues that were breaking the new app in 2.0, so when it's released in a week or two, you'll be able to use both apps with it.