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

From that error, it looks like you can resolve that problem if you remove or comment out the line capability "ChangeLevel from the driver/DTH (towards the top). This is a Hubitat capability that is not implemented on SmartThings as far as I know, though a look at the universal driver reveals that it must have been left in the "Bulb" driver for whatever reason.

Yes! That fixed it. Thank you so much to @bertabcd1234, @csteele, and @Marx for all your help!

Okay, now less critical questions:

When the devices got mirrored into ST it created new devices in Google Home as well. These are now duplicates because I already linked it from Hubitat. I don't know how to selectively remove devices from ST-->Google Home link. Is there a way to do this? The only thing I could think of is removing it from Hubitat--> Google Home link but I would prefer Google Home to call on the original local device and not the "mirror" device.

Edit: I found that currently there is no way to remove the duplicated device in Google Home if it is linked from HE. All devices from Smartthings will get sent to Google Home if you have linked your account. You have a couple options to remove the duplicates:

  1. Move the duplicate devices into a new Home. I have moved several devices into a home called "Hidden"
  2. Remove the device from HE-->Google home link since you have ability to filter at device level in HE. This means the HubConnect device from Smartthings will be the interfacing device in Google Home In some cases I found that to be a better option because Google Home recognizes the same device from HE and Smartthings differently. For example, Google will recognize an outdoor plug as a light from HE but it will recognize the same device from ST correctly as a plug. This is important to me when Google Home groups lights in a room together.

I've created a new "Bulb" driver for SmartThings.

as well as the repo organized ST specific:

Obviously, as a ST driver, it's not in HPM :slight_smile:

Additionally, I updated HubConnect.to to have the latest:
HubConnect-Remote-Client-SmartThings.groovy

so that the edit for a single ? is no longer necessary.

I've sent a couple messages to @srwhite but it's well into his annual Camping Season...

1 Like

Do I need to overwrite my code with what you've posted? Everything is working but not sure if there is some backend changes in the code that should be included.

Making changes at this point gets me a little nervous...

Also, I have a couple of Enbrighten (Jasco) Zigbee Outdoor plugs that I did not see in the device categories of the server instance. Actually, I saw it under Iris Smart Plug but not sure if it would work. Should I try that or is there not a supported driver?

Edit: Okay the Enbrighten Outdoor plugs are in the "Pocket Socket" device category. Was unsure of what that was until I tested and confirmed that it works.

no, YOU don't :slight_smile:

And now, the next ST'ers to come over won't have to either :smiley:

2 Likes

I have Alexa set up with devices for Hubitat populating it. I do not have a connection between SmartThings and Alexa at all. I am using the mirrored ST devices from Hubitat connecting to Alexa. I don't see any lagging whatsoever.

Okay, now I'm attempting to see select ST devices in HE. I go into the ST SmartApp and connect a couple of Audio devices:

I click done to navigate out of the SmartApp but I don't see them in Hubitat. I do see two HubConnect devices on the devices page:

So couple of questions:

  1. How do I see them on the device page? And should they be a child of the Home (ST friendly name) Hub in the second screenshot?

  2. Why do I have two Home hubs for ST (as shown in the second screenshot)? Is one of them a ghost device?

An update to my post above. It looks like the first HubConnect Remote Hub in HE has the same activity date/time from a couple of days ago (5-18 11:24 PM):

Is that device safe to remove? Will it have any effect on the HubConnect Server and all the devices I'm sending to ST?

Also, I still haven't been able send devices from ST-->Hubitat after trying a window shade and outlet. I know it was mentioned that I don't need to install drivers for Hubitat so not sure why this isn't working or what step I've missed.

I am not sure where that's coming from but I'd say it's false. Every device that is mirrored must have a driver on each end. If it doesn't, then the mirrored device will fail to be created.

For "real" devices.. the real driver already exists... so a ZWave device on Hubitat uses a real ZWave driver. When it's time to mirror that device to another hub.. Hubitat or ST, then that other hub needs a HubConnect driver available to permit the creation of the mirrored device.

Same thing for mirroring real ST to Hubitat. The Hubitat hub will need a matching HubConnect driver in order for the mirrored device to be created.

You may remove that remote hub, yes. It's another variation of the theme of needing a Hubconnect driver for a "real" device.. in this case the ST Hub itself. As with any device, going deep enough into the HubConnect menu will, on completion, send the full list of devices and any that don't exist will try to be created.

Sorry, I incorrectly assumed your statement below was an automated process:

So I search HPM for "HubConnect" and I see the two results:

Do I need to install both drivers?

The HubConnect drivers are located in the second package listed.

Sucess! Well, at least partially.

So I installed the window shade driver and now the ST window shade comes through but it does not perform any of the commands (e.g. open, close, set level). When I check the official Android HE app the shade has a bulb icon. I'm using the Bali/Graber z-wave shades if that matters.

The dimmers coming from ST-->HE are working great!

Sorry asking this if it was already answered in this post. I really tried to look for the info here but no success.

I have a Hubitat (server at my home) and a ST (cliente at my workplace). Is it possible to connect them via internet? What IP ports do I need to map? I am going to use a DDNS account to map the IP between them. Is it possible?

https

The Hubitat hub will communicate with ST's Cloud.
ST's cloud will communicate to the ST Hub, if necessary.
ST's cloud will communicate to Hubitat's Cloud.
Hubitat's Cloud will communicate with your Hubitat Hub.

There's no special setup required. Other than picking SmartThings :smiley: and correctly identifying the IP address.
Screen Shot 2021-05-29 at 11.40.00 AM

:thinking:
Even considering that the Server HUB and the CLient HUB are in different networks? (in fact in different cities :slight_smile: )?

so the IP address I will put in there is a DDNS name (internet IP) for both but the option that shows in there is the LAN adress for each device. So I put the LAN or the valid internet address for each HUB?

No. You're overcomplicating.

HubConnect cannot connect direct to the ST Hub (if it's on a different subnet.) Instead, the respective Cloud services are used.

No DDNS required.

HubConnect simply "links" the two clouds.

Your ST hub has a local IP address, already. The ST Cloud already knows this.
Your Hubitat hub has a local IP address already. The Hubitat Cloud already knows this.

2 Likes

but on the app (ST) it asks for the HUB (hubitat server) address. Whta do I put in there?

You put the IP address of your Hubitat hub. The LAN address you already gave it.

You boot up the Hubitat hub... it has an IP address. That one.. give the ST App that one.

You boot up a ST Hub... it acquires an IP address. Use that one in the Hubitat Remote definition.

1 Like

:rofl:

you cant make more clear.....

feeling stupid here.....

by the way, I am using the 2.0RC2 if that make any difference....

1 Like