Add swing and horizontal swing to climate device

[richardpolzer]

Description

Add swing and horizontal swing support to climate device

Fixes #466

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Code quality improvements to existing code or addition of tests

Checklist

• The documentation has been adjusted accordingly
• Tests have been added that prove the fix is effective or that the feature works
• The changes are documented in the changelog (docs/changelog.md)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.92%. Comparing base (9055a27) to head (2ffc8f3).
Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1642   +/-   ##
=======================================
  Coverage   96.92%   96.92%           
=======================================
  Files         160      160           
  Lines       10688    10702   +14     
=======================================
+ Hits        10359    10373   +14     
  Misses        329      329           

Files with missing lines	Coverage Δ
xknx/devices/climate.py	100.00% <100.00%> (ø)

[farmio]

Hi 👋!
Thank you very much for your contribution!

[farmio]

Do you plan to add this to the HA KNX integration too?

The code looks perfectly fine, but I have a little concern about it in general: None of the added attributes or methods interact in any way with the rest of the Climate class.

These 2 swing attributes stand for their own. Thus, I think in HA we could just add 2 extra xknx.devices.Switch instances to KNXClimate(ClimateEntity) on demand, instead of increasing size and complexity of the xknx Climate class (and its tests).
This could be handled like ClimateMode https://github.com/home-assistant/core/blob/96e40334b179d77d669035251716179a83571fa8/homeassistant/components/knx/climate.py#L416-L428
, but in a more generalised way. (As having ClimateMode as an attribute of Climate is also just tech-dept imho).

What do you think about that?

[richardpolzer]

Yes I plan on adding it to HA too.

I understand your concern. However if we want to abstract a device with the climate class, we should include all possible functions within that class and not rely on logic within systems that use the library. At least thats my opinion on that.

[farmio]

if we want to abstract a device with the climate class, we should include all possible functions within that class and not rely on logic within systems that use the library

Currently, I think the system using the lib - HA in this case - dictates the functions it can consume. So any future extension to a HA entity model (eg. homeassistant.components.climate.ClimateEntity) would need a reflection in xknx (xknx.devices.Climate). Leaving homeassistant.components.knx.KNXClimate as an intermediary layer without much functionality - it's mostly a translation layer between HA and xknx method/property names. But still we have to touch both, xknx and the HA knx integration, to add a feature. Including tests and code maintenance in both repos.
Using multiple xknx device instances per HA Entity (one per independent feature) instead of a single xknx device per HA Entity could (maybe) eliminate the need to change xknx code to add / change features to HA entities.

Anyway - we didn't do it that way until now, so let's leave it this way... can always be broken up later if we wanted to.

Yes I plan on adding it to HA too.

Just let me know when you are ready - so I can do an xknx release when you tested your feature with the integration code.