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

Yes but for those of us not running any other nodejs apps. spinning up a VM just to run one nodejs app is a lot less attractive than a docker container.

But no biggie. I don't really see me needing to use the HubConnect server anyway the way I have things set up.

And I know how to setup a docker container specifically for nodejs apps if I do. I've done it before.

1 Like

It's actually not hard to build a container from a NodeJS app for distribution. Thats something to consider but not on the intitial roadmap.

I don't know how many devices you have, but suffice it to say that performance is quite noticebly better in my environment.. Like close to a half second faster device response. But don't take my word for it..

In the 10 second video in the link below, I control an zigbee smart plug on located on remote Hub 2 through a dashboard hosted on my server hub.


It's odd to me that going through a broker would be faster than http/oAuth, but so be it! :wink:

If the broker is faster maybe I'll try it out. Faster is good.

Consider that the websockets are persistent connections it isn't all that unusual.. I think the overhead is in the http transaction.

The flow for device commands (http & Hubitat websocket) looks similar to this crude example..

[send hub] event fires -> call HubConnect eventHandler() -> call URLEncode() on event data -> call asyncHttpGet() ----> establish TCP session -> transfer data --> [receive hub] ACK/FIN --> teardown TCP session --> http request parsed & routed by hub -> call HubConnect mapping() -> call URLDecode() on event data -> execute device command()

With the HubConnect server the same flow looks like this since the socket is established and persistent...

[send hub] event fires -> call HubConnect eventHandler() -> call hcsSendMessage() -> call JsonOutput.toJson() -> webSocket.sendMessage() ----> [receive hub] data received & parse() called -> parseJson() event data -> execute device command()

I have no doubt the size of my system (555 devices) comes in to play as there's 2-3 events per second even after deduplication hitting the server hub.

There's also a great new driver that will be arriving with HubConnect 1.7 just in time for the holidays..

HubConnect Speaker

This driver was built and tested with Sonos speakers in mind but should work with a variety of LAN-connected speakers with existing Hubitat drivers.


I created this drawing yesterday and @srwhite has made it slightly obsolete already... half the command and control has been moved :smiley: so the Legend is off a bit...

Because of the Filtering and De-Duplication, the traffic seen and thus processed by each hub is more tightly targeted. Each hub has less to do, in other words. It's similar to what MakerAPI adds in the way it creates traffic after de-dup and Event firing is the Filter step.

My environment is dual sets of Hubs.. 3 'production' and 2 'development'. All 5 are feeding into the proxy/server and yet each hub receives only its targetted traffic. An Event enters the proxy/server from a 'production hub' and it gets distributed to only the two other 'production hubs' - nothing to 'development hubs' and vise versa. It's perfectly obvious that it should work like that but it's awfully cool to see. :smiley: (yes, that clearly means I have a geek badge. :crazy_face: )


Hi, apologies for my denseness (density?) - I'm trying to share Luxuriant from the Server Hub to a Remote Hub. I've set up a Custom Driver with "illuminanceMeasurement" attribute and saved it. Built a driver and installed it on the Remote Hub. When I go to HubConnect on the Server and try to Connect Local Devices, the new driver shows up under Custom Drivers, but I'm unable to select any device.

I am able to duplicate this.

I'll add it to my investigation queue. :smiley:

1 Like

Would HubConnect work with these Samsung SmartThings Wifi 1-pack SmartThings - ET-WV525BWEGUS | Samsung US ?

Work in what way?? It's a Meshed WiFi if I read it right.. it has nothing to do with Hubitat or HubConnect, because Hubitat is wired. In other words, since Hubitat hubs are wired devices, not wireless, the communication between them (HubConnect) is over the wire.

Wireless comes to play when you have devices (like Amazon Echo) that connect wirelessly but are visible to Hubitat simply because the local LAN is constructed to do so.

Are you asking if a SmartThings Hub, connected wirelessly can still be a HubConnect Remote? The answer is yes.

Samsung SmartThings Wifi 1-pack SmartThings - ET-WV525BWEGUS | Samsung US should double as a SmartTihngs hub
look at link; half way down the page

I think the same answer applies for those reasons. The SmartThings hub portion of that device is connected (via a wire inside :slight_smile: ) to the WiFi element.. which become just another part of the LAN.

Yes, it should work because the connection between a Hubitat Hub and that SmartThings device is a LAN, can largely ignore how it becomes a LAN.

Thanks, might be given it a try.

Several Community members have purchased a WiFi to Ethernet adapter. They plug their Hubitat in on the wired side and can walk around the house without the 50' Ethernet cable. The result is the same, Hubitat is on the LAN.

1 Like

I ordered and just received today a Zooz Zen16 Multirelay to use as a Garage door opener . Since Hubitat doesn't seem to have a driver for it, does anyone see an issue using hubconnect and smartthings hub and use the ST driver for this device through that hub on hubitat? I can test this if someone will tell me what universal driver to use on the hubitat side.

There is a HubConnect Garage a Door driver that should work for this device. When you share it after installing in the SmartThings app, select it in the Garage Door section and HubConnect will choose the correct driver for you.

Are these things okay for semi-permanent installations? I don't have any wires to the 1st floor.

Scratch that, I think my plan is to try ASUS's AiMesh solution and just add a 2nd router.

Again, I'd answer yes. It's just a device like any other and subject to failure over time, heat, etc. It's one more thing to debug :smiley: just as AiMesh is. In my eyes, the two are so very similar. Both receive Wifi, and thus have ethernet inside the box. The difference is how they present that result.. one regurgitates it as more WiFi, the other converts to a proper ethernet connector. :slight_smile:

However, I too have an ASUS with AiMesh potential and have long considered adding a 2nd... let me know how it works out. :slight_smile:

1 Like

Is it possible to view a Cloud Dashboard running on the Server connected via EventSocket? I'm unable to. Using oAuth is okay, but rather slow to load. I have also been having some issues with mobile presence because my mobile devices are connected to the Remote, while Dashboard is on the Server. Therefore when viewing a Server Dashboard in the mobile app with my phone, it's only connected to the Server hub and must not be registering presence. How are people getting around that?

I do. so I'm going to answer: yes

I have two hubs that are doing all the 'real work' related to Z-Devices (Zigbee and ZWave) -- one handles all my upstairs devices and automations, one handles the downstairs. My HubConnect Server is receiving all of the devices from thise two hubs, expressly for the purpose of running Dashboard and Homebridge, so that, in effect, Apple's Home App is my dashboard too. I'll be out and about and decide to check on the house and will use either the Dashboard shortcut or iOS Home app. They are functionally equivalent at the outer layer, Apple's has a nicer look and feel, but Dashboard can be used to look at History, if I feel the need.

I've never used the Hubitat App, so I can't comment on that. :frowning: