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

⚙️ Custom Apps and Drivers Custom Apps
,
1

Current Release: 1.6.4 - December 29, 2019

HubConnect 1.x End of Life Notice
With version 2.0 about to be released, there will be no further updates to the 1.x codebase and all official support will end on 4-30-2020.

HubConnect - A new and improved way to connect and share devices across multiple Hubitat and SmartThings hubs to a central Hubitat hub. HubConnect replaces HubLink/Link to Hub and supports true bi-directional device linkages no matter where the device is physically located; SmartThings <--> Hubitat AND Hubitat <--> SmartThings.

Upgrade Instructions

Installation Instruction (New Installs)

Picture1

HubConnect replaces the native HubLink/Link to Hub apps and includes the following enhancements:

  • Support for multiple device attributes (i.e switch, power, voltage for a Zigbee Plug).
  • Battery status is available for any device that supports it.
  • Switches, Dimmers, RGB Bulbs, and Buttons are 2-way devices which can be controlled from the coordinator hub as well as the remote hub in which they are connected to.
  • Fully bi-directional. Connect physical devices from remote hubs to the coordinator AND devices on the coordinator to remote hubs!
  • When a remote device is controlled from master, status updates (i.e. switch) are instantly sent by the remote device to ensure the device actually responded to the command.
  • Full bi-directional SmartThings support including 2-way devices.
  • Hub Health ensures each remote hub checks in with the coordinator every minute. If a hub fails to respond for 5 minutes it is declared offline.
  • A virtual "hub presence" device is created for every linked remote hub. If the remote hub is responding, the status is "present", if it's offline the status is "not present".
  • This uses the "HubConnect Remote Hub" driver and is done so rules can be created to notify when a hub is not responding.
  • The virtual Remote Hub device also acts as a switch; when on the remote hub sends device events to the server, when off, communication is stopped. This is useful when installing hub updates to avoid errors being written to the hubs logs.
  • Flexible oAuth endpoints; Hubs do not need to be on the same LAN or even same location.
  • Remote hubs can be located anywhere with an internet connection.
  • Communications between the master and remote hubs can be suspended for maintenance. (i.e. rebooting the master hub as it prevents the remotes from logging http errors)
  • Publish user-defined device drivers without modifying HubConnect source code.
  • Mode changes can be pushed from the Server to Remote hubs, including SmartThings.
  • Remote hub "Reboot-Recovery" checks-in with the Server hub to set the current system mode anytime a remote hub is rebooted.
  • Bi-Directional Mode Support - Remote hubs can send mode changes to the server, which then pushes them out to all remote hubs.
  • From the server hub web UI, reboot and shutdown Hubitat hubs that are located on the same LAN.
  • HomeBridge Support! - HomeBridge (HomeKit) users can now connect directly to HubConnect without installing any additional apps.
  • Mode Report that generates a single view that queries all hubs and displays the available system modes and whether which direction that mode changes.
  • System Version Report queries all hubs for all app and driver versions to made updating easier. This report displays the currently available versions of all HubConnect modules.
    [] Hubitat Event Socket support eliminates slow http calls and is ideal for high volume, rapid movement of remote device events between hubs on the same LAN.
    [    ] Bi-directional Hubitat Safety Monitor (HSM) and Smart Home Monitor (SHM) allows HSM to share arming states between hubs, including SmartThings Smart Home Monitor.

HubConnect is built on a foundation of a parent-child server app connecting to a single remote app using oAuth endpoints. This means that hubs can be connected within the local lan AND across the internet! HubConnect virtualizes devices using lightweight driver stubs. These "stubs" are essentially stripped down drivers that contain no logic but expose virtually all attributes and commands that each class of device woudl typically support on the physical device. For locks, this attribute and command support is so complete that a single Lock Code Manger app can be used to centrally manage locks and codes across multiple Hubitat hubs!

56%20PM
56%20PM2320×206 41.7 KB

Connecting a remote hub is easy! Start by creating a server instance on the coordinator hub, grab the connection key and paste it to the remote hub. The remote hub will handshake with the coordinator and complete configuration.

56%20PM
56%20PM1776×800 52.4 KB

The following device classes are supported natively in HubConnect with the attributes listed next to each one.

  • Arlo Pro Camera: ["switch", "motion", "sound", "rssi", "battery"]
  • Arlo Q Camera: ["switch", "motion", "sound", "rssi", "battery"]
  • Arrival Sensor: ["presence", "tone", "battery"]
  • Button: ["numberOfButtons", "pushed", "held", "doubleTapped", "temperature", "battery"]
  • Contact Sensor: ["contact", "temperature", "battery"]
  • Dimmer: ["switch", "level"]
  • Dome Motion Sensor: ["motion", "temperature", "illuminance", "battery"]
  • DomeAeon Plug: ["switch", "power", "voltage", "current", "energy", "acceleration"]
  • Garage Door: ["door", "contact"]
  • Iris Smart Plug: ["switch", "power", "voltage", "ACFrequency"]
  • IrisV3 Motion Sensor: ["motion", "temperature", "humidity", "battery"]
  • Iris Z-Wave Repeater: ["status", "lastRefresh", "deviceMSR", "lastMsgRcvd"]
  • Keypad: ["motion", "temperature", "battery", "tamper", "alarm"]
  • Lock: ["lock", "lockCodes", "codeChanged", "codeLength", "maxCodes", "battery"]
  • Moisture Sensor: ["water", "temperature", "battery"]
  • Motion Sensor: ["motion", "temperature", "battery"]
  • Multipurpose Sensor: ["contact", "temperature", "battery", "acceleration", "threeAxis"]
  • Omnipurpose Sensor: ["motion", "temperature", "humidity", "illuminance", "ultravioletIndex", "tamper", "battery"]
  • Pocket Socket: ["switch", "power"]
  • Power Meter: ["power"]
  • Presence Sensor: ["presence", "battery"]
  • Ring Doorbell: ["numberOfButtons", "pushed", "motion"]
  • RGB Bulb: ["switch", "level", "hue", "saturation", "RGB", "color", "colorMode", "colorTemperature"]
  • Shock Sensor: ["shock", "battery"]
  • Siren: ["switch", "alarm", "battery"]
  • Smart Smoke/CO: ["smoke", "carbonMonoxide", "battery", "temperature", "humidity", "switch", "level", "hue", "saturation", "pressure"]
  • Smoke/CO Detector: ["smoke", "carbonMonoxide", "battery"]
  • Switch: ["switch"]
  • Thermostat: ["coolingSetpoint", "heatingSetpoint", "schedule", "supportedThermostatFanModes", "supportedThermostatModes", "temperature", "thermostatFanMode", "thermostatMode", "thermostatOperatingState", "thermostatSetpoint"]
  • Valve: ["valve"]
  • Window Shade: ["switch", "position", "windowShade"]

Note: Lock-code support is available only for locks connected to Hubitat.

HubConnect supports user-defined drivers! Have a unique device that does not fit any of the native devices? Add your own supported drivers without modifying any of the app code... Custom drivers are automatically synchronized with all connected hubs so they only have to be defined once.

20%20PM
20%20PM1768×780 43.5 KB

HubConnect organizes device selection for effecient device management. Device counts are provided for troubleshooting and bragging rights!

45%20PM
45%20PM1770×1194 185 KB

Get up your hubs connected running fast... Save time by NOT installing drivers until they are needed. Select the devices you wish to connect to the remote hub and HubConnect will instruct you which drivers to install.

18%20PM
18%20PM1756×932 129 KB

HubConnect Server is available for Hubitat hubs.
HubConnect Remote Client is available for both Hubitat and SmartThings hubs.

HubConnect 1.4 has been RELEASED to the Community Repository!

Installation Instructions

https://github.com/HubitatCommunity/HubConnect/blob/master/readme.txt

Please read the Installation Instructions and BACK UP YOUR HUBS before installing!!

Enjoy!

58 Likes
2

You're such a tease @srwhite :stuck_out_tongue:
I had hub link setup for a while but the atrribute/device type limitation made it incomplete and not worth the trouble for me. I think this would let me completely separate my custom/web based apps and drivers.
This sounds fantastic and I'll be reaching out to you and @csteele for advice when I'm ready setup my coordinator. Sooo glad you stuck around!

4 Likes
3

@srwhite
This is exactly what I was hoping the native link to hub app would do! I'll give it a try one it's released and report back how it's working for me.

How are you implementing the Ring Doorbell without Hubitat intergration? I have it setup on Smartthings right now with WebCoRE on ST to do a few things and using Alexa to turn on virtual switches with Hubitat.

1 Like
4

You can also do this natively in Alexa with the Ring skill. Alexa sees the doorbell as both a motion sensor and a button. I'm using 2 Alexa routines to flip a virtual switch in HE on motion and another one on doorbell press, but without having to go through the ST cloud to do it. :wink:

4 Likes
5

As @corerootedxb mentioned, there's no need for ST.
See this thread

2 Likes
6

That's exactly what I'm doing, I just have ST with WebCoRE to turn on lights for my other Ring devices.

Example:
If motion at front doorbell or front doorbell is pressed. turn on light at front garage (Ring Floodlight Camera).

I have it setup to turn off on that instance after 5 minutes. It's also setup to do that based on how much the illuminance level is outside as well, definitely can't be done that way with Alexa

Really nice at night if someone was outside my house.

3 Likes
7

I don't have a spotlight, but I do have a Floodlight and I can control it directly from HE using the details listed in this thread

2 Likes
8

I'll have to check that out when I get home.

2 Likes
9

This is true, however bridging through SmartThings is more flexible. It allows the Ring doorbell to be exposed as both a button AND motion sensor natively within Hubitat. I thought the Alexa integration virtualizes those as switches.

2 Likes
10

@srwhite Really looking forward to this .. thank you so much in advance for the time and effort to bring it to a release state.

1 Like
11

It does but can be easily remapped to motion with a custom driver or simply using on/off instead of active/inactive.

I originally used my ST hub to send events to HE but the delay was too much to be used with a lighting automation. The Alexa->HE virtual switches were MUCH faster and more consistent.

1 Like
12

In Alexa, it exposes the doorbell as a Camera type. For Routines, you have a choice of motion or button press.

But, I get what you are saying about native device types in HE based upon button and/or motion sensor and that makes perfect sense.

Screenshot_20190316-112350
Screenshot_20190316-112350.png1440×2960 186 KB

Screenshot_20190316-112548
Screenshot_20190316-112548.png1440×2960 154 KB

Screenshot_20190316-112514
Screenshot_20190316-112514.png1440×2960 153 KB

2 Likes
13

@srwhite Sounds pretty interesting. I'll be interested in seeing if a thermostat device type is doable within your architecture. I'm guessing that it might not since you need >8 variables for a thermostat device type.

Cool development, though!!!

1 Like
14

the 8 limit is for 'custom'. There's no limit for a built-in / native HubConnect driver.

To ALL NEW Readers of this topic...
This topic is 3300 posts long and covers items and issues that may be 2 years old and fixed. Skip Forward to maybe #2800

Skip To here

2 Likes
15

Bad assumption on my part then. And now that I look closer it seems the smoke/co has 10. Cool. Will look forward to taking a peek at this after released (and I'm back on the same continent as my hubs).

1 Like
16

I don't own a ZWave Thermostat. but using the Virtual Thermostat as a guide, I found only these 7 attributes:

"temperature", "thermostatFanMode", "thermostatMode", "thermostatOperatingState", "thermostatSetpoint", "coolingSetpoint", "heatingSetpoint"

My 'real' Honeywell WiFi Thermostat also shows the same attributes.

What are the additional >3 you see?

17

You are right on the properties (although I have at least 1 more than you listed - I miscounted the 1st time). If you include commands (again, I haven't seen the actual app so I don't know what is possible), there are more....

Commands (12):
AUTO, COOL, EM HEAT, FAN AUTO, FAN CIRC, FAN ON, HEAT, OFF, Cooling SP, Heating SP, Fan Mode (enum), Thermostat Mode (enum)

Properties (8):
coolingSetpoint, currentSensorCal (that is specific to my thermostat drivers), heatingSetpoint, temperature, thermostatFanMode, thermostatFanState, thermostatMode, thermostatOperatingState

1 Like
18

A Virtual Thermostat shows:

Current States
coolingSetpoint : 75.0
heatingSetpoint : 68.0
supportedThermostatFanModes : [auto, circulate, on]
supportedThermostatModes : [auto, cool, emergency heat, heat, off]
temperature : 68.0
thermostatFanMode : auto
thermostatMode : off
thermostatOperatingState : idle
thermostatSetpoint : 68.0

And when I pass that over HubConnect, I get:

Current States

coolingSetpoint : 75.0
heatingSetpoint : 68.0
temperature : 68.0
thermostatFanMode : auto
thermostatMode : off
thermostatOperatingState : idle
thermostatSetpoint : 68.0
1 Like
19

Yup, those are the 7 states I have. And I have one more custom to my thermostat drivers. So 8 total properties for me.

I miscounted the 1st time, thus my comment on >8.

No point in my speculating any further at this time I guess. I'll see what it can all do when it gets released. Looking forward to it.

1 Like
20

Do you use currentSensorCal in an automation or Dashboard? If not, then it's absence won't matter :slight_smile:

1 Like