Feature/linear compensation (proportional controller mode)

[folfy]

Motivation:

Some eTRVs, like HomematicIP thermostats for example, already have a rather aggressive internal compensation for the thermostat temperature (rising with the radiator on), and using any of the modes by BT causes overcompensation, leading to rather strong oscillation and overheating, even with overheat protection enabled. "No compensation" works, but also leads to not really properly reaching our target temperature often (which would be the whole point of a thermostat controller like BT).

Therefore, a new "linear compensation" algorithm is introduced, which does not consider the actual TRV temperature, but simply adds a proportional (as part of a regular PID controller) offset, based on (t_setpoint - t_extsensor) * f_gain (factor is adjustable), with the applied offset being clamped (also supposed to be adujstable). This is a tradeoff, resulting in at least very small residual deltas (<0.2-0.3°C at worst for me), while minimizing risk for overcompensation (it's not 0, as this calibration can still lead to overheating in a very small room, or if the temperature sensor is slow/lagging in updating us).

RFC - Let me know if you're generally up for adding this feature to BT. This is currently a WIP/draft, because my branch is not up-to-date, PR#1502 is duplicated in this branch/PR, translations are missing, just the very basic function was added so far.

Changes:

• Added LINEAR_CALIBRATION mode accross the board (calibration.py, definitions, config flow, description...)
• Changed _calibration_mode checks in calibration.py to if - elif chain

DRAFT PR - ToDo's

Additional features to be approved

• Add variable for gain (currently fixed to 5 for the new mode, meaning 0.5°C offset applied per 0.1°C difference)
• Add variable for clamping (currently fixed to 2 for the new mode, i.e. +/-2°C) - Feature Request: Add an option that limits calibrating offset #1426

-> These two could be applied generally for all modes, with a default of 1 (unity gain) and 0 / empty (no clamping)? This should be helping quite some ppl, being able to dial in and tune the aggressiveness.

• Rounding - Fix rounding to be rounding nearest instead of fixed down - Does not round correctly #1475

Other

• Merge upstream changes
• drop b27f565 from the PR (obosolete once fixed typos HomaticIP -> HomematicIP #1502 merged into main)
• Add new description to all translations
• Add examples graphs of control behaviour to this PR (incl. before/after)

Related issue:

• ToDo no. 2 would fix Feature Request: Add an option that limits calibrating offset #1426
  ToDo no. 3 would fix Does not round correctly #1475
• there is no related issue ticket (for all other features explained; well technically there are a lot of issues that would benefit from this, but it's too many to list here now)

Checklist:

• I did not change any code (e.g. documentation changes)
• The code change is tested and works locally.

Test-Hardware list (for code changes)

HA Version: 2024.12
Zigbee2MQTT Version: N/A (ZHA)
TRV Hardware: HmIP-eTRV-B-2 R4M by eQ-3 (HomematicIP)