KartoffelToby / better_thermostat

This custom component for Home Assistant will add crucial features to your climate-controlling TRV (Thermostatic Radiator Valves) to save you the work of creating automations to make it smart. It combines a room-temperature sensor, window/door sensors, weather forecasts, or an ambient temperature probe to decide when it should call for heat and automatically calibrate your TRVs to fix the imprecise measurements taken in the radiator's vicinity.
https://better-thermostat.org
GNU Affero General Public License v3.0
746 stars 122 forks source link

HomematicIP devices keep endlessly heating due to homematic algorithm #1133

Closed Hidri02 closed 9 months ago

Hidri02 commented 9 months ago

Prerequisites

{
  "home_assistant": {
    "installation_type": "Home Assistant Supervised",
    "version": "2023.11.2",
    "dev": false,
    "hassio": true,
    "virtualenv": false,
    "python_version": "3.11.6",
    "docker": true,
    "arch": "armv7l",
    "timezone": "Europe/Vienna",
    "os_name": "Linux",
    "os_version": "5.10.103-v7l+",
    "supervisor": "2023.11.0",
    "host_os": "Raspbian GNU/Linux 11 (bullseye)",
    "docker_version": "24.0.2",
    "chassis": "",
    "run_as_root": true
  },
  "custom_components": {
    "scheduler": {
      "version": "v0.0.0",
      "requirements": []
    },
    "homematicip_local": {
      "version": "1.48.0",
      "requirements": [
        "hahomematic==2023.10.14"
      ]
    },
    "hacs": {
      "version": "1.33.0",
      "requirements": [
        "aiogithubapi>=22.10.1"
      ]
    },
    "better_thermostat": {
      "version": "1.4.0",
      "requirements": []
    },
    "localtuya": {
      "version": "5.2.1",
      "requirements": []
    }
  },
  "integration_manifest": {
    "domain": "better_thermostat",
    "name": "Better Thermostat",
    "after_dependencies": [
      "climate"
    ],
    "codeowners": [
      "@kartoffeltoby"
    ],
    "config_flow": true,
    "dependencies": [
      "climate",
      "recorder"
    ],
    "documentation": "https://github.com/KartoffelToby/better_thermostat",
    "iot_class": "local_push",
    "issue_tracker": "https://github.com/KartoffelToby/better_thermostat/issues",
    "requirements": [],
    "version": "1.4.0",
    "is_built_in": false
  },
  "data": {
    "info": {
      "name": "Heizung Wohnzimmer",
      "temperature_sensor": "sensor.temperature_3",
      "off_temperature": 20,
      "tolerance": 0.2,
      "humidity_sensor": "sensor.humidity_3",
      "outdoor_sensor": "sensor.temperature_1",
      "window_sensors": null,
      "weather": null,
      "cooler": null,
      "window_off_delay": 0,
      "window_off_delay_after": 0,
      "model": "HmIP-eTRV-2"
    },
    "thermostat": {
      "climate.heiz_thermostat_wohnzimmer": {
        "name": "Wohnzimmer",
        "state": "heat",
        "attributes": {
          "hvac_modes": [
            "auto",
            "heat",
            "off"
          ],
          "min_temp": 11.0,
          "max_temp": 30.0,
          "target_temp_step": 0.5,
          "preset_modes": [
            "boost",
            "none"
          ],
          "current_temperature": 17.3,
          "temperature": 13.5,
          "hvac_action": "idle",
          "preset_mode": "none",
          "interface_id": "RaspberryMatic-HmIP-RF",
          "address": "000A1D89A5DEF9:1",
          "model": "HmIP-eTRV-2",
          "entity_type": "custom",
          "value_state": "valid",
          "friendly_name": "Wohnzimmer",
          "supported_features": 17
        },
        "bt_config": {
          "calibration": "target_temp_based",
          "calibration_mode": "heating_power_calibration",
          "protect_overheating": false,
          "no_off_system_mode": false,
          "heat_auto_swapped": false,
          "child_lock": false,
          "homaticip": true
        },
        "bt_adapter": "homematicip_local",
        "bt_integration": "homematicip_local",
        "model": "HmIP-eTRV-2"
      }
    },
    "external_temperature_sensor": {
      "entity_id": "sensor.temperature_3",
      "state": "17.9",
      "attributes": {
        "state_class": "measurement",
        "unit_of_measurement": "\u00b0C",
        "device_class": "temperature",
        "friendly_name": "Temperatur Wohnzimmer"
      },
      "last_changed": "2023-11-11T15:16:55.626925+00:00",
      "last_updated": "2023-11-11T15:16:55.626925+00:00",
      "context": {
        "id": "01HEZFA66AH85ENHA5XB7999CG",
        "parent_id": null,
        "user_id": null
      }
    },
    "window_sensor": "-"
  }
}

Description

I am using homematicIP HmIP-eTRV-C and HmIP-eTRV-2 TRVs in my home. They are controlled locally via the RaspberryMatic AddOn + Homematic(IP) Local integration. An issue with those TRVs is that they have their own wacky algorithm to figure out when to heat and how much to open the valve to reach the set temperature. The TRV will open the valve way before the temperature actually drops below the set temperature in an attempt to catch the temperature drop of with minimal heating and hold the temperature at or above the set temperature. For example you have 21° set with currently 21.6° and the valve slowly starts opening. This sadly can not be disabled or circumvented (afaik).

This becomes an issue with how BT interacts with them through target based temperature control when combined with an external temperature sensor. From my experience BT only sets the target temperature a little lower (~0.5° depending on rounding etc.) than the current temperature on the TRV when not trying to heat. The homeaticIP TRVs will still open the valve at that point though due to their alogrithm and keep heating up while BT will keep adjusting the target temperature up to keep ~0.5° under the current temperature --> creating an endless heating cycle when its actually supposed to cool down because the target temperature for the external temperature sensor has long been reached.

Steps to Reproduce

  1. Use HomematicIP thermostats
  2. The automatic algorithm of them opens the valve already when set temperature sleightly below the current temperature
  3. Control via BT and external temperature sensor
  4. Reach target temperature and try have it shut off / close the valve
  5. Valve never closes

Expected behavior:

BT should recognise that the temperature at the TRV keeps rising and the TRV is in heating state even though the temperature at the external sensor has already been reached and lower the set temperature further or even go as far as to shut the TRV off completely.

Actual behavior:

BT keeps adjusting the temperature to sleightly below the current TRV temperature causing the homeaticIP alogirthm to keep the valve open as it hasn't reached the temperature yet.

Versions

HA Core: 2023.11.2 BT: 1.4.0

wtom commented 9 months ago

Why don't you set in BT on the settings "no calibration"? The Homematic algorithm is the best out there. Plus it learns itself. It will adapt after some time and should be very consistent with keeping the temperature. As said I wouldn't use any calibration on the Homematic TRVs.

Hidri02 commented 9 months ago

Are you using them in that setup? How exactly does "no calibration" work together with external wall thermostats / what is the difference to the other modes? I am testing it right now and from what I can tell so far I get the same issue.

Temperature in BT is set to 18.5°C while wall temperature sensor shows 18.8°C. So we are already 0.3°C above the set temperature for the room and on the TRV the temp is 21.6°C with a set temp of 21°C yet the valve is still 33% open and temperature keeps rising. A little later the wall temperature sensor shows 18.9°C while the TRV shows 21.8°C. BT adjustet the set temperature on the TRV from 21°C to 21.5°C. valve actually opened further to 49% open because the new set temperature is only 0.3°C below the current TRV temperature vs 0.6°C before.

Usually the alogrithm closes the valve for me when TRV temp is about 1°C above the set temp. It never gets to that though as BT corrects the set temperature upwards as well when the TRV temp rises (so it remains about 0.5°C below the current temp) even though the set temperature for the wall sensory has already been reached long ago.

I know that I could use the external wall sensors from Homematic directly together with their TRVs but those are expensive, and the whole point for using BT for me is the option to mix and match different devices :)

wtom commented 9 months ago

The no calibration should just send the target temperature from BT to the TRV without any adjustments.

nurunet commented 9 months ago

Isn't this at least very similar to this: https://github.com/KartoffelToby/better_thermostat/issues/889 ?

I noticed a similar issue with my eTRV-2 which is in the same room as another radiator with an Aqara TRV. Now I changed calibration to normal and ticked "overheat protection" for good measure. Let's see.

Hidri02 commented 9 months ago

Thanks @nurunet! Reviewing #889 yes, this is pretty much the same issue I am running into. Reading through it and a bit more code I also realized that the changes made to the overheating protection setting back then are exactly what I needed as a fix as well. I didn't realize that the overheating protection is adjusting the target TRV temperature lower and lower if the temperature keeps increasing when the set point has already been reached.

I guess the documentation about that setting could be improved a bit more ^^

Thanks for the help everyone, sorry for raising an issue uneceassarily!

folfy commented 9 months ago

The no calibration should just send the target temperature from BT to the TRV without any adjustments.

@wtom: Haha, yeah, I thought the same, but comapred to "fixed", it actually just disables "limiting" the values. xD With "no calibration", in heating mode the applied offset can be below -2.5C, while with "fixed calibration" it's limited to this value, but the original t_sensor - t_trv calibration is still applied. So yeah, this mode sure is broken, even though nobody/nowhere it's documented what this mode should do. Actually should open a new issue for this, but I'm lazy, I'll just straight up make a PR as soon as I got to fixing it, cause honestly @KartoffelToby seems more than busy enough with all the current issues.

Also gonna provide more update in #889, wanna implemented an alternative algorithm for HmIP, that should solve the original issue.