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

The JSON error is relatively clear... there's an extra ] in your config.json -- which translates to your JSON is invalid.

The best way to check JSON code is by pasting it into https://jsonlint.com/ and let that site help you correct it.

On the other hand, the NodeJS Proxy Server's config is very easily created at:

HubConnect Server Configuration Tool

There's even a Video to show how to Install it and a quick walk through of the Config Tool.

Yeah I'm a jackass LMAO... As soon as I hit Reply here it glaringly stood out to me and I immediately put it in the json validator and found I had an extra , after a bracket. Removed and issues resolved. Thanks. Sorry.

One last question...

What would be causing these errors from ST?

Is it because I haven't configured it in ST yet?

When HubConnect v2.0 RC1 was first released back in April, it had completed some iterative Beta Testing but history tells us that each level of testing only gets about half of the bugs. That's due to the similar subset of use. It was expected that people wanting to use it would be upgrading from v1.6.4 and all the documentation was focused there. But by the end of April, the 'spare time' needed to take RC1 into full release wasn't available. Thus it's sat in Beta for 5 months so far...

A few weeks ago I moved forward with creating "Fresh Install" docs, because 5 months is more than enough time for new Hubitat owners to want hubConnect... but I have to admit, I wasn't expecting a 'rip-and-replace' story. :slight_smile:

1 Like

:smiley:

Good Luck with that!! :smiley::smiley:

There's no WebSocket on SmartThings, or said another way, the NodeJS Proxy Server is for
Hubitat <--> Hubitat traffic only.

Remember, the NodeJS Server is OPTIONAL. It's value is with larger deployments... although it does help all the way down to the smallest, the return on investment isn't very big.

1 Like

So then I should remove my ST from the JSON file?

Thanks, this is good to know for when I replace my C4 with my C7 and use my C4 as a second hub. I am just using my ST for presence since I have webcore still working for presence with my iphone which I haven't found anything else to beat it's dependability.

Regardless if it's optional or not, I learned how to add a NodeJS container in my QNAP so I can work on other node apps that I've wanted to add for awhile! :smiley:

The 'growth path' for HubConnect begins with http (oAuth). That's the most generic of all connection methods. It works the same across Hubitat and SmartThings. It subscribes to each device you select for the Attributes that are expected for that device. This is the connection method I'd suggest for first time HubConnect users.

The next step UP is to use the EventStream (WebSocket) because there's no subscription in the path. Literally everything the Hub is doing goes out the EventStream. That lightens the load on the Sending Hub considerably although it increases the work needed on the Receiving Hub when the selection of devices is significantly smaller than "all."

That's where the NodeJS Server helps. In a lot of larger deployments, one hub gets ALL devices 'mirrored' to it and thus becomes the 'dashboard-like' hub... be it actually Dashboard or Homebridge, etc. where everything from the entire system is passed along.

Imagine 3 hubs feeding into one... one gets everything and that's great but the three don't need very much... Hub 1 of 3 doesn't need to hear about what hubs 2 and 3 are doing.. because none of those devices exist on hub 1. (in this example, that is.) The NodeJS Server filters traffic to ONLY the hub that needs it. Additionally, it de-duplicates the traffic too. Hub 1-3 might see an 80% reduction in traffic courtesy of the NodeJS server.

But 80% reduction of 2 messages a minute isn't very impressive :smiley:

So again, larger systems where traffic gets measured in the Events per second range is the NodeJS Server's best deployment occurs. :smiley:

1 Like

RC 2 works beautifully. Many thanks!!

1 Like

How do we update from RC 1? Just import new code?

Yes, jut login to HubConnect.to and visit Support:Downloads:HubConnect v2.0 RC2

The 4 Apps are there while there's a directory each for the Remote Hub Driver (Hubitat vs SmartThings.)

Everything mimics the RC1 layout, just not as full. :slight_smile:

That's the UPGRADE steps...

For all new installs, you start the same way: visit Support:Downloads:HubConnect v2.0 RC2 and get the 'build a highway' code. Then once you have a Connected pair of hubs (or more) visit Support:Downloads:HubConnect v2.0 RC1 to retrieve the Universal Drivers, or the ST equivalents, since those haven't changed for RC2.

For an upgrade going from 1.6 to V2 RC2 should I be using the drivers n the RC1 or RC2?

I've got two hubs connected but sending commands from the indirectly connected device page does not result in the desired effect on the hub directly paired (ie: turning a switch on and off from non paired hub to paired hub). Did I miss something? Also I'm looking to use my inovelli lights, do I have to use the custom driver to get them to work with the hub that they are not directly paired to? Thank you!

@csteele

An update: I upgraded to RC2 and same issue. I loaded some backups to see if it was related to 2.2.3 upgrade, but no go, it was present in 2.2.2.

I did patch the "HubConnect Remote Client" in the App software in "connectPage" adding the following below the existing line:

app.updateSetting("serverIP", [type: "text", value: accessData.serverIP])
app.updateSetting("serverIP", [type: "text", value: "192.168.1.201"])

So it seems the issue is with the accessData not containing the proper IP address. I haven't found where this is created or maintained. You write some interesting code. It took me a while to figure out where the IP address was even set. I'm just not as familiar with Groovy as you are!

Appreciate your assistance,
Alan

There's no need to alter code to get HubConnect functional. It's working for hundreds of people as-is.

Alter the code to understand it, certainly, but for basic functionality, there's no need. You've found that you don't have the pieces installed properly and as a result, they aren't handing off the values.

I would suggest 'back to the drawing board' to get it all installed correctly. Along with everyone else, I too wish Hubitat would allow for the Installs of Packages... but thus far, they don't. The result is each of us must grab a minimum of 5 code sets and paste them into the correct location, then install (make active) THEN configure them. THEN go back and add Universal (stub) drivers in the correct locations. We agree, all of that could be made much easier... but today it is what it is.

I recreated a drawing repeated in this topic multiple times but maybe the update won't hurt :smiley:

Server Hub on the Left, 3 code sets installed, 2 apps, 1 driver. Remote Hub on the Right, 2 code sets installed, 1 app, 1 driver. The Parent/child notation is to show that the pieces work together and must all be in place first.

The messages I've read in your screen caps tells me you're trying to recreate an existing Connection, but that it still exists and HubConnect is (correctly) rejecting the attempt.

1 Like

they kind of do with package manager it would do this with its eyes closed but due to the now personal code obviously it cant be done :pensive: BTW no issue with the need to create a account its just a shame that it makes the install hard.

@csteele

Belay everything. I went into the Child configuration. Went into "Connect to Remote Hub" which shows the proper IP address and then selected the option "Update child devices with new IP address?" and this resolved the issue.

Thanks again,
Alan

@csteele, I'm trying to use the attributes of the remote hub device itself to trigger a rule when the remote hub is hosed (e.g. 500 error with the hub or perhaps when the Hubconnect layer itself is not happy). I'm using websockets.

Just from trial and error, it looks like eventSocketStatus and/or Presence would be a good indicator of whether the remote device is "online". I tried to test my hypothesis by purposely turning off the remote hub and noticed both Presence and eventSocketStatus changed values. But I don't know if they'd change for other reasons as well.

Advice?

Socket/WebSocket status, Orphaned Parent/Child Hub,

Both Presence and Switch are the same. Two sides of the same coin.
'present' == 'on'
'not present' == 'off'

1 Like