Thought he was back when RC2 came out. Lol. My mistake.
Right. I just assumed (incorrectly, obviously) that v2 stuff would be in a different branch in the same repo, not in a completely different repo.
1 Like
The device drivers are all available on the HubConnect.to site with the app. @csteele was kind enough to add all of those drivers to a separate repo that can be downloaded all at once by using Hubitat Package Manager, but @srwhite is the author of the code.
1 Like
HubConnect is released under two independent Licenses.
The Universal Drivers & SmartThings Device Types are all under the Apache License, Version 2.0.
The App is released under the HubConnect license agreement.
Making an effort to protect the License is the reason behind having an independent repo. Github has a reputation that everything is Open Source, no one reads/respects the Licenses found there, in other words.
3 Likes
I have a Samsung TV connected in the new SmartThings app. I have added the TV to HubConnect as an AVR and it works fine. However, I don't see the source listed even though in the ST app, I can see the source and also, use it for automations. Please anyone know if there is a source in the AVR driver or how else I can get the source of the TV?
Thanks. I'm aware of that driver and also on that thread but that driver doesn't give the current source (or any state/attributes of the TV). Right now, it's just a remote control for the TV. Not sure if that driver would ever get info on the TV but since all that info is already in SmartThings, would like to get it from there.
Hubconnect friends.....
Is the below error from Hubconnect? The way I have modes configured, mode is set based on some logic on my server hub and then sent to (but NOT received from) the remote hubs. From what I can tell, the remote hubs are receiving and processing the mode change correctly. But I’m getting the below errors for each remote hub every time mode changes.
So what does this log error indicate?
“Ignoring mode change event... Mode changes are disabled on this hub.”
it's a warning.
log.warn "Ignoring mode change event... Mode changes are disabled on this hub."
It's one of the BIG changes in RC2.. to downgrade that message from an Error to a Warning. 
If you are expecting Modes to be accepted by that hub, well, you have to check the settings, but if you don't, well then it's expected you'll ignore it.
1 Like
That makes sense, thanks. The OCD in me has some need to act on errors. 
2 Likes
So, i'm pretty embarrassed, but I forgot how to add my cell phone as a ST Presence sensor in Hubitat. Just got my new phone and it's been so long since I did it, I simply forgot. Any assistance is appreciated.
maybe it would be better as a trace? warning is still alarmining when it is just saying. "by the way you haven't told me to accept this mode change? Just letting you know just in case you wanted me to act on it."
Is there a better place to post HC issues than in this thread with 3800 messages?
Perhaps I missed it, but I didn't see anywhere in the docs that you need to install device drivers on ST in order to have devices in HE show up on ST. Of course, it makes sense and I guess that's why they're called "universal" drivers, but it would be good to state (or emphasize) that somewhere for noobs to HC.
Also, in the HE UI when adding devices to share it shows this:
Shouldn't it say "are installed on the Remote hub"?
Ok, so the link takes me to the v1 drivers. Since I'm using 2.0, I go to https://raw.githubusercontent.com/HubitatCommunity/HubConnect/master/UniversalDrivers/HubConnect-Bulb.groovy and install that on the ST hub, and I get:
Java.lang.RuntimeException: Metadata Error: Capability 'ChangeLevel' not found.
So I go to HubConnect_v2_Drivers/SmartThings/DeviceTypes at master · HubitatCommunity/HubConnect_v2_Drivers · GitHub and there's no Bulb driver.
What am I doing wrong?
** Final Edit:**
Further tests, seem to indicate that the category under which you select a device determines what driver is needed. I selected this device under "Bulb Devices" and it says I need the Hubconnect Bulb Driver. The universal bulb driver throws an exception as mentioned above, and a ST-specific 2.0 bulb driver does not exist.
If select this device under Dimmer Devices, it tells me I need the Hubconnect Dimmer Driver.
If I select both, it tells me I need both and attempts to create two devices on the ST side. Why would a single device appear in more than one category? It should only appear in one. If there's some reason it really needs to appear in multiple categories, then selecting it in one place should deselect it in the other. Or at the very least a warning should be displayed.
@csteele Please any idea if this is possible? Would love to get the "current input source" as a current state for the HubConnect AVR driver.
Thanks
If it can be done, it would be by using the built in custom driver builder. Click on ”manage custom drivers” in the Hubconnect server app, then
As @Ken_Fraleigh suggest, a Custom Driver is probably the best option at this time. HubConnect makes it easy with it's Custom Driver feature... it was put in there for exactly this reason.. device features grow and as more devices are created, they add features. I don't happen to have a Samsung TV connected to ST and thus I'd be blind in creating a solution.
The Custom Driver feature of Hubitat wants two components... the screen cap @Ken_Fraleigh added shows how the list of attributes are made known to HubConnect, but the 2nd piece is the "stub driver" that goes on (in this case) the Hubitat hub. HubConnect offers a tool to build a driver, but you probably will find that copying the AVR driver, changing it's name and then adding in the attributes and commands to match the ST DTH will be the fastest.
The first time is always a challenge because the menus are new, so don't be afraid to delete any attempt and try again. I'm getting good now and can usually get it right on my seconds attempt
2 Likes
Hmmm, not sure how to make this work. From the SmartThings API, it appears the capability/attribute needed is "MediaInputSource" (SmartThings Developers | Documentation). Interestingly, the AVR has that attribute already but not the capability.
I created a custom driver and tried to add capability "MediaInputSource" but that gave an error. It's not clear to me what else needs to be changed. Any idea please?
Attributes are in many ways a "Result" of something..
The something is usually a Command.
I assume that: command "setInputSource" is the something that will cause: attribute "mediaInputSource" to have a related value.
setting an ID into this and then clicking the button, 
is supposed to cause the TV to do it. Then the ST "real" driver will get it's response, put it in the attribute, and HubConnect will mirror it.
Like I said, I don't have one, so what "Id" is/does, is a mystery to me. But the task is to mimic what's on/in the ST DTH.
Can you reveal the ST DTH you are using?
Thanks. It's a native integration in ST (so not a custom DTH). "ID" I believe is for apps. However, according to the API, it should be a string (not a number). Let me try changing that in my new DTH and see if it makes any difference.
So changing the "Set Input Source" to a "STRING" entry almost worked. I can now type "HDMI1" in the field and it'd change the source on the TV. However, it doesn't still get the Current State of the "Media Input Source".
