I recently bought my first Elevation hub and this is my first post asking for help. I have two buildings, each of which has a Z-Wave Plus switch for the exterior lights. One has a HomeSeer WD200+, and the other a HomeSeer WS200+. The buildings are too far apart for Z-Wave but are on the same wireless subnet. I'd like to have the doubleTap action of each switch control the exterior lights of the other building. Is it possible to do this with a second hub and HubConnect (or for that matter with HubLink/LinkToHub)? Looking at the posts it seems my switches are not supported. How hard would it be for me as a complete Hubitat novice with some past programming experience to create the required drivers? Thanks in advance for any pointers or suggestions.
HubLink will be fine for a plain old switch.
HubConnect will work too, of course, but it's a larger install process... worth it at the end, when you start adding all the rest of your devices... you know you'll be buying more devices, right? 
Thanks for responding! If I understand correctly though, a HomeSeer switch is not a plain old switch. If I set the device type to Generic Z-Wave Dimmer or Switch I no longer see support for the doubleTap command on the device page. The standard switch action is to control the local light directly, and the doubleTap command is to control the remote switch/light by being relayed over WiFi. Perhaps there's some way to use a "plain" virtual switch as an intermediary? I'm happy to install more apps and buy more hubs and switches, but if my scenario can't be supported I need to be returning everything I've bought so far instead.
Because of the double click desire, HubLink gets kicked to the curb, I'm afraid. It's not built to push any/every Event from hub to hub. HubConnect can.
As you point out, the HomeSeer devices are not natively supported by Hubitat and therefore HubConnect doesn't have a Universal Driver either. But HubConnect is extensible... it does allow you to create Custom Drivers within by identifying the Attributes (and therefore events)
This seems very punitive, even unfair for something that doesn’t state it supports this.. although ironically it could I think, especially with your apparent openness to programming.
This seems very punitive, even unfair for something that doesn’t state it supports this.. although ironically it could I think, especially with your apparent openness to programming.
Yeah, I should have left that thought to myself. I let some of my frustrations with the installation process, some of which are not Hubitat's fault, leak into my comment. I understand the HE hub is a work in progress and I expect to have to deal with its rough edges and growing pains. However, I still have to try to evaluate if I'm on the right home automation path before investing a lot more into it, and it's not that easy. I read the Hubitat wiki manual before taking the initial plunge, and the Link To Hub page states it can "control devices from one hub, on the other." I was counting on this as a backstop to anticipated Z-Wave range issues, so it was disappointing to learn afterwards this does not actually apply to the full set of devices. Having a developer community that can fill in gaps like these is a huge benefit. As long as HubConnect can support some kind of solution for me, even if I have to learn driver details, then I can at least proceed with additional hardware installation.
I may just be missing something obvious, but if I have one Hubitat hub and one ST hub, do I connect a client hub for the local Hubitat? (i.e. connecting to itself?) Or do I just set up the ST client connection?
Edit:
Also, not sure what device type I need to use for my Strips Comfort - Sensative device, which reports temperature, illuminance, and moisture (wet/dry), as it doesn't seem to show up on any multi/omni sensor choices... Only water sensor, which is the only capability I don't need 
The simplest HubConnect configuration is one Server (must be Hubitat) and one Remote (either Hubitat or SmartThings or Homebridge.)
The Server needs 2 App Code modules installed:
HubConnect-Server.groovy
HubConnect-Server-Instance.groovy (enable oAuth)
and 1 Driver Code module installed:
HubConnect-Remote-Hub.groovy
On SmartThings, install HubConnect-Remote-Client.groovy (from the SmartThings folder of Github) Enable oAuth
on the RECEIVING hub, drivers need to be installed. If you're sending devices from Hubitat to SmartThings, then SmartThings need the drivers. If you're sending devices from SmartThings to Hubitat, then the server hub needs universal drivers.
For Sensative strips, what "real" driver are you using?
Crazy thought....what if there was a way to directly assign a device from the client hub to a device on the server hub. My thinking is in a setup where you are using a hub as a RF hub (zwave/zigbee) and you need to replace a switch, update firmware, etc. With zwave you need to exclude and add back or even completely replace a switch with a different one. Once the new switch or newly paired switch is back on the client hub...what if you could specifically tell it which remote switch(device/etc) it should link to?
Then all automations that use that device aren't affected.
For Sensative strips, what "real" driver are you using?
I'm just using the built-in hubitat driver Strips Multi-Sensor, not a custom driver or anything
I don't think this is possible since each device, regardless of which hub it is on, has a unique device ID.
On the originating hub yes...but doesn't mean it can't map to a different device ID on the server....
That's not how z-wave or zigbee works.
No but that's how hubconnect works. It doesn't use the zwave or zigbee ID because remember not all devices are zigbee or zwave. they jut need to be unique. Hubconnect uses the IP address of the client plus the unique ID combined to define an ID on the server. So the mapping is already happening.
@csteele Still curious about how to get my Sensative strip to show as some kind of multi-sensor, so that it can feed temperature and illuminance to ST
You'll want to create a Custom Driver within HubConnect Server identifying the Attributes you need.
Create a new stub (universal) driver.
The native Strips driver has the following Capabilities, Attributes and Commands:
You'll use all the info to build a Custom Driver within HubConnect's Server app.
So will I just go and assign the list of attributes to match these? [battery, illuminance, syncStatus, temperature, water]? Does it matter which primary attribute is selected? I had it set up like this, but didn't seem to be showing up under either of the multi / omni sensors list that I'd assume it would go under:
It's just another device that you use to SEND events... in each Remote (on the server) there's:
and then the last Section is:
You should find your custom device within.
I'm still getting the same error. any help would be appreciated.
I may have discovered a small bug: it doesn't seem to like device names with forward slashes, at least in specific circumstances. I had a device called something like "XYZ Temp/Humidity Sensor" on Hubitat (server) that I was sharing to SmartThings (remote client), and I kept getting "httpGet() request failed with error 400" errors on the server instance that I couldn't figure out. I added more logging to the code and was able to figure out it was coming from asyncHTTPGet (or really the handler it runs), so I added another log to get the URL it was trying to bang against the ST server, and that URL returned nothing for me if I did it myself, so naturally HubConnect would fail, too. I'm guessing there is something off about the encoding of at least this special character.
Anyway, I changed the device name to use a hyphen instead as a workaround. Hopefully I won't have to do this at all anymore if Hubitat adds more sensor support to the Alexa skill, but for now, I can pretend my outdoor temperature sensor is a thermostat, using a webCoRE piston on ST to sync the remote Hubitat sensor with a virtual thermostat temperature on ST, then ask Alexa what the actual temperature where I live is. All thanks to HubConnect!
