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

It indicates that the websocket is connected. Your server hub should be receiving events generated by the remotes.

Can you go into the derver inssance for this hub anhd switch to http instead of websocket? You will need to repaste the connection key after doing that.,

I have a Darksky weather driver on my second hub that is very chatty, and only need the tile to go across to the main hub.

I just tested it.

Using websocket - server updates appear on client, but client updates do NOT appear on server.

Using http - server updates appear on client and client updates appear on server.

So for me, websocket appears to be unidirectional and http is bidirectional.

Is there an advantage to one over the other? I chose webscoket, since the data is there anyway.

Websockets are currently unidirectional, with the server hub listening to events on the remote's websocket (remote-to-server events). For server-to-remote events, communciations use http by default. That's what is apparently failing for you right now, but I'm not sure why, especially if the hubs are on the same subnet.

I'm assuming that both hubs are assigned static IPs so they don't change?

1 Like

Static. Same network.

Thanks for your help.

As Steve said, EventSocket (websocket) is unidirectional. When you select "Event Socket" as the type, that converts the server from having a bidirectional http conversation to the Server listening in on the websocket. EventSocket is a platform feature (unsupported) that sends every event it sees. It's got nothing to do with HubConnect explicitly. Events occur and the DB gets updated and that's put into the EventSocket stream. HubConnect opens the connection and listens. It's a "firehose of information". Every device, every event. Any Event for a 'mirrored device' gets injected into the Server Hub as ordinary events.. as if the real device was truly located on the server hub.

Your experiments indicate that bidirectional http works, but that when switched to EventSocket, the Server Hub is not 'hearing' anything. Of course the Server to Remote Client works, because that direction never changes.. uses http when you select http (oAuth), uses http when you select Event Socket.

Can you PM me the HubConnect Key please? Its got some additional clues, perhaps.

1 Like

I believe that I have had the same problem.
Read the immediatly above posts, switched to http and it started working.
Now works great.

So many questions,
What device driver works approptiatly with ZOOZ power strips parent and child devices?
I will stop there as to not hijack the current thread direction!
Thanks for this incredable enhancement to HE.

I was wondering if locks will work across ST and hubitat linked with hubconnect, specifically schlage locks. I tried to link my ST paired lock to hubitat and I couldn't control the lock thru hubitat. Thanks

I believe Zooz Powerstrip is just 5 child devices that need to individually be selected. They will appear as 5 devices (not as children) on the other hub, where they can be individually monitored (dashboard) and controlled using a Switch universal driver. As is so often the case, I don't have one to test my opinion. :frowning:

I have my Yale Lock on a Hubitat Hub, mirrored to the Server Hub. Just now I mirrored it to ST and tested in each direction. Locking it from ST and Unlocking it from Hubitat. Worked fine.

2 Likes

My usage of the app has changed over time, plus I didn't completely understand the suggestions of which should be the server vs client in the instructions, but I now see I have my apps on the wrong hubs. My current setup has all devices going from the server to the client. The client has no devices going back to the server. So I have them backwards if I want to use the event stream.

Do you know if I just switch the apps on each hub whether it will reconnect to my already created hubconnect devices? Or will they be recreated as duplicates, and I'll need to manually change them in all my RM rules?

No problem either way, my fault - we learn as we go. But I'm just wondering if this is a half hour change or an all night adventure :slight_smile:

I'd suggest waiting.

I won't tease, but I think next week you might be smiling. :slight_smile:

You can practice smiling now if you want. :smiley:

3 Likes

Gonna grab me a mirror

3 Likes

You won't tease, but I will!

HubConnect 1.5 has a cleaner Server UI...

...and Remote Client UI

The Required Drivers are linked to Github for instant download!!

There is a new Technical Support Report option in the Utilities menu...

... this is the output of that report!


... part of it anyhow.

7 Likes

And those aren't even my favorite parts. :slight_smile:

"Wait, there's more..." hint: You'll be putting the HubConnect Remote Hub Driver on ALL Hubitat Hubs.

:smiley:

5 Likes

... except SmartThings. :grinning:

corrected :slight_smile: Thanks

1 Like

Grabbing the connection key is also easier... Especially when the text auto-selects for you!

3 Likes

Very impressive improvement! Curious to ask if any improvements for the custom drivers? I would like to see all existed attributes of my custom driver devices . So far my xiaomi temp/humidity only report temperature using provided iris driver..

Custom drivers are working in the current release although there were a couple fixes that are going into 1.5.. There shouldn't be anything stopping you from creating a custom driver with all of the attributes you need and using it now.

1 Like