Bug: Retrieve Custom Capabilities Files

Hi there,

As of recently, my Home Assistant integration for Samsung Soundbars utilizing the SmartThings API has troubles of retrieving the status of custom capabilities like “/sec/networkaudio/soundmode” and others.

It seems somewhere in February / March something changed. This change is not only affecting me, but also other using my integration. Still this is also confirmed outside of my integration.

The following call:

        url = API_DEVICES + "DEVICE_ID" + "/commands"
        api_full = "{'commands':[{'component': 'main','capability': 'execute','command': 'execute', 'arguments': ['/sec/networkaudio/eq']}]}"
        resp = await session.post(url, data=api_full, headers=request_headers)

should put a new status into the “main.execute.data” status. While the response says that everything should be fine:

{'results': [{'id': 'RESULT_ID', 'status': 'COMPLETED'}]}

It is not displaying the executed status when retrieving it with:

url = API_DEVICES + "DEVICE_ID" + "/components/main/capabilities/execute/status"
request_headers = {"Authorization": "Bearer " + token}
resp = await session.get(url, headers=request_headers)

Which was working a few weeks / days ago.

Is there any way to get a statement on whether this is a bug / an official issue, or if the SmartThings API changed? Because the Changelog does not list a change that would indicate something.

Thanks a lot in advance.

1 Like

Was this something you were able to solve?

I messed about with this earlier in the year, march to be exact with the intention of building something for my air conditioner.

My execute status hasn’t updated since march this year!

@AdamLC sorry for the late response. No not at all. Nothing changed, No answer from anybody, therefore I needed disable some functionality. :sweat_smile:

No worries!

Support for the OCF features seems sketchy at best!

Hi, @AdamLC
Should this command do something in the physical device or only get information?
Have you tried a refresh command afterward to see if the data attribute is populated? Sometimes this particular capability doesn’t update live, so a refresh can bring the latest status of this attribute.

@nayelyz I can only speak for myself, but I tried everything you asked for. The commands I use probably get information from the device itself. But even after a refresh, or checking the data separately it will not update.

Okay, thank you for the confirmation. We can open an investigation about this, but as a heads-up, the investigation can take some time, and the issue might be related to a change made by the manufacturer in how it handles that command. If that turns out to be the case we won’t be able to do anything.
If you can, please provide the following:

  1. Send the command again and take note of the timestamp when you do it and share it with us including your timezone
  2. Confirm the email account registered in the forum is the same one you use for SmartThings. If not, please share it with me over DM
  3. Enable support access to your account:
  1. Go to the SmartThings Web (my.smartthings.com)
  2. Log in to your Samsung Account
  3. Select Menu (⋮) and choose Settings
  4. Toggle on Account Data Access
  5. Select the time period and confirm - In this step, please select “Until turned off”, once the team finishes, we’ll let you know so you can disable it again.
  1. Share the device’s name so I can get some info from it.

Hi @nayelyz
time is not of the essence as it is isn’t working for me since 26th of March 2024. I am not sure weather this is an issue by the manufacturer, because it worked fine prior to this date.

Some guys using my soundbar integration also took a bit of time to debug it on their side, and what they found was that on the same date (26th of March) also the AWS instance that SmartThings was pointing to had a bigger crash. I don’t know whether there is a connection, but that is pretty much the time that it stopped working.

Interestingly, like mentioned, the issue only persists in retrieving the “custom” information from the soundbar, but changing the values I try to retrieve (and fail) works fine.

I’ll send a message when I enabled support access to my account.

And lastly. Thanks a lot for listening to this issue :slight_smile:!!!

Hi @nayelyz,
I activated the access for the support for a month. If more time is needed, then I will refresh the access.

Just now I tried to fetch the data again. The following are the steps with the timestamp in seconds (Germany CET).
1727114566.0243158: Request against the /execute endpoint of my device with the following payload

"{'commands':[{'component': 'main','capability': 'execute','command': 'execute', 'arguments': ['/sec/networkaudio/advancedaudio']}]}"

Result:

{'results': [{'id': '6dbf-------------------------------aa89', 'status': 'COMPLETED'}]}

1727114566.238415: Retrieving the information with the /components/main/capabilities/execute/status endpoint.
Result:

{
    'data': {
        'value': {
            'payload': {
                'rt': ['x.com.samsung.networkaudio.eq'],
                'if': ['oic.if.rw', 'oic.if.baseline'],
                'x.com.samsung.networkaudio.supportedList': ['NONE', 'POP', 'JAZZ', 'CLASSIC', 'CUSTOM'],
                'x.com.samsung.networkaudio.EQname': 'NONE',
                'x.com.samsung.networkaudio.action': 'setEQmode',
                'x.com.samsung.networkaudio.EQband': ['0', '0', '0', '0', '0', '0', '0']
            }
        },
        'data': {'href': '/sec/networkaudio/eq'},
        'timestamp': '2024-03-26T09:15:02.869Z'
    }
}

I updated my E-Mail address in the account to match with the one the soundbar is assigned to.

Do you need anything else?

Please share the ID of the result of sending the command, this helps us find the logs of that event.
I mean the ID you removed here:

I can access your account, thank you!

‘6dbfa222-f696-43c3-8ebd-94d4c3c6aa89’

Sorry for the late reply here, I’ve been away. In my case its a Samsung Aircon unit, but I get the same with a Samsung JetBot too.

Also calling the /execute endpoint with the following payload:

{
    "commands": [
        {
            "component": "main",
            "capability": "execute",
            "command": "execute",
            "arguments": [
                "mode/vs/0"
            ]
        }
    ]
}

With the following response and ID:

{
    "results": [
        {
            "id": "f426019d-7803-4f6b-a6c8-0a19424705ea",
            "status": "COMPLETED"
        }
    ]
}

When calling /execute/status its still not updated since 2024-03-21T08:52:22.325Z

Let me know if theres anything further needed to help debug. Appreciate you looking into this @nayelyz

Hi, @AdamLC, @samuelspagl
The engineering team mentioned this is the expected behavior and it’s due to the execute capability containing OCF raw messages as a state which could lead to potential privacy issues.
So, the status of the execute capability is no longer stored in a public endpoint for you to access.

Hi @nayelyz,

Thanks for the response! This is first “real” answer and I am very thankful for that.
Despite that, I don’t really understand what privacy sensitive data is stored on my soundbar, or an air conditioning-device.

If the status of the execute capability is generally no longer stored in the public endpoint, why does the public endpoint still exist?

But the most important question for me: How does the engineering team propose to retrieve these values? Because there obviously still exists a way, as the SmartThings App is still retrieving the status of all of those values.
If there’s a different protocol, or API to use, I am happy to implement that for the sake of making my integration fully working again.

Thanks a lot in advance!

I echo @samuelspagl really. Fail to see what the privacy concerns are, just sounds like an excuse. If the status endpoint is no longer functional then it should be removed or deprecated.

If theres another way to get the states of these values then happy to integrate that instead!

The communication of OCF devices works differently, in this post I included some details:

Basically, the communication happens between the app and the device and this information is not required to go through the public API
So, that’s why the app can still see those values, I’ll ask the engineering team if there’s another option but I can’t make any promises.
Also, I’ll confirm if the attribute data won’t be used any more to request its removal from the capability.

Hi @nayelyz,
is there any news regarding the open topic?

Or would it even be possible for Samsung to publish the OCF documentation? This would also be awesome!

Thanks a lot in advance.

Hi, @samuelspagl. Sorry for the delay, the engineering team mentioned the correct method to get OCF data is that the manufacturer exposes the information through capabilities for you to get it using the public API. If this isn’t done, there’s no other option for you to get that information.
So, in that case, you should reach Samsung’s support to see if they can expose the information you used to retrieve with the command.

Each OCF integration has some differences that only the manufacturer knows and it depends on them if they want to make this information public, you should mention that to their support team as well.

Sorry we cannot help you further.

Hi @nayelyz,

thanks for the quick response!

But why is it then possible for the SmartThings App to retrieve those values.
For example: In the SmartThings App I can set the Soundmode used by the Soundbar. I can see the current selection as well as the possible ones.
This data was also previously available to me through the “execute” calls.

If the SmartThings App can still utilise this functionality, shouldn’t there be a way for us to do so? :sweat_smile:

I am just trying to wrap my head around this :slight_smile:

Samsung devices are a special integration, their communication is through the SmartThings app, this means the information doesn’t need to be saved in the API to be displayed there, and you can’t intervene in the messages between the physical device and the app to get some data.
All the data received from the physical device enriches the special UI of Samsung devices, that’s why you can see information there that is missing in the API because that needs to be explicitly exposed to be seen outside their usual workflow.

That would be only when they’re exposed to capabilities since it’s what we can interact with.

No problem, I know it can be confusing but as a summary:

  1. The communication between Samsung and SmartThings happens through some services in the app
  2. These services aren’t open to public requests to read/send some data.
  3. All the information/functionality the manufacturer wants to expose must be through capabilities