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

Spelling and capitalization ?

The error basically says it doesn't exist.

def setLevel(value, duration)

Something like that is expected.

Thanks. I'll have a good rummage but I'm a poke and hope man. :smile:
We will see if I can solve this error.
Thanks again.
Cracked it.
Thanks for the pointer.
In the code there was this.
def setLevel(value)

Replaced it with this (as you suggested) and no more errors and the light turns on to the correct level.
def setLevel(value, duration)

I'm still seeing the error as I indicated above though.

As you know, HubConnect uses /eventsocket to "listen" for events. It turns out that the Lock Code data needed is not included in /eventsocket.

You'll have to work around this until such time as Hubitat updates /eventsocket... assuming they do.

I've created a new HubConnect driver and updated Server-Instance and Remote-Client to support RM's new Global Variable OmniSensor Connector. I'm not at all ready to publish this as I've tested ONLY the one attribute "variable."

However, as a preview:
I altered the Rule (on the "real" Hub):


where "LocKode" is the name of a GV Connector:


Logs show:

dev:2473 2019-08-31 08:15:30.472 pm info LocKode variable is Wife
app:2089 2019-08-31 08:15:30.406 pm info Action: Set LocKode to '%value%'
app:2089 2019-08-31 08:15:30.389 pm info TEST DOOR WHO UNLOCK Triggered
app:2089 2019-08-31 08:15:30.371 pm info TEST DOOR WHO UNLOCK: Yale DoorLock lockCode Wife

On the Receiving Hub, logs are:

app:2 2019-08-31 08:15:31.052 pm info Received event from ZeeRadioLower/LocKode: [variable, Wife null]
app:33 2019-08-31 08:15:30.961 pm debug Sending event to ZeeHomebridge: Yale DoorLock [lock: unlocked null]
app:2 2019-08-31 08:15:30.888 pm info Received event from ZeeRadioLower/Yale DoorLock: [lock, unlocked null]

On the "real hub" the RM Connector virtual "LocKode" shows:


On the receiving hub, the HubConnect 'mirrored' GV device shows:


The only real way to tell is that HubConnect has 'version:' at the bottom, the result of Sync.

From there, one should be able to alter the rule to 'speak/notify' with the value from the GV Connector.

Thank you for all of this...now please tell me I'm crazy and there is no way this was working previously? Because I swear...this worked a few months ago. But I'm old and maybe my memory just really stinks that bad. I'll poke around with some ideas and maybe see what I could add to the "RF" hub that has the lock to achieve the same goal. Try to keep as much code off that hub as possible.



A lot of sensor devices provide the temperature attribute, although it is rare that we really care about that attribute for most devices (obvious exceptions are thermostats and temp/humidity omniSensors).

Given a goal to keep the inter-hub traffic to a bare minimum, it would be awesome if there were options to disable temperature updates on a per-class basis (e.g., contact sensors, motion sensors, etc.). I have hard-coded this into my own installation, and it has reduced the traffic from my master to its slaves by more than 70% (temperature changes occur far more frequently than do motion or contact sensor changes).

FWIW, I already accomplish something similar by declaring power-reporting pocket-sockets as switches so that they don't forward the constant stream of minute power changes...and I can still get power data for those devices I want to by declaring them pocket sockets instead of switches.

Please consider this enhancement request for a future update to the HubConnect Server and Remote components...


HubConnect only DIRECTLY creates LAN traffic when Hubitat oAuth (http) is selected.


Using Hubitat Event Socket, and I assume this is the most selected option by HubConnect users, means that HubConnect doesn't send anything *, instead it listens to the always on, always sending Event Socket. (ws://[hub ip]/eventsocket)

  • HubConnect does ACK selected device traffic, so using Event Socket doesn't completely silence it. Also http PINGs are used, as well as any of the HubConnect Utilities.

What that means is HubConnect doesn't control what appears in the Event Socket. (aka event stream) As @jrfarrar discovered for us, Hubitat controls what is included in the stream.

By choosing a driver that doesn't expose the total capability of a device, you've found a means to limit a portion of the stream. I think we'll see more of this as time marches on -- in both directions. Maybe drivers that only offer ONE of the sensors in a MultiSensor6. Maybe drivers that add capabilities that don't exist in the physical. (I know I can now add calculated outdoor Luminance to any driver I create. ROFL. ) There's the new Virtual Omni Sensor that seems to have every sensor capability, used by RM GV Connectors. Dynamic drivers are not available and probably never will be, but a MultiSensor6 driver that exposes only 2 of the 6 means 15 different drivers.

It's interesting, but I'm deferring to @srwhite :slight_smile:

Another question. On my control hub I have an RGB bulb using the "HubConnect RGB bulb" driver. My bulbs (different manufactures) one in particular a Sylvania lightify led strip. Got kicked out of my google app (no longer showing up) When I went back into the built in google app to add it, I got this error:

app:1292019-09-01 07:42:17.706 pm warnThe following devices are not supported by Google Home and will be removed from your device list:[Bedroom Bed]

Assuming something changed in either the built in app or integration because I haven't changed anything lately with hubconnect. On this one I know for a fact I used to be able to turn this particular light on/off via google. Because I did it quite often.

Can anyone confirm or replicate using a Hubconnect RGB bulb in Google through HE?

The request is still valid for Hubitat—>SmartThings and Hubitat—>HomeBridge.

And yes, I have noticed that Hubconnect between two Hubitats delivers more than just the base set of features. For example, both my Ecobee Suite Thermostat and my MeteoBridge Weather Station update more than 30-50 attributes, and ALL of them will be replicated between two Hubitats, regardless of what device type I select them in.

This is less than optimal, especially because HubConnect will apparently override the HTTP connection and switch to web socket if both ends are Hubitat.

I wish it wouldn’t.

You can replace spaces with %20 in a URL, but for these Modes in Hubitat it is not a good idea. I keep my modes all to a single word (Morning, Night, Away, etc.)

1 Like

I just want to say you saved my life with this simple recommendation. Thank you, I will forever be grateful :slight_smile:

1 Like

Could you help me figure this out? How did you go about mirroring your Echo speaks devices?

Just bringing this back up again...assuming someone else here is using the Google app with hub connect. All of my RGB bulbs that are using the hubconnect stub won't sync with Google through the built in app anymore. Can anyone else confirm this?

I've pushed a small set of Universal Drivers that might be useful...


  • More of a 'hybrid' driver that incorporates a dimmer with the regular stepped speed.


  • Global Variable Connector driver.


  • Adds "lastCodeName" attribute.


  • Adds "ColorMode"

Any chance to add a temperature sensor driver that just does temperature and humidity? I created my own to use but others may find it useful too.

Thank you!

Was this to fix the fact that the stub driver wasn't passing WHO unlocked the door to RM?

LOL... yea, I guess that's correct, :smiley: it's the stub driver's fault that hubitat doesn't expose that.

but in reality it's just part of the solution. More to come later. :smiley:

LOL, yep, forgot about that...sorry

Weird error this morning:

org.h2.jdbc.JdbcSQLException: Column "name" not found [42122-197] on line 109 (setLevel)

That came from the HubConnect dimmer driver. Was working on something else looking at the logs and saw that pop up. It was being triggered by a Motion Lighting rule.

Why I get newer numbers than the latest version?