mediaInputSource capability has disappeared for some Samsung soundbars such as HW-Q990B, Q990C. It’s still there for other devices such as Samsung smart TVs.
Could someone please fix this ? We can’t change our soundbar sources anymore with our API implementations such as Home Assistant, the #1 opensource project on GitHub. Thanks!
Yeah, this change has broken my whole TV setup. Please fix ASAP 
@nayelyz @SmartThings @jody.albritton - perhaps tagging those people will get our TVs working again quicker
It would appear that Samsung have reworked their device integration. Users have reported issues with handling ARC/eARC in the past so perhaps they felt they needed to refactor a bit using their own custom capabilities.
I see you have investigated samsungvd.audioInputSource and found it doesn’t have any commands. Have you looked at samsungvd.soundFrom which I believe does?
Unfortunately knowing the intent of custom capabilities is hard.
Is that very recent? I also have broken eArc for a year now between a 2023 Samsung soundbar and a 2023 Samsung TV. I tested maybe 2 weeks ago and it was still broken. I will test it again but I’m almost sure Samsung broke 2 things for me now 
Not really, I just saw they were there. But we should not do that. If SmartThings exists, it’s to provide a common API over a variety of devices. If we have to start using custom commands for basic things such as select the sound source for a soundbar, then SmartThings is not serious.
All I know is that users have expressed problems with being able to handle ARC/eARC in automations. I can’t remember how recent this was.
Unfortunately there are all sorts of weird and wonderful devices types mentioned in the SmartThings API, and clearly handled by the ‘SmartThings’ app to a greater or lesser extent, the details of which are a complete mystery to SmartThings users like myself. Samsung appliances have historically used OCF protocols but there isn’t a scrap of information available as to how OCF device types are plumbed in to the SmartThings API.
The users are even less party to the politics of the technical relationship between SmartThings and their Samsung parents. We don’t even know how much involvement SmartThings have in the app that carries their name. Sometimes it seems like next to none.
Other problems:
In summary, each device has a half correct implementation, and what’s funny is that what is wrong on one device is good on the other one and what is good on the one device is wrong on the second device, all that on two 2022 mid to high end $1000+ Samsung devices on an API owned by Samsung.
I only get to see the capabilities of Samsung appliances when someone posts them somewhere.
A brief look around suggests that Samsung have been using their samsungvd capabilities for a number of years now so any recent changes are actually probably minimal, though with somewhat unfortunate consequences.
In particular they have been using the samsungvd.mediaInputSource capability which has the supportedInputSourcesMap attribute. This is clearly being used because it supports a ‘friendly name’ for each source, something that the stock mediaInputSource doesn’t. The samsungvd.mediaInputSource capability includes a command to set the source and a presentation which only has an ‘automation’ section which suggests they probably intend it to be used instead of mediaInputSource to support SmartThings automations but pull other tricks in the details view.
The samsungvd.audioInputSource capability is more of a curiosity. It doesn’t have a command to set the input source. The presentation is very unusual in that it only covers dashboard tiles in the app and consists of an array of different states that define different fixed text labels. It only makes sense if the device presentation is using an integer attribute to choose the label. It is certainly unusual but maybe that was how things were done once upon a time. It certainly doesn’t suggest any intent for it to be used in SmartThings automations.
The samsungvd.soundFrom capability has an integer mode attribute and a 'detail name`, along with a command to set both. There isn’t a presentation which suggests it isn’t designed to be used in the app in any typical SmartThings way, but there must be a reason there is a command. Is it a coincidence I’ve just mentioned an integer attribute in two consecutive paragraphs?
So how do they intend the audio input source to be selected without mediaInputSource? It certainly seems to be possible to craft execute commands to use OCF to do the job but it seems a little odd to expect that when they are using other SmartThings friendly capabilities.
Thanks for trying to help @orangebucket but to be honest I’m not even interested in finding new solutions. I’m interested in stability. Changing things like this or that, without any notice and time to adapt, is just destroying the SmartThings ecosystem, demotivating developers and making customers unhappy. At the very least we should be warned and have some versioning, we’re still at 1.0-PREVIEW…
My story : I’ve been working on a PR to add SmartThings media_player platform in Home Assistant Core for more than a year now. Because it’s in my free time, because people come & go, because HA is the #1 opensource project (on GitHub), it’s now my 3rd PR attempt. Finally 1 month after my PR was submitted, a Core maintainer has looked at it, which is awesome considering that generally PRs can be looked at only around 3 months after. Now just when I’m finalizing the PR, SmartThings breaks the media input source on our soundbars, and there’s the PAT problem. What a waste.
Hi there,
I am also going to tuck into that one 
@orangebucket
I see you have investigatedsamsungvd.audioInputSourceand found it doesn’t have any commands. Have you looked atsamsungvd.soundFromwhich I believe does?
Yeah I saw this one and also tried to try it out, but while getting a “status: ‘COMPLETED’” back nothing changes. I found out that the mode (integer) is ‘1’ for external device, and ‘27’ for spotify on my device for example. But like mentioned setting these values does not change anything.
@orangebucket
Samsung appliances have historically used OCF protocols but there isn’t a scrap of information available as to how OCF device types are plumbed in to the SmartThings API.
I also stumbled around with the OCF thingies on SmartThings side and found cool things, but then they stopped working. That there is like no information at all about this really bugs me, because I would love to just use the same protocol.
I am intrigued by the somewhat unconventional capability presentation used for samsungvd.audioInputSource which I can only make sense of if there is an integer being used to index into an array of friendly names. Do you have the vid/presentationId for a Samsung soundbar being used in SmartThings? That might show something of interest.
Being on the outside looking in (my Samsung Soundbar is about ten years old and very low end) it looks to me like Samsung have preferred samsungvd.mediaInputSource over mediaInputSource for years because it supports labels for input sources. For soundbars it looks like samsungvd.soundFrom has been used for quite a while, with samsungvd.audioInputSource being a more recent introduction which again looks to be preferred over mediaInputSource but actually only seems to be for limited display purposes as it only defines a presentation for dashboard tiles and doesn’t have any commands.
I know it is, or certainly was, possible to do an awful lot in the SmartThings API by tweaking the OCF side of things with the execute capability but that is supposedly deprecated so if they expect you to be able to twiddle the input source from the API there really ought to be another way, and if it is no longer mediaInputSource what on earth is it? Unless they don’t want you to.
Hi!
Sorry for the delay, this is all the information I have:
Samsung devices use the OCF protocol and the communication is mostly from the app to the physical device, so, you may see information in the app that isn’t present in the API. Therefore, the suggestion is not to rely on these states as they are subject to change.
Can you explain that in English? How are we supposed to change input source via the API?
Her point is that not everything that you can do via the app can be done with the API. Likely the app is not calling the API to change the input, but instead talks directly to the device via the OCF protocol.
So the SmartThings API is deprecated and needs to be replaced with OCF?
The thing is that the ‘SmartThings’ app is a amalgamation of remote control apps for Samsung appliances, fused with the primary end user interface for the SmartThings platform. End users of Samsung and/or SmartThings have very little practical information on what it gets up to, or how.
The Samsung devices use OCF protocols to communicate with the app. They also appear as OCF devices in the SmartThings API. What the communication and control flows are between the API and the OCF devices is a mystery.
What actually appears in the SmartThings API for Samsung devices seems to be largely down to Samsung themselves. What their intentions may be isn’t known. It may be that it is largely for their own purposes.
All you need to know can be found here:
https://openconnectivity.org/developer/specifications/
Make sure to download the Device Specification, read it (or just scroll through the PDF) and you’ll realize why Matter was invented.
The document Resource Type has this to offer:
Oh, and here’s some code:
Not in the mood to learn another dying protocol.
And of course there’s GitHub dumpster diving to rescue/refurbish code:
Different language, but helpful nonetheless.
There might be a potential way to use an API. Check the AWA and see if your device has a command to set the input source. If so, use a web developer tool to look at the request being sent. On my TV, there is a command setInputSource:
That AWA command generates this API call with the associated request body:
{
"commands": [
{
"arguments": [
"HDMI3"
],
"capability": "mediaInputSource",
"command": "setInputSource",
"component": "main"
}
]
}
Notice that this is NOT a standard v1 API call but rather some other call likely only for the ST app or TVs. @orangebucket might be able to tell us more about what the cupcake-api is all about.
There may also be an option to send OCF commands through an API, but I’ve not researched what that entails:
