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

@csteele I will try to give as much info as possible. These are the error logs after I verify connection,

This is what I have set up in Smartthings.

This is in Hubitat

Hope someone can point me in the correct direction as I am at a loss!

Missing the driver on the Hubitat side:

Your screen cap shows only the RM Connector driver.

Two Apps, one Driver for Hubitat Server hub. One App, One driver for each Remote Hub. (ST or HE)

THANK YOU!!!!! That was it!

Hopefully linking devices will be a smoother process!!!

Mirroring devices is different because it's bi-directional. You have a device, a real/virtual device, already created on one of your hubs. You select it in that Hub's HubConnect app (either Remote, or Server Instance) and on the way out, as you click done, a message appears to tell you what HubConnect drivers need to exist on the OTHER hub before the last click of Done:

Screen Shot 2020-11-15 at 11.43.06 AM

If you miss it, don't fret BUT the other hub can't create the mirrored device without it's matching driver. Just add in the HubConnect Universal driver, and then go back and dive into the HubConnect menu as if you were selecting the device again.. you don't need to deselect reselect, just dive deep enough into the menus. Done all the way out and again, HubConnect will try and mirror all the devices... successfully if the driver exists.

If you are using Hubitat Package Manager (HPM), then all the HubConnect Universal drivers for Hubitat can be installed. Obviously, HPM is a Hubitat only App and it can't help with installing drivers (DTH) on the ST side.

Hopefully someone can help...I am having issues trying to setup the global variable connector. I have the driver on both the coordinator and remote hub. I have chosen 1 variable to sync to the remote hub. the device does show up on the remote, but the variable never updates on the remote. the device on the remote shows nothing under both current state and state variables.

If the driver needs to be modified to reflect a variable, can anyone suggest the changes?

Thank You
Chris

have a look here HubConnect passing global variables

1 Like

This tripped me up as well. Shouldn't it say ",,, are installed on the Remote hub", not "Server"?

The label next to the Remove unused devices control refers to the OTHER hub as "remote".

Question: On HubConnect v1.5 I was able to connect my EcoSmart remote through smartthings and have it work, but in v2 I lost that functionality. Is this expected? I am using the HubConnect Button Driver. Thanks!

ST and Hubitat have different button implementations. HubConnect v2.0 added a transformation layer for Buttons. But I've never heard of a problem with it...

Unfortunately I don't have an EcoSmart remote to use to attempt to duplicate this.

So additional question on the TV integration. I also added an attribute called tvChannelName (that displays the app currently running). The issue I have is that it doesn't update in realtime. I have to hit the refresh button to get it to update. The volume also doesn't update in realtime.

In the ST app, it updates in realtime.

Please is there any way to make this update in realtime? Seems I need to subscribe to this but HE doesn't automatically subscribe? Wonder why it worked fine with inputSource but not this.

Any other thing you might suggest if not possible? I can possibly add a command in RM to run the refresh() command every 30s but don't want to put more strain on the hub.

Will this still work with SmartThings after their migration is complete?

Things that make you go hmmmm....

I'm using HC to connect my ST and HE hubs. In the config for each, it wants the IP address of the other hub. Fine, except that my ST hub is on a different subnet than my HE hub. Yet, it works.

Does HC somehow work through the cloud if the hubs can't directly talk to each other, or do I need to start looking at my network switch config?

Yes.
ST or if you have a Summer Palace with another Internet and Hubitat Hub.

1 Like

So why the IP addresses? Will it try those first and then fall back to the cloud?

All of my IOT things are on a separate lan/wifi from my computers and NAS. I had to put HE on the lan with the computers though, so I could access it.

I imagine things would sync a little faster if they were on the same lan, but is there a perceptible difference (I have a pretty decent internet connection)? Not sure I want to trust ST on the same lan as my NAS.

Also, please any idea how to deal with attributes that have null values? tvChannelName is null when no app is running. I want to be able to track when there's no app running but HE overwrites the null with the previous value (which isn't useful). As a result, it appears I'd need to replace the null value with a string like "no app running". Not sure which hubconnect driver to edit to make this change.

Thanks

DNI
The mirrored devices get a DNI of the IP address+deviceID

Not exactly. The most common use is to mirror devices paired to the ST hub onto Hubitat. If the ST hub must physically manage the ZWave/Zigbee traffic, then you have the choice to use HubAction, which sends commands directly to the ST hub BUT the ST hub probably has to send that to ST's cloud and back. Clearly a small portion is run locally on the ST hub, and that would continue. If the ST managed device is itself a cloud device, then really, the hub isn't participating and you can power it off.

HubConnect is like a mirror... you want to stick an Elmo sticker on your mirror to make the reflection better? Don't think it works like that, if you see my metaphor :smiley:

If you want the attribute to have a value, then the "Real" driver would be updated to have a value. I don't remember Hubitat replacing nulls with a previous value, but a change in 2.2.4 involved de-duplication... and maybe nulls are being caught in that fishnet.

Thanks... Was hoping HubConnect figured out a way to deal with it since ST has always supported null as an attribute value while HE has not (so this issue might have come up before). In my case, the TV uses a built-in driver so there's no way to edit the driver unfortunately. I have updated to 2.2.4 and it still doesn't handle nulls (simply sets the attribute to the previous value). I still don't understand why null isn't a valid attribute "value" but HE has decided.

@csteele please any idea about this? Thanks!

Figured it out. Had to edit the Server Instance to check for nulls in the value and replace it with string "blank". Works fine now though.

Thanks