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

csteele · January 27, 2020, 6:44pm

GVOmniSensor is:

GV = Global Variable.
OmniSensor = Driver with a lot of Capabilities defined.

The name is so confusing, v2.0 is renaming it to "HubConnect RM Global Variable Connector"

On one hub, you might have some RuleMachine Global Variables and Connectors defined:

23%20AM

On the connected hub, those would appear, individually, using the Universal driver that matches the selection. For String Variable Connectors:

25%20AM

Will become:

51%20AM

Perhaps you want to use: "HubConnect Moisture Sensor" universal driver? It has:

"Water Sensor"
"Temperature Measurement"
"Battery"

t30t28t16t12 · January 27, 2020, 6:54pm

Ah...that does it. "HubConnect Moisture Sensor"

Hit Sync and all is good.

csteele · January 27, 2020, 7:00pm

There's a feature in HubConnect Server...

You might find that helps.

jkudave · January 27, 2020, 8:49pm

Does this hold true for those of us mirroring devices from Hubitat to SmartThings only?

srwhite · January 27, 2020, 8:52pm

The HubConnect nodeJS server is completely optional and targeted towards power users. It is not a requirement of the new release. And since SmartThings does not support any type of websocket, it'll still continue to communicate using http.

Nothing to worry about there.

bptworld · January 27, 2020, 9:33pm

Curious if anyone else is trying to use the Homemade Env Sensors with HubConnect.

It doesn't seem to show up on any lists. Was hoping it would show up as an Omnisensor. Any suggestions would be appreciated!

csteele · January 27, 2020, 9:40pm

The ‘real drivers’ specify Capabilities.

CapabilitIes dictate HubConnect Selections.

Selections dictate the HubConnect Universal driver on the connected hub.

Therefore what real driver is used and what are it’s Capabilities?

bptworld · January 27, 2020, 9:52pm

definition (name: "Environment Sensor EX", namespace: "iharyadi", author: "iharyadi", ocfDeviceType: "oic.r.temperature") {
    capability "Configuration"
    capability "Refresh"
    capability "Battery"
    capability "Temperature Measurement"
    capability "RelativeHumidityMeasurement"
    capability "Illuminance Measurement"
    capability "PressureMeasurement"
    capability "Switch"
    capability "Sensor"

csteele · January 27, 2020, 10:07pm

Chances are you already have a switch defined and therefore you can find your device in the switch selector. If you’re using Event Socket then all the attributes are mirrored automatically.

bptworld · January 27, 2020, 11:01pm

Alright, so the device was found in the Switch section. I selected it and sent over to my other hub with all attributes. I could see it in the device list and all attributes are updating.

I then tried to add it to an app looking for humidity devices. It was still not listed in the app drop down.

Sooo, I started comparing the driver to another custom driver that has similar capabilities. One thing that stuck out is "RelativeHumidityMeasurement" vs "Relative Humidity Measurement" in the driver I was comparing it to. Once I changed that it showed up in the Omnipurpose Sensor Device list. Sent the device over that way and Bingo!, it now shows up in the Humidity drop downs.

Changed Capabilities in driver... (added spaces to capabilities that didn't have them)

definition (name: "Environment Sensor EX", namespace: "iharyadi", author: "iharyadi", ocfDeviceType: "oic.r.temperature") {
        capability "Configuration"
        capability "Refresh"
        capability "Battery"
        capability "Temperature Measurement"
        capability "Relative Humidity Measurement"
        capability "Illuminance Measurement"
        capability "Pressure Measurement"
        capability "Switch"
        capability "Sensor"

Thanks for the help!

csteele · January 27, 2020, 11:42pm

23%20PM

Hubitat's documentation shows no spaces. As far as I know, Hubitat (like ST) ignores case and whitespace.

srwhite · January 27, 2020, 11:55pm

This is correct.

All HubConnect drivers are built with the white space added for readability.

woodsy · January 28, 2020, 3:06am

app:28592020-01-27 22:00:46.026 errorFloRida is offline.

app:28592020-01-27 22:00:45.754 errorasynchttpGet() request failed with error 408

app:28592020-01-27 22:00:33.673 debugSending event to FloRida: Fridge Bar Food [temperature: 44.60 °F]

Any clue as to where to look?

csteele · January 28, 2020, 3:23am

408 = there's a timeout occurring.

If FloRida is ST, then the cloud is probably down. Wait.

srwhite · January 28, 2020, 2:05pm

ATTN Beta Testers: The code and upgrade instructions have been released! Please install the upgrade at your earliest convenience.

The HubConnect node server will be released in a few days to give everyone a chance to install the update and become familiar with it.

To keep this discussion relevent to the current 1.6.x branch, I kindly ask that the beta team file support tickets to report any issues found.

kraig109 · January 28, 2020, 2:14pm

Question of approach.

Many of us aim to have a dedicated Rules Hub, I suspect. However, for LAN devices, for example Sonos or Ecobee, does it make more sense to keep the devices on separate device hubs and interact with the speakers/thermostats via HubConnect, or install the Sonos and Ecobee apps on the Rules Hub and manage these devices locally?

I know basically either could work, but as a design discussion - is there a better approach?

srwhite · January 28, 2020, 2:38pm

Virtually everyone using multiple hubs has an opinion on this topic, and mine is just another "voice in the choir". The important thing is to think first about what you wish to achieve, then map out the topology that fits that design. Having all devices on one hub, and all rule on the other hub could make sense if for example, you use a lot of resource-hungry energy monitoring automations.

I also view that as an all eggs in one basket approach, in this case, you have two; rules and devices. Thinking about a potential failure vector, the loss of either hub basically trashes your entire HA environment. If that's not something you are worried about then there's nothing wrong with this approach. I would prefer to share what I did for my system, and you can decide if it's right for you, rather than tell you what you should do.

When I first went multiple hubs it was to address some (long fixed) reliability issues with Zigbee. This led me to adopt an upstairs/downstairs approach, with one hub in the basement, one on the 2nd floor, and a third hub acting as the server and aggregating those events. I've since added a 4th Hubitat hub into the home on the 1st floor to offload some processing which has helped mitigate the hub slowdowns a bit.

So what I have now is:

Server Hub, collects devices, runs some automations, presence, and is the entry point for Ecobee.
Hub 1, 2nd Floor hub has all of the door & window sensors on HSM, which creates a partition. This hub has all motion lighting devices for the 2nd floor so those automations stay as quick as possible.
Hub 2, Basement. Same as Hub 1, all basement door & window sensors for an HSM partition, all motion lighting devices for quick motion lighting automations.
Hub 3, 1st Floor. Some 2nd floor Zigbee devices, TP-Link devices, SONOS, Life 360, and a few others.

The server hub hosts all of my dashboards, it's also the host for Hubitat's app presence. It runs mode manager to manage modes based on presence, and hosts all rules that tie in devices located across multiple hubs. This includes all of my exterior lighting automation since those motion devices are Arlo cameras via SmartThings and UniFi cameras via Homebridge.

So what happens when a hub crashes, is upgraded, or rebooted is the impacts on the overall home are mitigated.

For example, when Hub 1 is offline for any reason, we lose motion lighting upstairs, HSM, and the ability to control lamps using buttons that override automation. But the outside lighting automations run, basement motion lighting runs, basement and 1st floor security is active etc.

Or, if I reboot the server hub, I lose dashboards but still have HSM working across the entire house. I lose exterior lighting automations but virtually all other lighting automations are unaffected. My server hub was recently down for a half of a day because the hardware failed. The impact of that was noticeable in that my DW is used to using a tablet dashboard in her craft room, but the home otherwise continued to operate as we expected.

I am sure others will post their own experiences as well. My advice is to study what others are doing and pick those elements which you feel would work best and build on them.

kraig109 · January 28, 2020, 4:41pm

thanks for the detailed thoughts

leeonestop · January 28, 2020, 5:58pm

I like your program and I like your approach and that is what I'm doing with my hubs and like the upstairs and downstairs approach. Thanks so much for you insight it is very much appreciated. This community rocks.

t30t28t16t12 · January 28, 2020, 7:02pm

I was told that there could be setbacks with Downstairs/Upstairs approach related to Mesh Network so make sure you have good repeaters for both mesh.