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

I think that worked. Will test further just to be sure, but in the meantime, MEGA THANK YOU!

1 Like

It's something I should have looked for earlier BUT, Steve will be happy to tell you stories of how many times I was using the wrong version(s) when he'd give me 'the latest' to test. Thus I can conclude that version checking is quite a bit further down my debugging map than it should be. :smiley:

maybe I should rely on @april.brandt to ask "Are you using the correct versions?" -- 'cause I won't get to that item in my list for many steps. :smiley: On a positive note, we did get there in ONLY 4 hours :smiley::smiley:

3 Likes

Hey, there's no I in team @csteele. I got your back.
:grin:

2 Likes

Speaking of versions, I'm still on release 1.6x and everything is working well. Is there any benefit to update to the 2.x beta? I dont plan on using the NodeJS server. I feel like I'm missing out back at 1.6x !

I'm not on the new version either. But mine doesn't connect much. Just lightify strips and cree bulbs.

There's a lot of features added to v2.0, but a lot of them are related to first time install benefits. Things like the Driver detecting the break in Parent/Child. That occurs most often with a new install especially an out of sequence. You've got a working install. And there's nothing in the EventSocket method of communications that was improved beyond those install benefits. Obviously, you identified one of the big changes: the addition of a THIRD communications method, the NodeJS Server.

There's a lot of improvements in Reports, and the Driver Builder for Custom Drivers is a big enhancement.

Eventually Steve will get back and will release v2.0 and v1.6 will vanish from the forefront of github. So I would put it on your roadmap to be ready to do the upgrade, but I'm not expecting anything for months.

Steve was going to release v2.0 RC2 before he left but I convinced him that there's too few problems with the RC1 to take another spin. Unfortunately time ran out and he didn't get v2.0 packaged for release. (Every code module has to be touched and the versions edited, at a Minimum, and he just ran out of time... ) BUT.. he's going to have ALL Summer to percolate new ideas and he may be too excited with those new ideas to do a Release first. :smiley:

1 Like

Did the testing and it failed. The hub device now shows that it using socket as the communication type, no longer http, which is why I thought it worked. But events aren't coming across. And the server hub device still shows no subscribed devices (actually, it shows "[80]"). When I done out, the logs show this error. Thanks for sticking with me!

app:30452020-06-19 09:46:15.336 pm errorjava.lang.NullPointerException: Cannot invoke method length() on null object on line 1580 (systemSetCommType)

app:30452020-06-19 09:46:13.640 pm errorjava.lang.NullPointerException: Cannot invoke method length() on null object on line 1580 (systemSetCommType)

app:30452020-06-19 09:45:58.830 pm errorjava.lang.NullPointerException: Cannot invoke method length() on null object on line 1580 (systemSetCommType)

app:30452020-06-19 09:21:02.075 pm infoSkipping event subscriptions... Using event socket to send events to server.

app:30452020-06-19 09:21:00.658 pm infoHubConnect Server Instance Initialized

app:30452020-06-19 09:21:00.622 pm infoHubConnect Server Instance Updated with settings: [clientIP:10.0.0.53, clientName:HE Cloud, remoteType:local, localConnectionType:socket, useProxy:false, updateDeviceIPs:false, removeDevices:false, enableDebug:false, receiveHSM:false, receiveModes:false, genericMotions:[Back Door Exterior Motion, Back Stairs Virtual Camera Motion, Driveway Virtual Camera Motion, Front Walk Virtual Camera Motion, Garage Motion, Garage Virtual Camera Motion, Mudroom Door Virtual Camera Motion, Mudroom Motion, Side Door Virtual Camera Motion, Vault Virtual Camera Motion], genericContacts:[Vault Cabinet], cleanupDevices:true, pocketSockets:[Kitchen Security Monitor, Master Bathroom Monitor, Theater Power, Xbox Power], genericSwitches:[Driveway Switch Debounced, Override Foyer Chandeliers, TV Door Close, TV Door Open, Virtual Front Doorbell Motion Switch, Virtual Front Doorbell Switch]]

EDIT: in case this helps, I noticed that if I add a new device to the remote app, it will show up as a subscribed device in the server hub device. But if I simply refresh (or remove/done and then add/done) an existing device, it won't show up in the server hub device. Stymied.

You'd better PM me a Technical Support Report, please. Line 1580 of the Server Instance is only supposed to run when "proxy" is selected.

Screen Shot 2020-06-19 at 9.47.43 PM

Just PM’d you

1 Like

You still have an antique driver showing up on "HE Upstairs GroundSW" and "HE Basement GroundSE"

I know that's not the one you're reporting the error on, but the Report you just sent shows them. (Lines 74 and 407)

Can you also have Live logs for both Server and "HE Cloud" running in individual tabs then, on the server instance of "HE Cloud" click into Connect Local Devices to Remote Hub. then into anything... Audio Devices.. and then Next, Next and Done. Can you then grab both sets of those logs and PM them to me as well, please?

Sorry if I'm being dense, but I don't see any line numbers on the report. Are you referring a device driver? Is it the Hubconnect Remote Hub? I show v2.0.9501, which I thought was the most recent. Am I misunderstanding?

Will PM logs to you momentarily....

The two Hub Instances (on the Server) are still showing that they are using the Old Driver. Perhaps it's just a cached thing.. there is only One copy of the driver, it's right for at least once Instance. It could be you haven't hit those Instances yet with the

Ah, so you're not saying that I need to update a certain device driver. You're saying I need to going into those two hub instances on the server and done-out. I misunderstood. Assuming I'm interpreting correctly now, I've completing that step, and am working on the logging now.

It's 1am to you.. you can have another go in the morning. :smiley:

Hah, okay. Same to you -- not sure where you are, but it's late everywhere. I just PM'd you the logs and I'm going to hit the hay. Regardless, you are Da Man. Major gratitude. TTYL

@csteele.
I've just defined a Virtual Illuminance Sensor and tried to share to another hub.
Before clicking 'Done' it says I need a 'HubConnect Virtual Illuminance Sensor' driver installed.
When I click on the link it returns a '404'.
When I go to github I cannot find the device driver.
Is there another site that I should be looking at now.
Thanks.

I found it and downloaded it from:

https://hubconnect.to/download/category/4/Universal-Drivers.html

It's there close to the bottom, alphabetically. I was able to download it.

Thanks. I had an old url saved to github.
Changed it to this site now.
Thanks again.

The "old URL" is probably for v1.6.4 and it's still valid as that is the "Official Release Version".

The HubConnect.to site is where v2.0 (and beyond) will be released, including the current RC1 "Public Beta" code. The GitHub site will be reduced to only the 'stub' drivers in that future.

In other words, you'll want to keep both, perhaps.

1 Like

Architecture question -- I have a 5 hub setup that is hub and spoke -- 4 hubs that control devices and do "remote/local" automation and 1 server hub that collects all the devices for dashboarding and "global" automation. Works great.

Here's my question: I only use SmartThings for Presence, but because I manage Presence on one of the 4 remote hubs (not the HE server hub), I'd like to hubconnect directly from ST to the remote HE hub, bypassing the HE server. If I did this though, one of my HE remote hubs would essentially be acting as a Hubconnect server hub to the ST remote hub.

Is this architecture workable? Would I essentially install another instance of Hubconnect on the remote hub? Or should I just suck it up and force the presence sensors to take two hops--ST to HE server, HE server to HE remote?

Thanks in advance for any advice?