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

That was quick!

Using HSM on my Coordinator hub, I have 2 keypads setup to arm and disarm HSM:

It doesn't seem to work at all, getting this error in logs:
The JSON input text should neither be null nor empty. on line 1409 (armNoticeHandler)

I modified the driver for the keypad since it was missing some commands so now the LockCodes actually displays and beep command works. Just not sure what else is missing that is causing this error and why it's not working.


It'll arm the actual keypad correctly from the looks at it, but it won't actually arm HSM. Anyone else have a keypad setup like that? Not too sure if this is a HubConnect issue or HSM issue.

Driver I added the following:

capability "Tone"
capability "Lock Codes"
capability "Sensor"

	Turns the beep on (if equipped).
def beep()
	// The server will update on/off status
	parent.sendDeviceEvent(device.deviceNetworkId, "beep")

	Arms the keypad to "Night".
def armNight()
	// The server will update status
	parent.sendDeviceEvent(device.deviceNetworkId, "armNight")

Thanks for the fix!

For me, it turned out helpful to change ${device.deviceId} to ${params?.deviceId} - that showed me that a device I had stopped linking to the remote hub was still making command/event requests (getDeviceId() was failing only because the deviceId wasn't among the selected devices any more).

Now, if I could only get the Custom Driver working...


Does it work correctly with the "real" device/driver and fail on a 'mirrored' device via Hubconnect? <-- IF yes,

Do the 'mirrored' device's attributes (Current States) change when the "real" device changes? <-- IF yes,

Do the buttons on the 'mirrored' device properly change the attributes on the "real" device? If yes,

Are all the buttons on the "real" device also on the 'mirrored' device? IF yes.....

I do not have any keypad, Steve has them and did all the testing. I can't test, in other words.

I'll PM you an updated driver that adds some additional commands. If you could assist by testing, please.

Is it possible to share Sonos from client to server? Alternatively, can I share a Aeotec Wallmote Quad from server to client?

I've got the button driver installed but figure that's not enough for the custom button that is a Aetoc Wallmote Quad.

I'm trying to keep all wifi devices on one hub and all zwave on the other.

@csteele if you have any ideas re: the error Iā€™m seeing above, Iā€™d appreciate any thoughts. Thanks!

yes, but I think the problem is that the ST cloud is/was having a problem that day. Possible?? The errors come and go?

the ST logs show it's trying to send.. but gets 2 errors. (real plus retry?) and they are received, but are missing pieces of an event. Nulls in places where nulls don't make sense, such as the device name. How can there be an event for nothing? :smiley: The messages don't identify which element is null and Events are not fixed length.

line 224 in HubConnect Server Instance is where the Event gets injected into the Server's Event queue, and there's a null in there. You may swap lines 225 and 224 for testing... that would put the log.debug first. It's possible the log would show which element is a null.

The wallmote now works in the latest version of HubConnect.

Regarding the HubConnect Presence Sensor... I'm working on migrating some rules from my main hub's RM to my 2nd hub's webcore, and hoped to consolidate one of my virtual presence management rules... But found that the HubConnect Presence Sensor does not expose any Arrived or Departed function.

I have this set up today:

Babysitter - virtual presence device set up on Hub 1
Babysitter Switch - virtual switch that is exposed to Alexa
Babysitter - Presence Based on Switch - RM rule to run Arrived or Departed based on the Babysitter Switch turning on or off, respectively
Babysitter - Switch Based on Presence - RM rule to turn Babysitter Switch on or off based on Babysitter Arrived or Departed, respectively

I was hoping to move this over to a webcore piston on hub #2, but currently there's no way to run Arrived or Departed from the remote hub.

Can't duplicate :frowning:

I created a virtual presence device on one hub, then connected it via HubConnect and I can change presence and it 'mirrors'

I then created a Rule to just detect then log presence changes... also works.

app:550 2019-10-07 11:59:08.522 am info not present on csteele Presence logging
app:550 2019-10-07 11:59:04.634 am info present on csteele Presence logging

I mean, the actual functions don't appear to be exposed for the HubConnect Presence Sensor. Are you changing the presence on the HubConnect hub, or are you merely changing the presence on the server hub and seeing that it propagates?

Here's the virtual presence on the main hub:

And here's the HubConnect Presence Sensor on the 2nd hub:

Presense Sensors are sensors. Not switches.


The Hubitat (and ST) specs say the same thing.. no commands.

A real presence sensor doesn't have them, and I agree that a VIRTUAL Presence Sensor needs to have buttons... in fact, I've created one...

It's what I've come to call a "hybrid driver" in the way it merges two drivers into one. Presence and switch in that case.

But the HubConnect Presence universal driver implements the spec... by leaving off the buttons/hybridization.

I suppose I agree with you on that. A physical presence sensor just reports whether it's present or not. But the virtual presence sensor needs some kind of programmatic control. Maybe we need a HubConnect Virtual Presence Sensor :):grin:

I made that change to the code, here are some logs. First a couple virtual sensors updated their status (ST has an integration with wireless sensor tags through a cloud-based API), then a ST virtual thermostat setpoint changed. Thanks for any insight!

OK, I'm totally stuck.

I can't get the Custom Devices page to come up on any Hubitat Remote Client, but it DOES work on SmartThings Remote Client. I have even tried replicating exactly what you did, to no avail. I get the Unexpected Error with nothing in the logs.

There seems to be something failing when the code tries to call the customDevicePage(), because it never starts executing in that page (I added a log.debug as the first line in that page). I can find no reason for the dynamic page call to fail on HE, yet work properly on ST.


1 Like

Is anyone else getting the same double present event when using Hubconnect arrival or presence DH?
The Arrival sensor is in the remote hub I am using for Zigbee and gets a one "present" event

On the sever hubs hubconnect arrival device events I get two a fraction of a second apart but enough to cause me grief.

presence present Ethan presence is present DEVICE 2019-10-04 12:57:00.771 PM MDT
presence present Ethan has arrived DEVICE 2019-10-04 12:57:00.684 PM MDT

Want to confirm it is a Hubconnect DH issue or an issue with my setup.

@csteele -

I found the problem - The Hubitat version of Hubitat Remote Client is missing the page definition for the customDevicePage - you need the insert the following at line 44 (or anywhere within the Preferences{} section):

	page(name: "customDevicePage")


HF9 is on github.

You also need to update the method used to count the custom devices in the Hubitat version of Hubitat Remote Client. In def devicePage() {, comment out line 1149 and insert 1150 as shown below:

1149        // totalCustomDevices += settings."${device.selector}"?.size() ?: 0
1150		totalCustomDevices += settings."custom_${devicegroup}"?.size() ?: 0

You will need the same edit in the SmartThings version of Hubitat Remote Connect, at line 1115.

Finally, you need essentially the same edit in the Hubitat HubConnect Server Instance at lines 1378/79.

1378		// totalCustomDevices += settings."${device.selector}"?.size() ?: 0
1379		totalCustomDevices += settings."custom_${devicegroup}"?.size() ?: 0

That seems to be enough to get custom devices working (I don't know how long the code has been this way, but I'm pretty sure that there's no way it would have worked in without these changes).

I spoke too soon - more edits required, pretty much for the same reason. In several places, the code looks in the wrong places to find the requested custom device. I'm tracking them down as we speak...