There are all sorts of codenames floating around. For example the client app settings use a nibbler endpoint and the various platform versions (as I call them) that modify the API each have keywords (e.g. 20170916 which is used in the Core SDK is gizmo). So cupcake might perhaps refer to the AWA or to the library it uses to wrap up many different tweaks of the API. It seems to be something along those lines.
The ocf capability has been deprecated along with execute so that doesn’t seem too promising going forwards. They always seemed to fit the SmartThings model like a glass slipper on an Ugly Sister and to be a bit of a fudge until they did the job ‘properly’.
Once upon a time, I was tasked to fix an issue in some microcode written in assembly for a processor probably no one has ever heard of. There were two variables in the code named “chuck” and “larry.” Nobody at the company knew what they were, what they did, or why they were there–except years before there were two guys named Chuck and Larry that worked on firmware in the Engineering Department. We tried for weeks to figure out what these variables did–and simply chose to leave them alone, for fear of breaking something else,
Coming back to my original post, mediaInputSource has just disappeared, although there’s still the current source and the possible sources list in the API. Does SmartThings plan to put it back ?
I see two commands that look like they could be used to set the source. samsungvd. setAudioFrom.setSoundFrom and samsungvd.audioFrom.setSoundFrom. Have you looked at those?
It’s obvious the removal of mediaInputSource is either unintentional or incomplete. I believe it’s a n unintentional bug. Why would they have kept the inputSource and supportedInputSources attributes otherwise?
@nayelyz Would you be able to ask the developers about this?
I do think there are two assumptions being made here:
That Samsung ever intended mediaInputSource to be used to set the audio input source on soundbars, rather than just to read the current setting.
That Samsung intend that it is possible to set the audio input source via the SmartThings API at all.
If you don’t buy into the assumptions then removing mediaInputSource looks intentional, overdue and sensible.
I can’t know why Samsung wouldn’t want to allow the audio input source to be automated by the API, but it is hard to see it any other way. They don’t seem to even allow for it to be used in conditions, let alone actions.
80% certain it’s a side effect of something else and no decision-maker cares enough to make someone fix it, at least for now. I’ve seen it countless times.
