Inconsistency in supportedAcModes: "heat" missing from list despite active status

[dfandrew (Andrea De Francesco)]

The device reports airConditionerMode: heat when controlled via IR remote, but the supportedAcModes list incorrectly excludes ‘heat’. This inconsistency prevents any API-based control (SmartThings App/Home Assistant) from switching the device to Heat mode, as the command is rejected by the cloud validation logic.

This is a part of the status api response
“airConditionerMode”: {
“availableAcModes”: {
“value”: null
},
“supportedAcModes”: {
“value”: [
“cool”,
“dry”,
“wind”,
“auto”
],
“timestamp”: “2026-02-06T15:52:33.815Z”
},
“airConditionerMode”: {
“value”: “heat”,
“timestamp”: “2026-02-06T16:50:30.522Z”
}
}

[nayelyz (SmartThings Developer Support)]

Hi, @dfandrew
Are you trying to control an OCF-type device?
This reminds me to this other case where other developers were trying to control one of these device types through the API.
The Supported Modes doesn’t prevent the usage of certain values through the API, I made a test and the command gets accepted, meaning it doesn’t have a syntax issue. But, here I provided more info on why this happens (for OCF devices specifically):

How to put my air conditioner in heating mode with the api?

Hi, @Philippe_Leborgne and @Nuno_Conceicao The appliances are a different type of device called OCF. They use a different communication protocol and they work more on the app level than the API level. That’s why you can see something different on the app than the API Also, if a “handler” for certain commands or parameter values isn’t inclided in the device integration (code), they won’t work even if the API accepts it (this is true for any integration type). This is because the API only checks that the syntax is correct and the command is sent to the device, but it isn’t processed by the integration that controls it.