Hello community,
I’ve been lurking the forums now for a few days, and it seems that the old SmartThings way to switch Input Source on a soundbar (mine is quite recent, HW-Q950T) is not available anymore.
So I’ve been trying to explore the local network OCF way, like suggested in some post.
I’ve indeed tried the “setSoundFrom” command but it doesn’t do anything.
I learned about the COAP protocol. But the input source switch does work when you’re not in the same wifi network (over 5g for example), which means there is a http command for this. I just can’t find it.
Any dev managed to succeed in such a basic need for any home automation ?
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.
About the COAP command, only the manufacturer would know which one you can use and it depends on them to make this information available.
hi @nayelyz , thank you for your answer. Ok then, I guess I’lll have to get off the soundbar network and fully inspect the smartthings app network packets on my phone.
Switching input source is such a base feature though, Samsung could at least expose it to IFTTT or Home Assistant.
edit : can we simply create a request for SmartThings team to expose input source to Home Assistants ? Right now they only have access to turn on / off.
edit 2 : trying to edit samsungvd.audioInputSource value with api.smartthings.com/devices/{{deviceId}}/events (thanks to this post), but I get a 403 forbidden, unlike all other command pathes. Seems like only ST app can call this command.
Creating device events is the mechanism device drivers / handlers / integrations use to communicate the status of a device to the SmartThings platform, which results in the capability attributes being set, entries being added to the history, events being received by automations and so on. That particular API call is the method used when the device integration is a SmartApp and so only the particular installed SmartApp that manages the device can issue it.
In any case all creating an event to change the inputSource attribute would do is misrepresent the status of your soundbar in SmartThings. It isn’t going to do anything to the soundbar. It would be the tail wagging the dog.
Unfortunately the samsungvd.audioInputSource capability doesn’t define any commands that could be used to actuate anything on the device.
In a previous post you suggested:
I know very little about the CoAP protocol, but I know it can work over the internet. Whether that is what it is doing is another matter. In any case the ocf and execute capabilities are actually deprecated in SmartThings so expecting those to be used moving forward seems inappropriate.
What have Samsung had to say? And I mean Samsung, not SmartThings. I appreciate it seems ridiculous to separate the two given the confusion caused by the ‘SmartThings’ app, but sometimes you still need to.
Indeed, have Samsung ever expressed an intent for automation and control of the soundbar to be available to third parties via the SmartThings API, rather than it being incidental to the integration into the SmartThings app?
Thank you for your very well put reply, orangebucket. A lot to learn in here.
As a reply, I didn’t try to contact Samsung directly, as it will be the usual automated support redirecting me to the SmartThings app and SmartThings API for any programmation.
I know for a fact that a ton of complaints can be found on the net concerning the missing input source switch exposure to assistants.
Worse : only open source assistants made by passionate people like Home Assistant have implemented the automation, but it uses the now missing setInputSource command. So they’re all broken aswell now.
There seems right now to be absolutely no way to program a simple input source switch.
The integration’s owner, Samsung in this case, must do that. They must expose that information/feature explicitly. For example, include a capability that lets you send this kind of command and that works through API commands as well as in the app.