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

[csteele]

I'm unable to duplicate. I tried my Virtual Shades on one hub, and looked at Dashboard on 'coordinator' and it works as expected.

In other words, my 'source' was what I think of as the 'real device' which in this case just happens to be a real virtual device. and the 'destination' is the Server/Master/'coordinator' Hub.

'source hub':

app:837 2019-03-27 09:06:04.131 am debug Sending event to server: testshade2 [windowShade: closed null]
app:837 2019-03-27 09:06:04.122 am debug Sending event to server: testshade2 [position: 0 null]
app:837 2019-03-27 09:06:04.120 am debug Sending event to server: testshade2 [switch: off null]
dev:902 2019-03-27 09:06:04.028 am debug nextState: closed
app:837 2019-03-27 09:05:59.079 am debug Sending event to server: testshade2 [windowShade: closing null]
app:837 2019-03-27 09:05:50.755 am debug Sending event to server: testshade2 [windowShade: open null]
app:837 2019-03-27 09:05:50.720 am debug Sending event to server: testshade2 [position: 100 null]
app:837 2019-03-27 09:05:50.717 am debug Sending event to server: testshade2 [switch: on null]
dev:902 2019-03-27 09:05:50.620 am debug nextState: open
app:837 2019-03-27 09:05:45.697 am debug Sending event to server: testshade2 [windowShade: opening null]

'destination hub':

app:19  2019-03-27 09:06:04.367 am info  Sending DEVICE Event (testshade2 | WINDOWSHADE: closed) to Homebridge at (.129:8005)
app:19  2019-03-27 09:06:04.366 am info  Sending DEVICE Event (testshade2 | POSITION: 0) to Homebridge at (.129:8005)
app:389 2019-03-27 09:06:04.342 am debug Sending event to server: testshade2 [position: 0 null]
app:389 2019-03-27 09:06:04.340 am debug Sending event to server: testshade2 [switch: off null]
app:389 2019-03-27 09:06:04.339 am debug Sending event to server: testshade2 [windowShade: closed null]
app:19  2019-03-27 09:06:04.290 am info  Sending DEVICE Event (testshade2 | SWITCH: off) to Homebridge at (.129:8005)
app:41  2019-03-27 09:06:04.247 am info  Received event from ZeeRadioUpper/testshade2: [switch, off , isStateChange: true]
app:41  2019-03-27 09:06:04.233 am info  Received event from ZeeRadioUpper/testshade2: [windowShade, closed , isStateChange: true]
app:41  2019-03-27 09:06:04.230 am info  Received event from ZeeRadioUpper/testshade2: [position, 0 , isStateChange: true]
app:41  2019-03-27 09:06:00.088 am trace Received ping from ZeeRadioUpper.
app:19  2019-03-27 09:05:59.192 am info  Sending DEVICE Event (testshade2 | WINDOWSHADE: closing) to Homebridge at (.129:8005)
app:389 2019-03-27 09:05:59.185 am debug Sending event to server: testshade2 [windowShade: closing null]
app:41  2019-03-27 09:05:59.141 am info  Received event from ZeeRadioUpper/testshade2: [windowShade, closing , isStateChange: true]
app:389 2019-03-27 09:05:50.992 am debug Sending event to server: testshade2 [windowShade: open null]
app:389 2019-03-27 09:05:50.961 am debug Sending event to server: testshade2 [switch: on null]
app:19  2019-03-27 09:05:50.929 am info  Sending DEVICE Event (testshade2 | SWITCH: on) to Homebridge at (.129:8005)
app:19  2019-03-27 09:05:50.917 am info  Sending DEVICE Event (testshade2 | WINDOWSHADE: open) to Homebridge at (.129:8005)
app:19  2019-03-27 09:05:50.890 am info  Sending DEVICE Event (testshade2 | POSITION: 100) to Homebridge at (.129:8005)
app:389 2019-03-27 09:05:50.888 am debug Sending event to server: testshade2 [position: 100 null]
app:41  2019-03-27 09:05:50.843 am info  Received event from ZeeRadioUpper/testshade2: [position, 100 , isStateChange: true]
app:41  2019-03-27 09:05:50.834 am info  Received event from ZeeRadioUpper/testshade2: [switch, on , isStateChange: true]
app:41  2019-03-27 09:05:50.833 am info  Received event from ZeeRadioUpper/testshade2: [windowShade, open , isStateChange: true]
app:389 2019-03-27 09:05:46.904 am trace Received ping from ZeeSmarts.
app:19  2019-03-27 09:05:45.852 am info  Sending DEVICE Event (testshade2 | WINDOWSHADE: opening) to Homebridge at (.129:8005)
app:389 2019-03-27 09:05:45.847 am debug Sending event to server: testshade2 [windowShade: opening null]
app:41  2019-03-27 09:05:45.819 am info  Received event from ZeeRadioUpper/testshade2: [windowShade, opening , isStateChange: true]

I also tried from ST (source) to 'coordinator and see this in it's logs:

app:412019-03-27 09:20:12.726 am infoReceived event from ZeeRadioUpper/MultiSenDomeU (office3): [motion, inactive , isStateChange: true]
app:3892019-03-27 09:20:04.901 am infoReceived event from ZeeSmarts/Iris Contact Sensor: [contact, open , isStateChange: true]
app:3892019-03-27 09:20:03.516 am infoReceived event from ZeeSmarts/Iris Contact Sensor: [contact, closed , isStateChange: true]
app:3892019-03-27 09:20:02.381 am infoReceived event from ZeeSmarts/Iris Contact Sensor: [contact, open , isStateChange: true]
app:3892019-03-27 09:20:00.849 am infoReceived event from ZeeSmarts/Iris Contact Sensor: [contact, closed , isStateChange: true]

[kevin]

But mine was the other way round. Controlling from the coordinator back to the local device on ST, the device was a dimmable bulb and the error is in the ST log.

[csteele]

@kevin

But mine was the other way round.

Ok, I guess I read Robert's first ( @bertabcd1234 ) and his sounded the way I just tested, so let me test the other way, now.

THAT I can duplicate

[kevin]

... phew.. that always makes things easier to fix...

@csteele

THAT I can duplicate

[csteele]

You know that Whack-A-Mole arcade game??

This is like that. A fix for that broke this, I suspect.

[Royski]

I've just updated to the latest, and now not able to use buttons, or switches?

app:52642019-03-27 05:15:06.289 pm errorThe device [New Lucys Dresser] does not support the command on.
app:52642019-03-27 05:15:04.102 pm errorThe device [New Lucys Dresser] does not support the command on.
app:52642019-03-27 05:15:01.509 pm errorThe device [New Lucys Dresser] does not support the command on.
app:52642019-03-27 05:14:10.630 pm errorThe device [Olivers Bed Light] does not support the command on.
app:52642019-03-27 05:13:43.173 pm errorThe device [Ollivers Reading Light] does not support the command on.
app:52642019-03-27 05:12:51.969 pm errorThe device [Olivers LED] does not support the command on.
app:52642019-03-27 05:12:29.346 pm errorThe device [Olivers Bed Light] does not support the command on.
app:52642019-03-27 05:11:54.665 pm errorThe device [Olivers Bed Light] does not support the command on.

The dresser is a button, the others are generic Zigbee switches

[csteele]

yes, as far as I know, I have two items I'm looking at:

"does not support the command xxx" <-- duplicated but it's a portion of a previous fix.

and @JasonJoelOld Custom Command question(s).

I'm building out a test device as the next step for Jason, 18 attributes, so I can pick a 'favorite' 8.

[Royski]

Ok cheers. But crap, the WAF is gonna be at an all time low, as all my rules are on that hub. GULP. Its almost 17:30 here. I'm in trouble.....

[srwhite]

Hey all.. The device commands should now be completely fixed across both platforms.. The issue came down to a check that is performed against the physical device before attempting to execute a method from a virtual device. Iterating though device.supportedCommands (using find) was comparing inconsistent datatypes thus giving inconsistent results between SmartThings and Hubitat. Each time it was fixed on one platform, it broke the other.

It's now standardized and heavily tested in both Hubitat and SmartThings..

I apologize that this was not caught in testing last night. My attention was split across this and the 2.0.8 upgrades which did factory reset one of my hubs.

The update is in the public repo.

Modules updated:

• HubConnect Server Instance
• HubConnect Remote Client (SmartThings)
• HubConnect Remote Client (Hubitat)

Regarding @JasonJoelOld thermostat. This will get more attention in the next release. The focus now is getting consistent functionality across both Hubitat and SmartThings with little, if any platform specific modifications.

[greg]

@srwhite

The device commands should now be completely fixed across both platforms

Confirmed that the issue is resolved for me. Thanks for the quick fix!

[JasonJoelOld]

@srwhite

This will get more attention in the next release.

No hurry at all. You are definitely working on the most important stuff first, as it should be.

[cstory777]

@bertabcd1234

@cstory777

do Virtual Devices not get shared? I have 2 virtual switches that I've selected on my client and they are not showing up on the server.

I'm technically having this problem too, but it's any device I choose on the client not showing up on the server after the latest update. Could that be happening to you, too, and this is just how you noticed it?

All of my devices showed up fine. I then decided to add 2 virtual switches to the list of devices being shared from client 1 to the server. They haven't shown up.

[csteele]

Unable to duplicate

I created a brand new Virtual Switch, added it to HubConnect on my "upper" hub and it showed on 'coordinator':

2019-03-27 01:49:43.787 pm trace Creating Device HubConnect Switch - testsw... .68:1128...

and it shows in the device list... after browser refresh of the page.

[cstory777]

Well then I'm stumped.

[srwhite]

I cannot replicate either. Please make sure that you have updated the server instance AND remote client code properly. What you are describing is the bug that was fixed today.

I'm sure you've already done that, but it's the first logical step to confirm.

[cstory777]

I updated them about 9am EST this morning. I'll see if there is a newer update when I'm done with work.

[srwhite]

There is. See my post from a couple hours ago. That specific bug was found and fixed this afternoon.

[BorrisTheCat]

which apps do we need to turn on auth on, it doesn't say in the instructions.

[cstory777]

@srwhite

There is. See my post from a couple hours ago. That specific bug was found and fixed this afternoon.

That did it. Thanks!

[JasonJoelOld]

Server Instance and Remote Client