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

Hot diddly damn! Now I got to stay sober :joy::joy:

2 Likes

WHY doesn't this have 100000 likes???
come on people

2 Likes

Why would you do that??? Do you think I coded HubConnect sober? :crazy_face::rofl::upside_down_face:

7 Likes

I can't believe hasn't had a post in 13 hours! This is the most exciting thing to happen on here in quite a while. I for one can't wait to see this released :partying_face:

2 Likes

Probably due to the no drinking inference. Scared me!

4 Likes

A quick High Level Overview of what this upgrade entails for existing users:

There's an assumption that you're already using EventSocket communications, and v1.5 adds biDirectional EventSocket handling. If you're using http (oAuth) communications the benefits are much smaller. The odd thing is... there's no sonic boom after... there should be but it just silently works. :slight_smile:

First, the HubConnect-Remote-Hub.groovy driver will need to be added to the Driver Code of each (Hubitat) Hub. When the biDirectional connection is created, a virtual device named by default: Server Hub is created.

Second is the task of upgrading all the Apps and Driver code. The quickest method will be to use the Import feature of Hubitat. Each component of the App has a saved Import URL, assuming you've used the method previously. The process is reasonably simple: open the code, click Import, click Import, click Save. You'll do that for each component and on each hub.

HubConnect detects the new code version and you will need to visit the App and click Done as the Message indicates. This step is critical because the App needs to rebuild it's internals. If you don't see a completely smooth upgrade, chances are this is what was missed.

44%20PM

Another giant thanks goes to @dan.t for upgrading homebridge-hubitat-hubconnect

6 Likes

Man, we need you to go off camping more often. LOL
Sweet

3 Likes

HubConnect 1.5 is Available Now!!!

Here's a pre-Thanksgiving treat complete with Bi-directional websockets, performance improvements, a driver builder, and an updated look and feel.

Upgrading from 1.4? Here's a simple, step-by-step guide on how to upgrade to HubConnect 1.5. Be sure to download fresh backups of your hubs before you upgrade!

Installing from scratch? Check out the updated installation instructions.

What's New in HubConnect 1.5?

  • Fully bi-directional websocket support for locally connected Hubitat hubs. The use of websocket events have been proven over time to be faster and more robust than http communication.

  • Bi-directional websocket support for the Homebridge Remote Client.

  • Device driver report on the device selection page now includes direct links to GitHub to download the required driver files.

  • HubConnect Driver Builder (BETA) for custom devices. HubConnect can now automatically create stub driver code for custom devices.

  • Hub IP addresses can be changed without breaking linkage to virtual devices. A toggle in settings will trigger HubConnect to update the IP address information in all child device DNI fields when selected.

  • On some hubs, websockets events may start to lag. It is now possible to schedule automatic daily reconnection of the websocket at a specific time of day in the remote hub device.

  • Performance enhancements for http clients (Server & Remote).

  • Additional performance enhancements for websockets (Server) using an on-device of device ID's to make sure it's "subscribed" during parsing of the websocket event before passing the event to the parent app.

  • Streamlined device selection across server & remote clients for both size code reduction and consistency of user experience.

  • Arlo GO camera support (through SmartThings) using existing Arlo driver.

  • New Technical Support Report to export details about your HubConnect environment when troubleshooting.

What's Fixed or Changed?

  • Improved error handling and request timeout management for http communications to prevent a race condition where a healthy hub could be impacted by an offline or sluggish hub if the hub failed to respond to http request/events in a timely manner. This could lead to an excessive amount of open http requests.

  • Cleaned up & streamlined command processing.

  • Fixes for Custom Devices

  • Various UI Improvements/Enhancements

  • Turning off the switch in a remote hub device now stops ALL traffic between the server and the remote hub. Previously it disabled only event processing.

  • Fixed navigation bug after creating custom device.

  • Fixed timeout error in mode & driver report when hub is offline.

  • Virtual remote hub device now properly sets switch state (on/off) during installation and consistently when on/off commands are executed.

  • Improved ST <-> HE button event translation in SmartThings Remote Client.

New Device Drivers (Hubitat):

  • Hubitat Mobile App

  • Speech Synthesis

  • RGBW Bulb

  • Fan Speed

  • GV Omni Sensor

  • AVR

Updated Drivers (Hubitat):

  • Locks. Display Last Code Name

  • Keypad. Display Last Code Name

  • RGB Bulb. Fixed issue with SetColor.

  • Ring Doorbell standardized with Hubitat button implementation.

Updated Drivers (SmartThings):

  • Locks. Display Last Code Name

New Device Drivers (SmartThings):

None. (Sorry!)

Like with any new release there are bound to be a few issues here and there... As always, I ask for your patience and that you please post all support requests here in this thread. We will get to them as quickly as possible!

Good luck and happy upgrading!

7 Likes

I am happy to release the homebridge-hubitat-hubconnect 0.3.5 with HubConnect 1.5 released just minutes ago.

Major changes are:

  • Device updates retrieved via websocket
  • Added thermostat fan switch support
  • Added support for colorTemperature bulbs
  • Fixed thermostat low battery warnings
  • fixed iOS13 duplicate calling of setThermostatOperationgMode
  • Added Button support, limited to "push" for 1 button, see "programmable_buttons" for advanced programmable button support (thanks to @swiss6th for the code base)
  • Added automatic detection of free port
  • Added diagnostic website hosted by plugin to see/download log files and enable debug logging
  • implemented new support interface for HubConnect 1.5
4 Likes

Don't you need to go into each HubConnect Remote Client app and click done also? That isn't in the upgrade instructions.

I completed the upgrade, went flawlessly. Thank you!

To clarify, this is only on the server hub right? I don't see the option to make a stub driver on the remote client app.

Nope... Just go into the server hub and hit Done when prompted. It'll call updated() on the child instances and then make the calls to all of your remotes. :slight_smile:

1 Like

Correct. It's on the main server app where the configuration of custom devices is done.

Great news! Thank you for the feedback.

I'm not seeing it there either. I must be blind.

EDIT: I see it now... I had to make a driver and specify a few things, Save it, then go back in before the option showed up. :+1:

EDIT 2: That builder will be useful for certain scenarios. I think there is still an opportunity to make a builder that creates a stub based on an actual parent device, though (instead of specifying attributes by hand). Basically, specify the actual device to create the stub off of and create the stub driver though based on the actual capabilities and commands on the specified device. I was tinkering with that in a script yesterday, so I guess it doesn't really matter if it is built in to HubConnect or not since it can be done externally.

In my test script I do 2 MakerAPI calls (since I am doing this off-hub): one to pull capabilities of the physical device, and one to pull the commands of the physical device. Once you have those 2 things, you can make a stub driver identical to the parent device driver programmatically - with the exception of ENUM command types as the ENUM values aren't listed in the MakerAPI call return.

1 Like

I've followed the instructions to update but there seems to be an issue.
I have a server and one remote HE hub.
On the dashboard if I turn off a virtual switch on the remote hub, I get the 'sending' icon showing up permanently.
image
On the server hub's dashboard it does turn the virtual switch off.
Any thoughts/ideas.

EDIT: Same thing for a dimmer.

EDIT 2: Anybody else seeing this?

Did you import the "HubConnect Remote Hub" driver to update it on your server hub?
Did you install the "HubConnect Remote Hub" driver to update it on your server hub?

Both steps needed to be complete before going to the server app and hitting done.

If you followed those steps, go into the remote hubs at each end (Server & Remote) and make sure they both report a Connected status.

You can always go and hit done on both the server and remote again to force a reinitalization of both apps.

@dan.t upgrade still the same?

I notice on my server, the HubConnect Hub devices still say v1.4 on their current states field.

Is that correct? And, yes, I did import and save the updated HubConnect Hub driver (on all 3 of my hubs - client and server).

EDIT: After hitting initialize, it changed to v1.5.0...

Capture