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

OK - in Hubitat Server Instance, and Hubitat Remote Client on both platforms, you need to fix the same reference in the getDevice(params) function so that it uses the ${groupname} instead of the ${device.selector}.

@csteele

OK, the above fixes appear sufficient to make Custom Devices fully functional, supporting all the defined Events (from the source Capabilities) and Commands in the supplied Custom Device Driver. I have successfully (:crossed_fingers:) linked devices from Hubitat Remote Clients to a (centralized) Hubitat Server, and then linked them from the Hubitat Server to a SmartThings-based Remote Client.

A couple of things I learned:

  • You do in fact have to install a version of the Custom Device Driver on any SmartThings Remote Client, or it can't create the client device. (Probably need on HE Remote clients, too - see below)

  • Said SmartThings device probably should include tile definitions, with all the tiles/commands that you want exposed. Most importantly, you will want a sync and a version tile, so you can verify that the ST device is in fact connected to the Server

  • If you are only forwarding devices from ST or HE Remote Clients to a centralized server, you don't need the Custom Device Driver on the Remote Clients.

  • But if you want to send Custom Devices from the Server to the Clients, I'm pretty sure you need the Custom Device Driver on your ST & HE Remote Clients.

Once it is all working, it is pretty cool...

Also, FWIW, I have code modification to Hubitat Server Instance that reflects the userName from Rboy's Lock DTH into the HE lastUsedName. lockCodes is still in a different format, but that's easily fixed.

Using Rboy/SmartThings locks instead of HE's is WAAYYY better :slight_smile:

Yes, the custom driver -- which is why in my test example I used an existing HubConnect driver... to save a) writing what would amount to a duplicate, and b) spreading it around my Hubs.

That's directional of course, but yes, writing a Custom Driver entails all the portions :smiley:

The purpose of the driver is largely "local" -- local to the Hub If you want buttons etc, much like you want Tiles on the ST end, then you'd want a more complete stub driver. Effectively Hubitat includes 'tiles' by capability on their side.

yes.. but I don't use it much since, in most cases, the driver I write for some need probably deserves going in the Repo.

(FWIW, I intended this post to help others who might be trying to implement custom drivers in HC).

Yes, it is very nice that Hubitat gives 'tiles' for each command a driver exposes; my comment was that a ST driver needs the two additional tiles to be most useful/similar to the HE experience.

And I needed a custom driver for my EcoNet Vents because:

  • Hubitat doesn't supply a standard driver for this device (it's basically a dimmer, with open/close commands in addition to on/off), so I use the one I originally created for ST, ported to HE
  • the implementation was throwing errors on the HubConnect Server if apps on my Client hub (SmartThings) invoked commands not supported by a standard "dimmer" - my driver supports open, close, configure, and refresh, while the stock dimmer device doesn't. This is probably a ST thing, because the HE eventSocket approach doesn't seem to suffer from the same problem

You should have Collaborator access to:

https://github.com/csteele-PD/HubConnect

assuming you accept. :smiley:

I also invited you as a Member to:


You can create Repo's there, and at a minimum I'd suggest adding a "pointer" to your personal github. (Look at Ogiewan, as an example.) You can of course make this your Release repo and use your personal as Beta/development.

I have a Fan (Bedroom Fan) connected to HE using the Bond Hub. Works fine.
I have multiple hubs and as only one hub can use the Amazon Echo Skill I have the Fan replicated using HubConnect to my "Grand Central Station" hub.
HubConnect sees it as a device type of "HubConnect Fan Controller", the Echo Skill ignores this device type. If I change type to "HubConnect FanSpeed Controller" it gets recognised by the Echo Skill and I get a message in the Amazon App saying that "Light Bedroom Fan" was found, however it gets created as a type of "Switch" and selecting my device "Bedroom Fan" in the Amazon App simply displays a screen "Waiting for Hubitat...." and three alternating dots.... forever.

Anyone any ideas what I've done wrong or how I can get this working?

Thanks,
Simon

you can try setting it to be a HubConnect Dimmer and see if Echo likes that better.

Nope - same behaviour when redefined as a Dimmer.
Amazon App gets to other HubConnect devices just fine.