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.
I built an ESPHome IR blaster and I can do a lot of things with it, including selecting the source. I found some codes on the flipper IRDB such as “select D_in source” and I just chain a “toggle source” IR command the required times in order to select the source I want. I dont’ have the time right now to finalize it, but the plan is to combine SmartThings to get the actual states of the soundbar, and IR blaster to send the missing commands in SmartThings, or even all commands. With universal media player, I can create a fully working media player entity and hide the SmartThings media player as well as the ESPHome controller.
I’m now first waiting to see what comes out of the exchanges between Nabu Casa and SmartThings team, mainly around the PAT problem, but ultimately I even have a plan to get the states locally without SmartThings. Even more radical than IR : an ESP32-CAM would take pictures of the soundbar LED display and then with OCR I would get the states of the soundbar. Basically, make SmartThings smart again, by totally getting around it
Any news on this ? Has someone tried reaching the Smartthings support team about this obvious regression ?
Issue reproduced (no setInputSource on the ST dashboard) today on a 990B that had the capability before.
Okay, after a few hours of analysing the logs/trafics of the app, I finally managed to use the execute command on the API to change the input on my 990B
Here are the payloads of the HTTP requests (as sended by the SmartThings. Add a little smartness to your things. )
So, for the “execute” command, the magic parameters are (as sended by the app)…
