Samsung room A/C: is the vertical louver ANGLE addressable? fanOscillationMode exposes 4 of 15 values, and OCF /airflow/vs/0 only mirrors the same four

Devices & Integrations
1

I have two Samsung wall-mounted room A/C units (AR50F09C1AHNEU, 2025 model) on SmartThings. I want to stop the cold airflow from blowing down onto people sitting in the room. I have read the existing threads and I think I am asking something they did not answer, apologies in advance if I missed it.

The problem

With fanOscillationMode set to horizontal, only the left-right blades sweep, which is what I want. But the vertical louver then receives no command at all and simply stays wherever the last vertical oscillation left it, very often pointing straight down, exactly the direction I was trying to avoid.

Verified on the unit itself:

  • fixed does not park the louver at a defined rest position. It freezes it wherever it currently is.
  • The angle is stored in the unit and survives a power cycle: switch off and on, and it comes back to the same angle.
  • So the louver angle behaves as an internal state that nothing addresses. There is no “point it up” command anywhere I can find.

What my units report

Device diagnostics, identifiers removed:

Model: AR50F09C1AHNEU  (binaryId TP1X_DA-AC-RAC-01001_0000, vendorId DA-AC-RAC-01001)
Wi-Fi module firmware: ARA-KR-TP1-25-ARXX00_11260401
Platform: Tizen Lite 4.0 - One UI 7.0 Air conditioner

fanOscillationMode:
  supportedFanOscillationModes = ["fixed", "vertical", "horizontal", "all"]
  availableFanOscillationModes = null
  fanOscillationMode           = "horizontal"

custom.airConditionerOptionalMode:
  supportedAcOptionalMode = ["off", "sleep", "quiet", "speed"]

samsungce.softwareUpdate:
  newVersionAvailable = false

I went through all 54 capabilities on the main component looking for anything blade / vane / louver / direction related. There is nothing. airFlowDirection is not present either, not even in disabledCapabilities. custom.airConditionerOptionalMode offers only off / sleep / quiet / speed, so windFree and motionIndirect are not available on this model.

What I already found here, and why it does not solve it

In airflowDirection status dead the workaround is to bypass the deprecated capability and drive the OCF resource directly:

{
  "component": "main", "capability": "execute", "command": "execute",
  "arguments": ["airflow/vs/0", {"x.com.samsung.da.direction": "Left_And_Right"}]
}

My units do expose the execute capability, so this route is open to me. But the accepted values, All / Up_And_Low / Left_And_Right / Fix — are the same four states as fanOscillationMode under different names. It changes which blades sweep, not where a blade points. Same dead end, one layer down.

What caught my attention in that thread is the /oic/res listing: alongside /airflow/vs/0 (x.com.samsung.da.wind, the Samsung vendor extension) there is /airflow/0 of type oic.r.airflow, which is a standard OCF resource type with a direction property. Nobody in that thread seems to have read those resources to see what properties they actually carry.

Questions

  1. Has anyone read /airflow/0 or /airflow/vs/0 on a Samsung room A/C and found a property that sets the louver angle, a step, a percentage, a numbered position, rather than an oscillation pattern? If so, what does the payload look like?
  2. Does any Samsung room A/C report indirect / direct / fixedCenter / fixedLeft / fixedRight in supportedFanOscillationModes? If yours does, which model and firmware? I want to know whether this is model-gated or simply unimplemented everywhere.
  3. If the angle genuinely is not exposed at any layer, what is the right channel for a firmware feature request that reaches people who can act on it? Consumer support has not looked promising.

The standard fanOscillationMode capability defines fifteen values, off, individual, fixed, vertical, horizontal, all, indirect, direct, fixedCenter, fixedLeft, fixedRight, far, wide, mid, spot, swing, and my units declare four. indirect alone would solve this, and it would not require inventing anything new. The hardware positions the louver accurately during oscillation, so the mechanism exists; what is missing is the command path.

Note for Home Assistant users reading this

Even if a unit did report the extra values, HA would not show them. Its SmartThings integration maps swing through a four-entry dictionary:

SWING_TO_FAN_OSCILLATION = {
    SWING_BOTH: "all",  SWING_HORIZONTAL: "horizontal",
    SWING_VERTICAL: "vertical",  SWING_OFF: "fixed",
}

Anything else in supportedFanOscillationModes is silently dropped when the swing list is built, so the HA UI cannot tell you whether your device supports more. Read the raw device diagnostics instead.

Thanks in advance to anyone who can confirm or correct any of this.