I realize that some people have had issues getting things going, but I found the instructions very straightforward and didn't have any issues getting setup.
I can, however, see where people may be accidentally using the HE code when setting up things on the SmartThings side. I'm not sure how to clarify/simplify that any further, as the ST code is in a separate folder in the repo.
Thanks for your efforts with this great app @srwhite.
Thanks for all the hard work on this app, its going to be awesome. For the walk through, i think a couple of things could make things a little smoother for others in the future
I dont know if this is an option since its a PDF, but making it possible to copy and paste the links would make the process a whole lot easier. The URLs are long so its easy to make a typo when adding the link to the page in the device creation.
For the oAuth of the app, you might clarify that once you enable, click update before you close the window. It probably should have been obvious to me but i enabled oAuth and closed the window, saved it and ran into issues because i didnt update first.
For step 4, it might be a good idea to clarify what is considered a large system and that you really should go ahead an install the drivers one by one. The step made it sound like you could just import the whole group of them with that one link, but thats not the case. I struggled with that a little bit, too.
When it comes to installing the server app, you might specify that you go into the apps, then add an app and then you can select the app and add a hub.
Maybe these are all things most people would know to do. Im brand new to HE, so its different than smartthings and i think i struggled because of some ambiguity in the directions.
So I may be getting in deeper than my knowledge allows me, but let's see if someone can point in the right direction if this is possible.
I have a DMP alarm panel with Z Wave integration. They're pretty vague on their Z Wave integration instructions, but there is a part to it that allows linking controllers, the alarm panel being one of them. I don't think they link via IP address, but rather through the Z Wave from controller to controller. Does HubConnect allow for this integration?
Thanks in advance.
Unfortunately no, that’s a totally different mechanism. They are likely using a Zwave primary/secondary configuration. Hubitat doesn’t support it within their ZWave integration either.
Does DMP list any controllers that they know your one will link with successfully ?
You will get better help really in a new topic specifically for your issue ...
Finally able to set one device in each hub as my doneness test. I was in no hurry and took my time to set thing up, but I agree with what has been said before.
First I think that the drivers are not optional as stated in the instructions but you have clarify that you don't have to install them all.
Second It might be obvious now that universal drivers go with Hubitat drivers but upon first read of the instructions not so obvious. Should be stated period.
Third the first message upon connecting should be just that -Connecting not Connected!
Great work! thanks. I will soon figure out if this is useful for my Home Automation setup.
This is great! A lot of us power users tend to be developers and take things for granted. This is becomes visible of when we write documentation. As @csteele will attest I hate technical writing.
The documentation never states that the drivers are optional, only that they're optional at that portion of the installation.
Since the majority of communications flow from remote hub to server hub, this step is largely unnecessary. For any devices linked from the Server hub to the Remote hub, HubConnect will still alert which drivers are needed at the time of device selection.
Nevertheless, I'll endeavor to make it more clear in the next release.
The Universal drivers are for both platforms. In some cases native DeviceTypes have been made available for SmartThings, but those are considered to be in beta and are not guaranteed to work for all devices. That's why they're not mentioned in the instructions at this point,.
I opened mine in foxit PDF and links copied fine.
And PS- it took me over an hour, I went very slow and read everything twice. I had no problems, other than trying to pull myself away long enough to finish my taxes.
@srwhite - you did an AMAZING job, Thank You and @csteele , this is so fantastic. I can't imagine the endless hours you guys put in. I'm sending you some cash, which will be promptly spent on more HA gear(just a guess:grinning:)
Hi I just installed hub connect on my hubitat hub and ST, I use xiaomi door sensors connect to ST hub, trying to add them on hubconnect I'm getting an error
error The device [Bedroom Door] does not support the command refresh.
Anybody using xiaomi sensors? having this issue?
I seen the error, but you should not see it anymore unless you click refresh on the remote device, is not needed to click refresh. The HubConnect driver is generic so some functions works on all devices, other not.
I should probably change that to a warning so it’s not so alarmist. In the early stages of development those failures meant something.
You can safely ignore it. The HubConnect is just letting you know that specific driver doesn’t support the refresh command. There is unfortunately no way we can dynamically disable or hide unsupported commands. Not at this point anyhow.
Glad you got it up and running! 
That makes perfect, thank you. I will ignore the error and continue adding the rest of the devices. Then next homebridge to be added 
Great work you have done here
Edit: Does the battery levels/temp from contact sensors also show up on the remote device?
ANSWER: Depends 
You pick the devices and you pick them from Categories, which display SOME of the attributes:
You can look in the Remote-Client driver and you will see lines like this, pretty near to the top:
"contact": [driver: "Contact Sensor", selector: "genericContacts", attr: ["contact", "temperature", "battery"]],
which shows the Attributes that can appear on the other Hub... if the device (and 'real driver') itself
support it. For example, you have a door sensor and the manufacturer indicates it supports contact + battery. The physical driver implements that. Therefore, all that HubConnect can send is those two attributes.
It's a great question and I think I'll 'convert' that table into "Documentation"
Initial documentation of Attributes for each Selector.
For a 3210-L Iris plug (natively on HE) should the ST device handler optimally be Iris Smart Plug or Pocket Socket?
That depends on the driver you're using for the physical device. I publish an Iris Smart Plug driver that has extra reporting including voltage and AC frequency. You'll want to use the Iris Smart Plug selection in HubConnect to link to that device. If you're using the native Hubitat "Generic Zigbee Outlet" driver, then use the Pocket Socket selection instead.
Thanks, Steve. I am using your driver.
EDIT: What confused me is that there is not a "tiled" ST driver for the Smart Plug, just the universal driver; whereas the Pocket Socket has both. Thanks again.
Are there other hubs supported by HubConnect beside HE and SmartThings?
There is HomeBridge, although technically not a hub. I'm talking with a guy who is trying to resurrect Iris (Arcus) about integration since that would open the door to that platform easily supporting a lot of new devices. But as of right now, that's all we've got.
Perhaps to clarify for everyone... The Universal Drivers are for either/both SmartThings (ST) and Hubitat. A Driver must get installed on the 'virtualized end' -- the Hub that doesn't have the physical device.
IF your intent is to leave some devices on ST and have a virtualized device appear on your Hubitat Server hub, then the physical DTH on ST will have tiles and remain functional, while the Universal Driver is needed on the Hubitat side.
IF your intent is to run WebCoRE on ST and need some sensor data to be evaluated and/or device attributes to modify, then the same universal drivers will work.
If your intent is to use ST's App as your mobile app and want many Hubitat devices virtualized on ST, then you'd want Tiles and thus should overlay/replace the universal driver(s) with their identical drivers from the ST folder in the repo.
I have 5 hubs now... 3 Hubitat and then ST and Homebridge. (I only use ST to assist / help the Community with HubConnect.) I have a Garage Door Opener on a Hubitat Remote-Client hub. It uses the normal Hubitat driver for that physical device. On my Hubitat Server hub, I install a Universal Driver for Garage Doors and that allows me to Display the Garage Door conditions on Dashboard. It also allows me to send it to Homebridge (which doesn't have that device driver architecture, therefore needs no drivers.) As if that wasn't enough I can also send the Garage Door to SmartThings and, by using a HubConnect DTH, have what looks to be a completely normal Garage Door Opener appear in the ST mobile app.
Thus the deployment of HubConnect drivers can be summarized in two 'rules':
Add Universal Drivers on the Server hub for every physical device type on any of the Remote hubs you will be connecting.
On the Remote hub, you will need 'a driver' for every device type sent from Server, that doesn't exist there prior. For Hubitat hubs, use the Universal Driver also. For ST, if there's a HubConnect DTH (with tiles) use it. IF NOT, use the Universal Driver. The difference is (obviously) the addition of ST's tiles and therefore, the display inside the ST mobile app.
Great thanks I have one contact sensor that for some reason isn't showing the battery level but I will check it when I get home because the second ended up showing the battery level
Download the Hubitat app
