Split AC Swing Axes

Pre-release build, cut at 5:30am rather than waiting for office hours (NO! It's Spring Bank Holiday here in the UK!) — today's heat wave forecast is the worst of the week, the AC behind my desk has been clocking plenty of overtime through this rewrite, and the swing axis split has been overdue since the v2.x Mitsubishi reports anyway.

If your AC has been struggling because the v4.0 dropdown couldn't actually park the louvers where you wanted them, this is the release for you — upgrade and enjoy the heat wave properly instead of getting up at 2am to wrestle with the Tado app. If something does go sideways, HACS rollback to v4.0.0 takes about 2 minutes.

The single Off / Vertical / Horizontal / Both swing dropdown is replaced with two independent dropdowns, one for vertical and one for horizontal, populated from your AC's actual capability set.

⚠️ Upgrade Notes

Upgrading from v4.0.0? Update through HACS and restart — no config changes. Existing service-call automations using the old unified swing_mode keep working through v4.1.x with a deprecation warning per call. The compat shim is removed in v4.2.0. Migration recipe in the CHANGELOG.

Dashboard templates and Lovelace conditions reading state_attr('climate.X', 'swing_mode') and matching 'both', 'vertical', or 'horizontal' need updating — the compat shim covers service calls, not state reads. After v4.1 the attribute holds raw values like 'on', 'off', 'up', 'auto'. Cards should check swing_mode and swing_horizontal_mode separately.

HomeKit users with AC zones — temperature and HVAC mode still update locally via HomeKit (typically within 2 seconds). Swing changes still go through Tado's cloud, so picking a swing position uses cloud quota and confirms on the next cloud poll (5–30 minutes). Same as v4.0 — not a regression. A follow-up to wire HomeKit's binary SwingMode characteristic into the new vertical-axis dropdown for ON/OFF AC units is being scoped separately.

What's New

• Split AC swing into vertical and horizontal axes (#270 - @Ralf84) — AC zones expose a Swing (vertical) and a Swing (horizontal) dropdown, each populated from the cloud-reported capability set for your specific unit. Pick a fixed louver position to stop oscillation on that axis — useful in bedrooms or children's rooms where a constantly moving louver is disruptive.
• Fine-grained louver positions for capable AC units — Units that report values like Up, Mid (down), Left, Mid (right) now expose those values directly in the dropdowns. Translations land in German, Spanish, French, Italian, Dutch, and Portuguese alongside English.

Bug Fixes

• Swing changes no longer silently drop the off-axis on OFF-less units (#270 - @Ralf84) — Picking "Vertical" on a Mitsubishi or Fujitsu unit (which doesn't report OFF as a swing value) used to send only verticalSwing=ON and omit horizontalSwing from the payload, leaving the bridge to keep whatever horizontal state it last had. Each axis now writes its own value independently and the silent-drop fallback is gone.
• Picking "On" from a swing dropdown no longer silently moves the off-axis — On was incorrectly being translated as a legacy v4.0 unified value, which set the opposite axis to Off and logged a deprecation warning the user hadn't earned. On is now treated as a v4.1 raw axis value and only the axis you picked moves.

Improvements

• One log line per AC write failure, not two — Temperature, HVAC mode, fan mode, and swing writes used to log the specific failure reason (timeout, exception, or "rejected by Tado") and then a generic "write failed" warning right after. The generic line now fires only when no specific reason was logged, so a timeout produces a single warning rather than two.

Migration Recipe

# Before (v4.0)
- service: climate.set_swing_mode
  data:
    entity_id: climate.tado_ce_living_room
    swing_mode: both

# After (v4.1+)
- service: climate.set_swing_mode
  data:
    entity_id: climate.tado_ce_living_room
    swing_mode: on        # or 'auto', 'up', 'mid', etc. — your unit's capability
- service: climate.set_swing_horizontal_mode
  data:
    entity_id: climate.tado_ce_living_room
    swing_horizontal_mode: on

For Jinja templates:

{# Before #}
{% if state_attr('climate.tado_ce_living_room', 'swing_mode') == 'both' %}

{# After #}
{% set v = state_attr('climate.tado_ce_living_room', 'swing_mode') %}
{% set h = state_attr('climate.tado_ce_living_room', 'swing_horizontal_mode') %}
{% if v not in ['off', None] and h not in ['off', None] %}

How to Install

1. In HACS, open the Tado CE integration
2. Overflow menu (⋮) → Redownload → tick "Need a different version?"
3. Select v4.1.0-beta.1 and download
4. Restart HA

Beta Testing

If you have an AC unit with fine-grained louver positions (Mitsubishi, Fujitsu, or anything reporting more than ON / OFF for swing), the most useful smoke test is:

1. Open the climate card for an AC zone
2. Confirm both Swing (vertical) and Swing (horizontal) dropdowns appear with the position values your unit supports
3. Pick a fixed position (e.g. Up on the vertical axis) and check that:
   • The Tado app reflects the change within a few seconds
   • The louver actually parks at that position rather than continuing to sweep
4. Set both axes to Off and confirm both dropdowns hold

If the dropdowns show a raw value like mid_left_down rather than a translated label, that's a known gap — drop a debug log line on the issue and the translation gets added in the next patch.

Contributors

Thanks to @Ralf84 for the debug log that exposed how thin the unified dropdown had become — seven distinct vertical positions and six horizontal ones reported by the cloud, all collapsed into four values in the UI. Three years of swing-related issues (#128, #142, #270) trace to the same root cause; the split-axis layout closes them all.

---

Thanks to everyone who supported the project through Buy Me a Coffee — it genuinely helps.

Full changelog: v4.0.0...v4.1.0-beta.1