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".
I've done some research and determined that Hubitat does not support the Media Input Source capability, and that ST treats it as an ENUM (not String, although the value is a string in the end.)
ENUM means that there's a specific list of values. String would imply any value is OK. Oddly, "HDMI1" is not one of the values! "HDMI" is, "HDMI2" is but not "HDMI1" 
In other words, your test SHOULDN'T have worked. The DTH isn't matching their own spec. Not shocking, I know... I'm just pointing it out.
The HubConnect AVR driver matches the Hubitat Denon AVR built in, which uses an input number value. Seems more flexible, since it also includes the means to label the values. Once you know that ID:3 is HDMI1, then you label it. In other words, it appears more future-proof and vendor agnostic.
I think this is a great advertising for HubConnect's expandability. Once you get it working, let the Community know and find out if there's a bunch of others that always wished there was a driver.
Hubitat's Denon AVR driver documents the Number value for Id:
And via my Get Attribute App, I can see that the two drivers overlap implementation:
Hubitat's Denon AVR:
HubConnect AVR:
1 Like
Thanks for looking into this!
Yup, I noticed that HE doesn't have that capability (kept erroring out). Tbh, I got stumped after that (not as familiar with writing drivers). I'm guessing I can't rely on HubConnect's drivers and would need to write my own driver that accounts for the lack of the capability. Any idea if there's a HubConnect driver for a device without a HE capability that I can reference?
HDMI1 is actually one of the listed enums.
Capability is just a "macro" or container for predetermined Attributes and Commands. Therefore the existing HubConnect AVR driver has a Command ("setInputSource") and an Attribute ("mediaInputSource") that is a functional equivalent to the Capability of "mediaInputSource" with one simple difference... Selectors. It's not a problem, because there's no such thing.
Apparently I'm using a different/older reference:
My vintage of ST Docs show that the name of the Attribute ST uses is "inputSource"
Thus you can take the HubConnect AVR driver as your inspiration, change it to be "HubConnect STV" (Samsung TV or anything, so long as it's unique" and alter that Set Input Source as you like. Then change the name of the Attribute to match what ST uses, and you should be good to go.
1 Like
Here's the latest:
Ah, I had tried using inputSource previously and it wasn't working. I just realized that in ST, I needed to select the device using the new driver I had created!!! That's why everything I had done hadn't worked. Changed the driver type in the HubConnect Smartapp in ST and voila, InputSource appeared. Feeling silly but glad I got it figured out!
Thanks for all your help on this!
I'm getting this error message in the log for one of my remote hub devices on my "server" hub. Anyone know what this means and where I hunt for problems? I went to add a couple devices to an existing HC connection; it error-ed out with "Unexpected Error" and this log message:
2020-11-12 06:45:01.899 pm errorjava.lang.NullPointerException: Cannot get property 'title' on null object on line 2260 (dynamicDevicePage)
I have a samsung dryer that is connected in ST. Is there a way to connect this to HE via hubconnect? I'm after the notification when the dryer is done. Been trawling through the post and documentation but cannot find the answer. The dryer doesn't seem to be appearing in the list of devices that I can share in ST.
