Add support for horizontal vane swing operation in climate integrations

[dgwynne]

I have a Mitsubishi Electric air conditioner that has both vertical and horizontal vanes that can be controlled independently. The climate entity already supports handling vertical swing operation. I'm proposing that the existing swing support is copied to allow handling for horizontal swing operation.

There's a pull request that implements this proposal in home-assistant/core#49541. That pull requests also provides an example of using it with the MQTT climate integration to talk to a Mitsubishi Electric air conditioner that's plugged into an esp8266 running Tasmota with the MiElHVAC driver.

Aside from the specific hardware I've implemented support for, this functionality would be useful for the control of several other brands of airconditioner. Going by the IRremoteESP8266 code, at least the aircons from the following vendors support independent setting of horizontal vane operation:

• Daikin
• Electra
• Fujitsu
• Hitachi
• Kelvinator
• Mitsubishi Electric
• Mitsubishi Heavy Industries
• NeoClima
• Panasonic
• TCL
• Voltas

Integrations for this hardware, such as the daikin, esphome, intesishome, knx, melcloud, modbus, etc, could be updated to use the functionality in the base entity and UI controls, and provide integration and automation with everything else that home-assistant provides.

[dgwynne]

I would also like to say that from a code complexity point of view, it's very low risk as it is literally a copy of the existing swing code. If you trust the swing code, then you can trust the horizontal swing code.

[blakadder]

Multiple fans and heaters also have horizontal swing/no swing modes

[khcnz]

Another integration that could make use of this change scottyphillips/echonetlite_homeassistant#17

I wonder if it would be better to implement a SwingH and SwingV mode and leave the existing generic swing mode alone to be a bit more explicit around a general swing mode v horizontal and vertical swing. It would be up to the platform which of the three to implement.

[gjohansson-ST]

Adding on Sensibo as an integration that could benefit from having two swing states e.g. vertical and horizontal independently. As of now the horizontal swing is implemented as a select entity which is not so nice.
The "problem" here is that the current swing supports both vertical and horizontal and an integration can implement it as such.

Proposal

Add a SwingH property as suggested in the PR mentioned in the original post.
That is probably the easiest way to deal with this would also not have any effect on current integrations using the existing Swing property for both vertical and horizontal.

[Aesculapius]

This is also possible with Mitshubitsi SRK airco's in combination with the Absalum-Muc ESP integration in HomeAssistant, see absalom-muc/MHI-AC-Ctrl#77

If it's such a non-breaking easy addition, I'm wondering why the original pull-request has been closed? Or has this been implemented nonetheless? home-assistant/core#49541

[gjohansson-ST]

It went stale and then the bot closed it. Those PR's won't be handled until this discussion has been finalized and approved anyhow.
We can always make a new PR once an approval has been made.

[Aesculapius]

Okay, great. So what is then needed to finalize the discussion here? Not trying to be blunt or disrespecting rules of the road, but trying to understand what would be needed to get this feature to be considered.

[gjohansson-ST]

From what I can understand there are two core integrations that could make use of this (MQTT and Sensibo).
That's a bit think to add this functionality so we should check if more integrations could make use of it.

[jdndm]

Some other integrations that could make use of this are;

• jeatheak/Mitsubishi-WF-RAC-Integration
• Gree
• sockless-coding/panasonic_cc
• Tasmota integration could also benefit as swingh and swingv are supported by Tasmota IRHVAC

[jwillemsen]

This would be very useful for the Daikin units, it looks the newer units get more and more swing modes and combining vertical/horizontal in one attribute makes it impossible to provide all freedom to the user.

[codyc1515]

Panasonic AC's also operate similarly.

[Bascht74]

my Mitsubishi devices have both vertical and horizontal vanes as well. Supporting those is very appreciated.
(and adding it to the climate integration of ESPHome).
Right now I am using a select entity, but that is pain in the butt...

[erkr]

My LG units have this as well

[janmashat]

The Gree integration would also benefit: home-assistant/core#88368

[erkr]

What blocks approval to extend climate devices with support for controlling horizontal and vertical swing independently?
Once approved, the implementation van be discussed further in a PR?!

[parautenbach]

My climate entities both have the individual swing options available.

Shouldn't this proposal thus be closed as implemented?

[parautenbach]

With that in a single list, it seems like the integration is either providing the features incorrectly, or it gets it incorrectly from the device itself. Perhaps the device's protocol doesn't support it. My point is that in the Midea integration (custom) that I use, it all works as expected, so HA's support seems complete – on the backend. There could be bugs in specific integrations, of course, but those should be logged as bugs then.

Yes, I don't have the swing positions available on the climate card. This would be a frontend issue though, which this dicussion wasn't aimed at.

[erkr]

I guess not, as far I can see, your climate cards also offers one list, where a combined setting 'both' for both H and V is offered:

The point is that we should have have a H and a V control for devices that offer these settings independently. The combinations in a one list explode (#H x #V). My combined list would have 72 combinations:

swing_modes:
  - VerticalOff
  - VerticalTop
  - VerticalMiddleTop1
  - VerticalMiddleTop2
  - VerticalMiddleBottom2
  - VerticalMiddleBottom1
  - VerticalBottom
  - VerticalSwing
  - HorizontalOff
  - HorizontalLeft
  - HorizontalMiddleLeft
  - HorizontalCenter
  - HorizontalMiddleRight
  - HorizontalRight
  - HorizontalLeftHalf
  - HorizontalRightHalf
  - HorizontalSwing

The LG integration seems to have chosen to allow the user to apply the swing modes sequential, so twice for horizontal and vertical combinations.

Before this can be fixed in the frond end (I agree a separate issue), the climate entity class should be extended to support two independent swing modes

[janmashat]

With that in a single list, it seems like the integration is either providing the features incorrectly, or it gets it incorrectly from the device itself.

The integration has no option but to cram everything into a single list if it wants to utilize the core climate entity, since only a single swing_mode property is provided: https://developers.home-assistant.io/docs/core/entity/climate/#swing-modes

This would be a frontend issue though, which this dicussion wasn't aimed at.

That's precisely what this discussion is aimed at - providing an additional dimension of swing control to the core climate entity.

[khcnz]

It's not yet just a 'front end issue' as the 'backend' doesn't yet let us support it, once the backend supports it might then be a front-end issue :)

As I mentioned early in the history of this ticket, I still think the best thing to do from a backwards compatibility point (and not all climate devices will have support for detailed types of V and H swing modes) would be to add a new SwingV and SwingH mode and leave the existing Swing mode alone.

Integrations should either therefore implement either the existing Swing or new SwingV and SwingH and an integration can indicate which of these it supports (which is already an established pattern like SUPPORT_SWING_MODE provides to indicate what capabilities the device has).

It might also at that time make some sense to give these H and V modes some semantic meaning rather than just being a list of strings which doesn't let you build nice looking UIs that have knowledge about these airflow patterns. I would wager most heatpumps would support a common base set of swing patterns, however it might be hard to make that have semantic meaning while still being extensible.

My list would be:

Vertical:

• VerticalAuto
• VerticalSwing
• VerticalMiddleTop1
• VerticalMiddleTop2
• VerticalMiddle
• VerticalMiddleBottom2
• VerticalMiddleBottom1

Horizontal:

• HorizontalAuto
• HorizontalSwing
• HorizontalLeft
• HorizontalMiddleLeft
• HorizontalCenter
• HorizontalMiddleRight
• HorizontalRight
• HorizontalLeftAndRightOnly

[janmashat]

My list would be:

Some of those seem vendor-specific and might be difficult for an enduser/developer to interpret - especially:

• VerticalMiddleTop1
• VerticalMiddleTop2
• VerticalMiddleBottom2
• VerticalMiddleBottom1
• HorizontalLeftAndRightOnly

My vendor (Gree) has the following list of options, and all of them are self-explanatory IMO:

Horizontal

• Default
• FullSwing
• Left
• LeftCenter
• Center
• RightCenter
• Right

Vertical

• Default
• FullSwing
• FixedUpper
• FixedUpperMiddle
• FixedMiddle
• FixedLowerMiddle
• FixedLower
• SwingUpper
• SwingUpperMiddle
• SwingMiddle
• SwingLowerMiddle
• SwingLower

Source: https://github.com/cmroche/greeclimate/blob/master/greeclimate/device.py#L67-L91

[jdndm]

+1 for this vertical and horizontal swing to be supported. I have MHI AC that supports selecting both swing modes. I am using the mqtt platform, but I can others would benefit also. Found this one that hasn't been mentioned beofre - jeatheak/Mitsubishi-WF-RAC-Integration#101

[jtauscher]

waiting for 3 years now to implement horizontal swing modes. Tasmota supports it for years now like this:

cmnd/AC/HVACSetSwingH RR

why not implement it like this:

swing_mode_command_topic: "cmnd/AC/HVACSetSwingH"
swing_mode_state_topic: "tele/AC/HVACSETTINGS"
swing_mode_state_template: "{{ value_json.SwingH }}"
swing_modes:
  - "swing"
  - "LL"
  - "L"
  - "C"
  - "R"
  - "RR"

[MoltenTesseract]

Adding my +1 to this. It's the only reason I now have to go to the Sensibo and LG apps.

[briancmpbll]

Also jumping in to ask for this, but I'll also add some input. I see several comments here about implementations that would work for individual models of climate devices, but we need to keep in mind that HA should try its best to work with any device as well as future devices. We would probably need a model where individual components can report the swing/vane positions they support instead of actual enum values that try to support everything. I think this is how integrations that have added support for this are working.

[cociweb]

All the Tasmota devices via IR+MQTT could profit from this - https://github.com/hristo-atanasov/Tasmota-IRHVAC
Currently the workaround is only hack over hack because of this long lasting functionality.

So if the PR is ready, what is missing here? Or we just talking about talking?

[zejulio]

+1 for this.
Wonder why is not already implemented. Would be awesome!

[zejulio]

While we lay down waiting for it to be part of this great component, what alternative way that I can add a extra dropdown to accomplish this?
I think HA can do that, only this component dont have any visual way to to it.
Thanks for any suggestion.

[erkr]

While we lay down waiting for it to be part of this great component, what alternative way that I can add a extra dropdown to accomplish this?

In my case the horizontal and vertical settings in swing mode list are independent. So selecting a vertical setting doesn't change the latest selection for horizontal. And visaversa.

So I made two template select entities, one with the horizontal options, the other the vertical options. When I change the select, the select_option calls a service to change the setting.
Example horizontal select options:

  - name: "Keuken Airco Horizontal Swing Mode"
    unique_id: keuken_airco_horizontal_swing_mode
    state: "{{ state_attr('climate.keuken_airco','swing_mode_horizontal') or 'HorizontalOff' }}"
    options: "{{ (state_attr('climate.keuken_airco','swing_modes') or []) | select('match','Horizontal') | list }}"
    select_option:
      - service: climate.set_swing_mode
        data:
          swing_mode:  "{{ option }}"
        target:
          entity_id: climate.keuken_airco
    icon: mdi:swap-horizontal-variant

I use these two selects instead of the combined swing mode:

I think HA can do that, only this component dont have any visual way to to it.

That really depends on the HVAC integration. Selection of horizontal vs vertical settings must be Independent. Some of them offer 'combined' settings. For those my approach probably fails.

[MarcusFrance]

• 1 for adding this - I'm just trying to set up some scenes for my Mitsubishi A/C units and of course the standard HA Climate card is displayed with no indication of the Horizontal Vane position which means I can't check that my scene has all the parameters I want to set.

[loryanstrant]

Also weighing in on this one as the climate card doesn't show the horizontal swing options.
I'm using the Echonet integration with a Mistsubishi AC unit, so every time I want to change it I have to go into the device settings.

[orzechszek]

Also 1 for adding this - I still need to use another integrations 😞

[emontnemery]

The design implemented in the PR linked to the architecture discussion is accepted, with the difference that we shouldn't shorten "horizontal" to "h" in the Python implementation.

We should make sure to make it clear in developer documentation that devices which don't allow independent control of vertical and horizontal swing should not implement the horizontal swing mode property and service, they should instead list the possible permutations in the swing_modes property.

[janmashat]

If arbitrary swing states (and icons) can be assigned to the existing swing_modes and we just want to add another dimension, then maybe it would be more sensible to call the addition swing_add_modes.

[gjohansson-ST]

As it was raised by @emontnemery here is the overview of the options we can do. I will refer to the respective modes property for simplification. Each modes property needs to have a mode property and an attached action for any of the cases (incl. feature).

For all these possible properties the built-in options are going to be limited and integrations needs to extend it with their own custom options (as the options are very integration/vendor specific, I don't think we gain anything by expanding the built-in options).

For some scenarios moving options from swing_modes (applies to both options), there would be a breaking change and therefore integrations need to consider a deprecation period for moving options (ClimateEntity can't handle that).

Option 1 (current decided solution)

Pro: Simple implementation and we continue to use the existing swing_modes for mixed or vertical modes.
Con: Can it be confusing for users to have a property for horizontal modes specifically (also named as such) but for vertical it's not in the name?

swing_modes

• If the integration does not have independent control of vertical and horizontal modes this property would have all the possible states regardless vertical or horizontal
• If the integration does have independent control, this property would only contain the vertical modes

swing_horizontal_modes

• Integrations should only implement horizontal modes into this property.
• In the case there is no independent control of horizontal modes vs. vertical this property should not be used (see swing_modes above)

Option 2

Use swing_modes when independent control does not exist, use swing_vertical_modes and/or swing_horizontal_modes when independent control exist. So swing_modes can't co-exist with any of the other two (to check and raise error if it does).

Pro: Separation of mixed modes and independent control of vertical vs. horizontal makes it clearer what is what.
Con: More to consider in implementation. Trickier to use for templating, grouping and action calls referring to several entities (split of action calls).

swing_modes

• If the integration does not have independent control of vertical and horizontal modes this property would have all the possible states regardless vertical or horizontal
• If the integration does have independent control of vertical and horizontal modes, this property should not be used.

swing_vertical_modes

• Integrations should only implement vertical modes into this property.
• Implement vertical swing modes when independent control exist

swing_horizontal_modes

• Integrations should only implement horizontal modes into this property.
• Implement horizontal swing modes when independent control exist

[janmashat]

I would vote for the quickest/simplest solution - so Option 1...and possibly think about refactoring into Option 2 down the road.
I assume the breaking change / deprecation period would not be a blocker for the initial rollout of swing_horizontal_modes?

[MarcusFrance]

I agree that Option 1 sounds best for getting this done straight away. Am I right in assuming that providing swing_horizontal_modes as you describe above in option 1 doesn't detail the specific horizontal swing modes allowed in HA and that these are specified in the relevant integration ie I use the MelCloud HA Integration which provides for: vane_horizontal_positions: auto, 1_left, 2, 3, 4, 5_right, split, swing, so that once the new feature is implemented in the HA Climate function/Card that these will be what I see whereas someone using an Integration for another manufacturer will see the swing_horizontal_modes applicable to their A/C system?

[gjohansson-ST]

Yes, the integrations themselves need to add options to the respective list so the user sees the available options (which obviously will be different for different integrations). That's independent from whichever option we go for and already true for the existing swing mode but also for presets, fan modes etc.

[jwillemsen]

Great news @emontnemery , will any resulting changes to HA core linked to this discussion? At some point I have to rework the daikin_onecta integration to use this new HA core feature.

[gjohansson-ST]

There will be an implementation PR linked to this discussion. I intended to reopen the initial PR but the branch has been deleted so wasn't possible anymore. You can watch that PR then when it's linked here.

[dgwynne]

sorry about that. i gave up on this and my branch didn't survive a cleanup. i'll see if i have a backup of the system i was running it on, but i'm not hopefully.

fwiw, the code was almost literally a copy and past of the existing swing code though, so my branch going away is not a huge loss.

[emontnemery]

The commits on your branch are not lost, it's just that it's not possible to reopen your PR.

[gjohansson-ST]

I will open a new PR tonight and update this discussion with the new PR and link the relevant PR's to the core PR.
Making the core PR doesn't take many minutes as it's a pretty straight forward new functionality we're adding 👍

[orzechszek]

Hi,
Quite good described horizontal and vertical swing states for Gree: https://github.com/arthurkrupa/gree-hvac-mqtt-bridge

[janmashat]

Although that repo contains invaluable info regarding the wifi config (for me at least), it hasn't received an update in over 3 years - so I would rather recommend the values in the python implementation as I mentioned earlier.

[AndLindemann]

Has this now been implemented? I wasn't able to find anything in the docs and more recent pull requests? Is there a current PR for this?

[jwillemsen]

See home-assistant/core#125578 and home-assistant/frontend#22043

[jwillemsen]

The core extensions have been implemented and will be part of the upcoming 2024.12 release, any integration that wants to use this needs to be updated, I have updated the daikin_onecta integration, pre release with the new feature is available for testing with 2024.12.0b0 and newer, see https://github.com/jwillemsen/daikin_onecta/releases/tag/v4.2.0