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

That fixed it, thanks.

I had only the first 3 status' on the device page for HubConnect. I pressed "on" and then the the bottom 2 appeared, and now the motion sensor are working.

3 Likes

Ok, multiple instances of not sending... yea, you have something very basic 'missing.'

41%20AM

1 Like

The yellow was missing in the device page, for some reason. After pressing "on", they appeared.,
image

1 Like

That happened to me once or twice before when I was developing the homebridge integration. You will never have to press that again....

3 Likes

"hidden feature" :smiley:

2 Likes

@csteele and @bertabcd1234

I am thinking that the group doesn't send back the necessary attributes so it hangs in limbo.

I was composing a message in my head earlier today.. "is there an open question that I've lost track of?"

Thanks for reminding me.. I installed Groups and Scenes on my Dev Hub and compared Capabilities, Attributes and Commands and thought they were well aligned to Hubitat's Virtual RGBW Light driver. The error @bertabcd1234 pasted indicates "setColor" may not be accepting the values as given.

@csteele just too much to keep track of!

My issue doesn't necessarily have to do with color. I have a set of white dimmable bulbs and a set of color bulbs too. Both experience the same issue with Alexa. I'll try and pull the logs for you but my specific issue is that Alexa comes back with the Device is not responding message when i ask for the lights to be turned on or off.

If the lights are OFF in the group and I ask for Alexa to turn them on it turns the lights on then waits and responds that the device is not responding.

If I then ask Alexa to turn the lights off the lights turn off and I get a response that it worked.

Now if the lights are ON in the group and I ask for Alexa to turn them off it turns the lights off then waits and responds that the device is not responding.

If I then ask Alexa to turn the lights on the lights turn on and I get a response that it worked.

So a sendevent that Alexa is expecting is not being set

I tried this again hoping to find some logs that help and didn't try Alexa because @bertabcd1234 suggested it wasn't... but I wasn't able to duplicate it.

I installed Groups and Scenes on the same Hub as a Real Hank bulb (RGBW) and then created a group ("testAgroup") and a virtual device was created with that name.

06%20PM

I then added that to HubConnect. On the server hub, where I have Alexa (but didn't use) the HubConnect device appears and seems to work fine. Changes made to the HubConnect RGBW device show on the real Hank Bulb.

I'll have to give alexa a try.

Would it be best to keep Sonos on the main hub, or move them to the client hub? I'm trying to keep my main hub free of apps/devices except default. I realise Sonos is a default HE app, but it may be better on the client hub.

Thoughts?

Edit: I'm hoping to put a TTS app on the client hub and keep it off the main hub. This is why I began thinking about Sonos.

@csteele Ok so Groups 2.0 in the 2.1.14 release has fixed this issue. It now reports on and off so that Alexa is happy.

This question might have been asked before...

If I use Hubconnect with a Smartthings hub, can I control devices that are linked to the Hubitat hub from the Smartthings app? I like the look of the new Smartthings app better than the Hubitat app.

Yes BUT...

You lose all local control. If the SmartThings cloud is bad, so is your control of Hubitat, since you would be shifting everything to Samsung’s cloud.

I am getting an error in my coordinators logs that seem to pertain to the remote hub driver.

error

I removed and reinstalled the remote hub and all seems to be working now.

Any thoughts as to my Sonos question:

I'm having a tough time determining that it would/could make a difference. You really want to put apps and drivers on the hub where the risk is mitigated. For me, I feel my "active Z-radio Hubs" are the very ones that I don't want to add risk. 90% of everything a hub does is local to that hub. All the Switches, dimmers, and sensors for any one room or hallway is on one specific hub. I have exceptions and those exceptions MUST use the server/'coordinator' hub to get the attributes distributed. (Zigbee exists on one hub only and thus those few devices that don't apply to the local switches and dimmers, get distributed.)

With three hubs, I have two "main hubs" -- one for upstairs and one for downstairs. 'Coordinator' is the third hub and is the HubConnect Server in my scenario.

Therefore I agree with your:

All 'real devices' and a big handful of virtual devices are mirrored to 'coordinator' where "everything" gets distributed outwards to Google, Alexa, Homebridge, and Dashboards. That includes Chromecast, which is my stand in for your Sonos... both are native HE apps/drivers.

1 Like

Hi everybody, I'm bringing some Arlo Pro cameras and siren associated with a ST hub to my Hubitat. That's the only use I have for ST Hub right now. Also, I'm using it to turn on and off a Samsung TV.

I'm not so sure if anybody noticed but the motion drivers don't seem to report the right status. The only one that gets through is the Battery Level. Well, I've tested it with my Arlo cameras so far, and although the devices are created with the right driver on my HE, it's not reporting any motion, rssi or sound detection. I can see some values on the events tab but it's not reporting any changes to the right status fields. Is it possible that I'm doing anything wrong? Maybe it's the driver or is it the App? I used the latest version from 4 days ago and I followed the instructions. Also, I don't know how the hub modes Away/Home/Night on a ST hub get synched with the Away/Day/Evening/Night modes from HE.

I don't have an Arlo cam, so I can't offer any specific advice...

Your Arlo(s) are on ST and using a functioning ST driver, I presume. That driver reports Motion as an attribute called "motion" correct?

HubConnect Remote Client on ST will see that attribute and send it to HubConnect Server Instance on your Hubitat. There's no real magic there, although the fact we can do this still feels magical to me. :slight_smile:

The HubConnect Universal Driver for Arlo exposes the following Categories, Attributes and Commands:

33%20AM

If the ST driver isn't manipulating one of those attributes, spelling/case SenSitiVe, then there's nothing for HubConnect to 'Inject' into the Server hub.

I was taking a look into it and apparently Arlo cameras report motion detection ONLY if you have armed them. Sad thing because if you arm them, you'll also be recording a bunch of events that you don't need to. SHM can control the actions like recording and stuff like that only if the Arlo system is configured to use the rule "SmartThings mode", so in conclusion, I'll need to arm the system to see if the reporting system actually works.

Here's how the driver looks in SmartThings:

1 Like