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

Thanks, where is the history tab?

edit....

I found it, it's inside the folders! I could do this yesterday and avoid all my stupid posts here.... Thanks again

1 Like

I guess I was over thinking things. Also trying to do things the "Hub Link" way which I still could but lose out on the really fun stuff.

I guess I have to keep thinking "controller" and expose my 2 client hubs devices to the server (as needed) and have my cloud apps like Alexa Skill operate on them via server rules instead of trying to create a million different virtual switches and local client rules. I also realize that for certain shared devices between all the hubs you would probably start at the Server and expose those devices to the clients.

Just trying to get a handle on good design practices for this!!!!

Thanks again (and again and again)!!!! :grin:

2 Likes

Installing the previous code worked fine!

D'oh! Wish I'd have known this last week, instead of going into WAF panic mode :joy:
Cheers!!!

2 Likes

I think you are overthinking this :slight_smile:

Eventsocket sends every event. Every -- Event. At LAN speeds. Products using this method are drinking from a fire hose, potentially. The more dedicated the Hub selected as Server is, the better the performance will be.

My Server hub is seeing very few events per minute because my home is very quiet right now. Others will see thousands of events per minute since many devices can get chatty. Power reporting devices come to mind immediately. I have 12 MultiSensor6's that send temp, RH and Lux every % change or every 5 mins. Not as chatty as power reporting, but similar in concept.

1 Like

This is exactly what I did, the server hub has about 15 devices total, and because you love so much Xiaomi devices I chose my hub with only Xiaomi for the server, so if I have a problem with a Xiaomi I will ask you or @csteele :stuck_out_tongue_winking_eye:

Thanks for the app, it's working!
I know there is a donation link, but that link works for @csteele beers too?

Good plan.. ask either of the two persons that have NO experience with Xiaomi :smiley: Steve has plenty of Zigbee experience at least. Me, I've got 4. Iris Motion (both v2 and v3) and a peanut plug. I have two Iris Outlets (unplugged as they are for Christmas Lights) and SmartThings Presence sensor. I've seen pictures of Xiaomi... I hope that will be enough. :slight_smile:

2 Likes

I have a question for you guys, my main hub between z wave, zigbee, wifi, LAN has about 110 connected devices, my second hub has like 16 devices most zigbee, z wave has 3 devices and it has nothing else. I'm using HubConnect server in the second hub and remote in the main hub.

What would be helpful to move from my main hub to the remote?

I have in the main hub
Google Home
Sharptools
Button controller
Chromecast
3 Cobra apps,
.......average all, message central and one 2 many
Groups and scenes
Dashboard
HSM
Simple lighting
IFTTT
Konnected
Motion lighting
Nest
Rule machine
Welcome home
Yeelight
Z wave poller

For example, if I move motion lighting to the server, all devices are in the remote hub, i must send those devices to the server, create the rules on the server, it will be more efficient or it will cause more lag because now I'm controlling all those devices remotely? I know probably just motion lighting app will not cause lag but what if I move half of the apps?

Thanks

HubConnect v1.2 is Available!

This release is all about speed and performance!

First off, please back up your hubs before installing or upgrading. It will make the rollback easier since every file in HubConnect has changed with this release!

This release features an improved Installation Guide with more details on each step.

How to Upgrade:

  1. Re-import ALL HubConnect apps and Drivers, including on SmartThings (if applicable).
  2. On your Server Hub, open each hub instance and click "Done" on the main page.
  3. Log into each remote hub (incl. SmartThings), open the app then click "Done" on the main page.
  4. Check to make sure your remote hubs are communicating with the Server hub.

Whats New?

  • SmartThings Arrival Sensor Driver. This native driver support all of the functionality of the SmartThings arrival sensors including tone (beep) capability.

  • Native SmartThings DeviceTypes. This release offers 13 drivers with a functional tiles user interface. These drivers can be imported right over existing Universal Drivers on the SmartThings platform to give connected devices functionality in the Classic app.

  • BETA: Hubitat Eventsocket support for remote hubs on local LAN. This provides a significant boost in the speed at which events from remote hubs are delivered to the server hub. By using a persistent socket the burden of subscribing to hundreds of individual device/attribute events as well as the overhead of using https to transport data is eliminated.

  • Asynchronous HTTP. For HTTP oAuth communications (Hubitat hub connected via internet an SmartThings hubs), asynchronous http transactions are now being used to improve performance of parallel event delivery.

  • BETA: Button Translation for SmartThings. SmartThings and Hubitat have different button implementation. This release adds a translation layer for physical buttons connected to SmartThings and linked to Hubitat to ensure that they will trigger automations correctly. Currently only push and held are supported. There is currently no translation to connect physical buttons in Hubitat to SmartThings.

Whats Fixed?

  • Failure to create virtual Hub Device upon connection of a new hub.

  • Connection key processing now performs a platform check to make sure the right key is being imported.

  • SmartThings: HTTP communication failures affecting devices that report temperature.

  • SmartThings: Command failures for devices with multiple parameters (RGB, Dimmers, Thermostats, etc.).

  • Standardized versioning across all apps & drivers.

SmartThings Native DeviceTypes

  • Arrival Sensor
  • Contact Sensor
  • Dimmer
  • Moisture Sensor
  • Motion Sensor
  • Multipurpose Sensor
  • Pocket Socket
  • Presence Sensor
  • Smoke/CO
  • Switch
  • Thermostat
  • Valve
  • Window Shade

Using Eventsocket Support

Once you have verified that your Hubitat environment is running smoothly after upgrading, you can choose to try out the new event socket support for all of your hubs connected on the same local LAN.

To change to event sockets, go to the Server instance for a particular hub and use the "Connect to Client Hub" wizard. More information on configuring event sockets can be found in the installation instructions.

While there is no hard data yet, I suggest using Eventsockets anytime at least 60% or more of devices on a remote hub are being connected to the Server hub.

There are a lot of changes to this release so please be sure to read the instructions carefully!

Enjoy!

5 Likes

Nice work!

Might want to version up the header/title in the install instructions. Still says v1.0.

1 Like

It works really well. The only detail in ST is Ring Pro button press is not working, I can see the motion change from inactive to active but no button 1 pushed on the server events.

I hope is not me not reading something about the buttons implementation between HE and ST :sweat_smile:

Thanks for the app!

edit; by the way, if I don't choose anything eventsocket and oauth, what is the default? I looked but it had nothing default.

1 Like

working great! don't know if this is by design or not, but on my controller hub, but events on remote hubs don't appear in the logs. it'd be nice to have that for debugging purposes.

1 Like

There is a big difference in button implementations between SmartThings and Hubitat. Even worse, there’s a few non-standard button handlers for SmartThings. Make sure you’ve imported the new ST RemoteClient SmartApp. If already did I’ll put this on the list of button devices to test.

By default oAuth (http) will be used if nothing is explicitly selected.

If you enable debug logging on each server instance you will see the events as received by the server hub.

Thanks, yes, I imported all new code, apps and drivers, in all hubs. Downloaded the new guide too.

1 Like

Ok.. I'll add put it on my list of buttons to test next week.

1 Like

@srwhite

Any chance to check if capability.securityKeypad for Keypads can be added? Unless I update the code to change to that for the capability, my Iris Keypad won't show under Keypads on Remote Client.

Release 1.2 is working great so far, I plan on sending a donation for all of the hard work you and @csteele has done.

Just upgraded on all my Hubitat hubs and SmartThings. Working well so far, even my problematic thermostat (tried enabling it on Alexa, the main reason I'm even using ST at all still...and hoping to get rid of my other awkward wokaround to make this work. :slight_smile: ) Thanks! Not brave enough to enable websockets (HTTP seems fast enough for me but my server hub is the one where I don't mind if things are a bit slower since the only thing I want to be super-fast are my lighting automations, all of which are now handled on a dedicated hub that sends its few events to my server hub).

1 Like

Crap... Thats on me as it was on the to-do list too. I've committed the change to the codebase. If you want to reimport the remote client and server instance code it will be there. :slight_smile:

It's like this thread got locked :smiley:

15hrs and no post... v1.2 been an improvement for me. Is everyone using Eventsocket from Hubitat Remotes to the Server? For moments when there's a lot going on, it should have improved the speed due to the persistent connection of Eventsocket.

In the Smartthings/DeviceTypes didn't have " Lock.groovy " . I use HubConnect-Lock.groovy in UniversalDrivers install in my Device Handlers. On ST app , it only show " 100% battery ", Tiles Missing. Please add DeviceTypes : LOCK on ST. Thanks.