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

[csteele]

Rule created on 'coordinator' and the logs show:

app:65  2019-08-31 12:47:09.258 pm debug Sending event to ZeeSmart: MultiSenDomeU (office3) [motion: active null]
app:3   2019-08-31 12:47:09.230 pm info  Received event from ZeeRadioUpper/MultiSenDomeU (office3): [motion, active null]
app:33  2019-08-31 12:46:44.803 pm debug Sending event to ZeeHomebridge: Office Ceiling Light [level: 50 null]
app:3   2019-08-31 12:46:44.770 pm info  Received event from ZeeRadioUpper/Office Ceiling Light: [level, 50 null]
app:33  2019-08-31 12:46:44.000 pm debug Sending event to ZeeHomebridge: Office Ceiling Light [switch: on null]
app:3   2019-08-31 12:46:43.964 pm info  Received event from ZeeRadioUpper/Office Ceiling Light: [switch, on null]
app:33  2019-08-31 12:46:43.821 pm debug Sending event to ZeeHomebridge: Office Ceiling Light [level: 50 null]
app:451 2019-08-31 12:46:43.819 pm info  Action: END-IF
app:3   2019-08-31 12:46:43.784 pm info  Received event from ZeeRadioUpper/Office Ceiling Light: [level, 50 null]
app:451 2019-08-31 12:46:43.783 pm info  Action:     Dim: Office Ceiling Light: 50
app:451 2019-08-31 12:46:43.782 pm info  Action: IF (MultiSensor6A (officeDesk) active(T) [TRUE]) THEN
app:451 2019-08-31 12:46:43.744 pm info  Bobbles Test Triggered
app:451 2019-08-31 12:46:43.734 pm info  Bobbles Test: MultiSensor6A (officeDesk) motion active
app:65  2019-08-31 12:46:43.703 pm debug Sending event to ZeeSmart: MultiSensor6A (officeDesk) [motion: active null]
app:3   2019-08-31 12:46:43.673 pm info  Received event from ZeeRadioUpper/MultiSensor6A (officeDesk): [motion, active null]
app:451 2019-08-31 12:46:43.495 pm info  Action: END-IF
app:451 2019-08-31 12:46:43.431 pm info  Action:     Dim: Office Ceiling Light: 50
app:451 2019-08-31 12:46:43.428 pm info  Action: IF (MultiSensor6A (officeDesk) active(T) [TRUE]) THEN
app:451 2019-08-31 12:46:43.390 pm info  Bobbles Test Triggered
app:451 2019-08-31 12:46:43.383 pm info  Bobbles Test: MultiSensor6A (officeDesk) motion active
app:65  2019-08-31 12:46:43.347 pm debug Sending event to ZeeSmart: MultiSensor6A (officeDesk) [motion: active null]
app:3   2019-08-31 12:46:43.307 pm info  Received event from ZeeRadioUpper/MultiSensor6A (officeDesk): [motion, active null]

The Hub that has the Real Device logs show:

dev:1224 2019-08-31 12:46:41.091 pm info Office Ceiling Controller light was set to 50%
app:837  2019-08-31 12:46:40.245 pm info Received command from server: ["Office Ceiling Light": setLevel]
dev:1224 2019-08-31 12:46:40.110 pm info Office Ceiling Controller light was set to 50%
dev:1224 2019-08-31 12:46:40.109 pm info Office Ceiling Controller light was turned on
dev:845  2019-08-31 12:46:40.008 pm info MultiSensor6A (officeDesk) motion active
app:837  2019-08-31 12:46:39.930 pm info Received command from server: ["Office Ceiling Light": setLevel]
dev:845  2019-08-31 12:46:39.617 pm info MultiSensor6A (officeDesk) motion active
dev:845  2019-08-31 12:46:19.009 pm info MultiSensor6A (officeDesk) motion inactive

The difference includes the real driver we are using.. mine is a Hampton Bay Fan Controller, and I'm dimming the child driver of "Ceiling Light"

You're error is showing Missing Method Exception ... setLevel() from dev:101 which is your Lightwave driver... do you have another dimmer using a different driver?

[csteele]

I changed to a different device/driver and got the same "normal" result:

dev:744 2019-08-31 01:01:26.204 pm info Lutron Dimmer Module was set to 50% [digital]
dev:744 2019-08-31 01:01:26.202 pm info Lutron Dimmer Module was turned on [digital]
app:837 2019-08-31 01:01:25.072 pm info Received command from server: ["Lutron Dimmer Module": setLevel]
dev:845 2019-08-31 01:01:24.831 pm info MultiSensor6A (officeDesk) motion active
app:837 2019-08-31 01:01:24.753 pm info Received command from server: ["Lutron Dimmer Module": setLevel]
dev:845 2019-08-31 01:01:24.439 pm info MultiSensor6A (officeDesk) motion active

[bobbles]

Well done.
Just tried it on a Fibaro Dimmer 2 and it worked as expected. Light turned on to 20%. That error has now gone.
I'll have to look at that driver. I ported it over from ST. Going to be a bit cheeky here.
What should I look for in the driver that could be wrong. Any thoughts?

BTW I am still seeing this error though against the remote hub in the server hub logs.

@bobbles

[csteele]

@bobbles

What should I look for in the driver that could be wrong. Any thoughts?

Spelling and capitalization ?

The error basically says it doesn't exist.

def setLevel(value, duration)

Something like that is expected.

[bobbles]

Thanks. I'll have a good rummage but I'm a poke and hope man.
We will see if I can solve this error.
Thanks again.
YEAH!!!!!!
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.

[csteele]

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.

[jrfarrar]

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.

THANK YOU VERY MUCH!!!!!

[storageanarchy]

[ENHANCEMENT REQUEST - temperature]

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...

[csteele]

Interesting.

@storageanarchy

goal to keep the inter-hub traffic to a bare minimum

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

[jrfarrar]

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?

[storageanarchy]

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.

[ardjanbarnas]

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.)

[artistickatt]

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

[natemate]

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

[jrfarrar]

@jrfarrar

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

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?

[csteele]

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

HubConnect-FanSpeed-Controller.groovy

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

HubConnect-GvOmniSensor.groovy

• Global Variable Connector driver.

HubConnect-Lock.groovy

• Adds "lastCodeName" attribute.

HubConnect-RGBW-Bulb.groovy

• Adds "ColorMode"

[bfara83]

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.

[jrfarrar]

@csteele

Adds "lastCodeName" attribute.

Thank you!

[jrfarrar]

@csteele

HubConnect-Lock .groovy

• Adds "lastCodeName" attribute.

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

[csteele]

LOL... yea, I guess that's correct, 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.