Thanks for the tag, @GSzabados!
Welcome to the SmartThings Community, @sipiyou!
Ok, the issue is not the capability itself or the API.
In this case, who handles the capability events is the device controller, I think OCF devices (Eg. Samsung AC, Oven, etc.) still use DTH.
Also, a curious thing about OCF devices is that they work on a plugin level (app) and not through the API. This means the values showed in the API are not always complete or updated…
In this post, I shared more details about that:
Get info from API - #9 by nayelyz
For example, these are the results of a device that works with an ST Schema integration that completely interacts with the API:
In the capability event handler of this integration I set the value received in the command directly without modifying it in any way:
{
"headers": {
"schema": "st-schema",
"version": "1.0",
"interactionType": "commandRequest",
"requestId": "383FEEC4-A49E-4094-B9F4-754C9F13EB42"
},
"authentication": {...},
"devices": [
{
"externalDeviceId": "airConditionerMode",
"deviceCookie": {},
"commands": [/*This is the event received when I executed the command from the CLI*/
{
"component": "main",
"capability": "st.airConditionerMode",
"command": "setAirConditionerMode",
"arguments": [
"heat"
]
}
]
}
]
}
This means the device controller of your device is handling the capability events strangely and setting that value directly. In the app, do you see only the buttons “cool”,“dry”,“wind”,“auto”,“heat”?
This one belongs to the custom capability custom.airConditionerOptionalMode, this means it wasn’t defined by SmartThings but by the device’s manufacturer, only they know how it works and can correct its behavior.
So, in this case, if you need to correct the capability’s behavior, you need to contact Samsung’s Support team because we (SmartThings) don’t have access to their devices’ controllers to modify them either.