🔥 Advanced Heating Control

[nberndt (Nicola Berndt)]

Yes, but in my case the target temperature ist not being raised and that is something AHC should do. I also tried aggressive mode but still nothing moves.

Besides that, thx for the link. I checked it out but had to find that my thermostat Nedis ZBEHTR10WT - https://nedis.de/de-de/product/haushalt-und-wohnen/klima/heizung/550743676/smartlife-heizkoerpersteuerung-zigbee-3-0-batteriebetrieben-lcd-android-ios simply does not expose the controls to set most of the stuff yours does. Using ZHA I’m stuck with very little features atm.

[hindseb]

Thanks @panhans that did the trick!

[Ohana_Means_family]

The temperature setting is not correct. It should heat to 22 C but sets other values. This has been the case since I set Generic Calibration.

[panhans]

@nberndt

The target temperature simply does not go high enough.

I think I’d limited the generic calibration to avoid those extremes. Atm I refactor the whole automation. I will implement something to make this a little bit more adjustable so you can go higher / lower with the calibration.

@Ohana_Means_family

Only the temp measured at the TRV is taken. This means that the rooms are far too cold. He did it before, I don’t understand why he calibrates it properly now that he has come back from the night setback.

Did your thermostats provides entities for calibration? If not you can go with generic calibration but this only works in combination with schedules, presence detection ect.

@Rapha0000

Maybe the window scene should be exempt from deleting while the window is still open.

I will have a look into this. The scene is deleted if there is a change in presence or schedule so it needs a new target temperature after closing the window. If there is no scene anymore the fallback values evaluated out of the base logic should be taken or did you get some kind of error?

@Rapha0000

Additionally the Lime Protection option seems to be dependent on input_mode_winter. This does not take the Invertion toggle into account.

Further I would like to have the Lime Protection completely independent of Winter Mode and have the valve cycle at all times (I have seen my valve getting stuck in winter as well since usually only minimal valve movements are done by the TRV).

Thanks for reporting. I will put this on my list.

@nberndt

Yes, but in my case the target temperature ist not being raised and that is something AHC should do. I also tried aggressive mode but still nothing moves.

Could you share you ahc configuration in yaml? Did you also check if there is a custom quirk for your thermostat. Just check the type in your device overview and search for it in this repo.

[panhans]

@Ohana_Means_family

The temperature setting is not correct. It should heat to 22 C but sets other values. This has been the case since I set Generic Calibration.

It is. Generic calibration adds the calculated temperature difference on top of the thermostat target temperature. Just check if your thermostats provide an entity or service for calibration.

[Ohana_Means_family]

@panhans

It is. Generic calibration adds the calculated temperature difference on top of the thermostat target temperature. Just check if your thermostats provide an entity or service for calibration.

It is calibrated by AHC from the external sensor.

In addition, I cannot manually enter a higher temperature in the thermostat card because it keeps resetting it.

I can’t understand why AHC does what it wants and doesn’t adjust the set temperatures as it should.

Normally only 19 °C should be shown here. But these are incorrect settings.

I suspect that this setting is incorrect.

.
.
Do I need this? Should take over AHC.

https://gist.github.com/pavax/8d6ed250765d89cb281d4a1762b8d2e8

[panhans]

Could you navigate to your template editor and paste this. Edit the climate entity to yours and share the result with me.

{% set valve = 'climate.YOUR_CLIMATE_ENTITY' %}

{{device_entities(device_id(valve)) |
          expand |
          map(attribute='entity_id') | list }}

Generic calibration is for thermostats that don’t provide a special calibration entity. If you tick this option, the target temperature gets manipulated.
Also the calibration only gets triggered if there is a temperature change. You can force it by holding the sensor in your hands for example. Don’t expect calibration just right after you saved the automation.

[Michael_Dahl]

Proximity, fund a fix.

Created a template sensor

template:
          
  - binary_sensor:
    - name: "Lilli on way home"
      state: >
        {{ states('sensor.skovkrogen_3_2_nearest_distance') | int < 9100 and states('sensor.skovkrogen_3_2_nearest_direction_of_travel') == "towards" }}
      

and then add the “Lilli on way home”, as a guest.

[PeL4]

Hi, I’m trying to make this blueprint work with no success so far.
We are starting spring and I wanted to use this for cooling rather than heating. Does it work for cooling?
You can pick a heat_cool HVAC mode, but I cannot make it work.

Every time I turn on my AC unit manually, it’s turned off by the automation a few minutes later.

[Rapha0000 (Raphael)]

@panhans

I will have a look into this. The scene is deleted if there is a change in presence or schedule so it needs a new target temperature after closing the window. If there is no scene anymore the fallback values evaluated out of the base logic should be taken or did you get some kind of error?

Can reproduce it every time.

• Window open sets the TRV setpoint to a low temperature.

• When Physical Temperature Change / Sync is active, this triggers the script again and it sets my Comfort Temperature helper to this lower value.

• This change of the Comfort Temperature triggers the script again and it deletes the scene

When the window closes it stays on the low temperature because that is now set as Comfort Temperature.

[nberndt (Nicola Berndt)]

@panhans

I think I’d limited the generic calibration to avoid those extremes. Atm I refactor the whole automation. I will implement something to make this a little bit more adjustable so you can go higher / lower with the calibration.

It seems to be limited to add a maximum of 2° to the target temperature. In my case I will need a lot more, since my thermostat jumps to close to 30° measuremnt, due to it’s shitty installation location. Will also have to work on this, yeah.

@panhans

Could you share you ahc configuration in yaml? Did you also check if there is a custom quirk for your thermostat. Just check the type in your device overview and search for it in this repo.

I use a custom quirk, namely ts0601_trv_siterwell.py , which exposes the switches, but names them “switch” and adds an offset feature, which seems to hang/crash the thermostat when given decimals. I don’t find the source for this quirk right now, but will see, if there is a better fitting one in the mentioned repo. Thx for this!

As for the requested YAML: Sure, this is what it is at right now. Tried everything that came to mind, though…
I’m not sure where “input_mode_room_temperature_threshold” comes from, or what it does…

alias: 🔥 Advanced Heating Control
description: ""
use_blueprint:
  path: panhans/heating_control.yaml
  input:
    input_trvs:
      - climate.tze200_hhrtiq0x_ts0601_thermostat
    input_temperature_sensor: sensor.thermo_sensor_wz_temperatur
    input_temperature_comfort: input_number.zieltemperatur_manuell
    input_calibration_options:
      - generic_calibration
    input_temperature_comfort_static: 25
    input_temperature_minimum_static: 22
    input_temperature_minimum: input_number.zieltemperatur_manuell
    input_calibration_timeout:
      hours: 0
      minutes: 0
      seconds: 2
    input_mode_room_temperature_threshold: 30
    input_calibration_delta: 1

Besides from that, I need a second thermostat and I will not buy that one again.
Does anyone have a good recommendation, best available in Germany/Europe?
It should be able to take an external offset in ZHA, with a range as large as possible.

[Rapha0000 (Raphael)]

@Ohana_Means_family

Do I need this? Should take over AHC.

AHC does that for you, you should see the external sensor temperature as Local Temperature in the Z2MQTT settings.

If it does not change, try to modify the ‘External Temperature Input’ slider and see if it starts updating after a couple of minutes. I have seen the external temperature not updating correctly until I set a value with the slider once (was after a factory reset of the E1). Might be a bug in Z2M.

You should not use the Generic Calibration feature since the E1 will use the external temperature once it is working (so no further ‘calibration’ is needed).

Also according to your Z2M settings page your thermostat is not calibrated, so it probably just does nothing at all or drives the valve to the wrong positions.

[nberndt (Nicola Berndt)]

So I looked for a quirk at the link given and also found the right one. This one though doesn’t give ma additional switches and no offset at all. Either that, or the quirk is not loaded. I removed the old one and put the new file right in place, so I guess it should work. In the quirk itself I can find mention of my device tze200_hhrtiq0x. How would I verify the custom_quirk is actually used?

class SiterwellGS361_Type2(TuyaThermostat):
    """SiterwellGS361 Thermostatic radiator valve and clones (2nd cluster signa>

    signature = {
        #  endpoint=1 profile=260 device_type=81 device_version=0 input_cluster>
        #  output_clusters=[10, 25]>
        MODELS_INFO: [
            ("_TZE200_jeaxp72v", "TS0601"),
            ("_TZE200_kfvq6avy", "TS0601"),
            ("_TZE200_zivfvd7h", "TS0601"),
            ("_TZE200_hhrtiq0x", "TS0601"),
            ("_TZE200_ps5v5jor", "TS0601"),
            ("_TZE200_owwdxjbx", "TS0601"),
            ("_TZE200_8daqwrsj", "TS0601"),
            ("_TZE200_czk78ptr", "TS0601"),
            ("_TZE200_2cs6g9i7", "TS0601"),  # Brennenstuhl Zigbee Connect 01
            ("_TZE200_04yfvweb", "TS0601"),  # Appartme APRM-04-001
        ],

[Ohana_Means_family]

@panhans

Could you navigate to your template editor and paste this. Edit the climate entity to yours and share the result with me

I don’t have much experience with tamplats yet.
Should I just copy it in there?

[panhans]

@Michael_Dahl

Proximity, fund a fix.

Great! But I also will check this in my revision.

@PeL4

You can pick a heat_cool HVAC mode, but I cannot make it work.

Sadly I just can check this in my testing environment because I don’t own a AC. But could you share me your automation configuration in yaml or a trace log after the AC turns off? (description in the first post)

@Rapha0000

When the window closes it stays on the low temperature because that is now set as Comfort Temperature.

Yes, this damn physical change workaround. I will check if I can get another workaround for this.

@nberndt

Besides from that, I need a second thermostat and I will not buy that one again.
Does anyone have a good recommendation, best available in Germany/Europe?
It should be able to take an external offset in ZHA, with a range as large as possible.

Most thermostats allows ± 5°C. Aqara, Popp / Danfoss / Hive / Nedis let you set an comoplete value of the measured temperature but I don’t know how they handle it under the hood.

@nberndt

How would I verify the custom_quirk is actually used?

You have to remove the devices out of your zigbee mesh, delete / rename the extension of your old custom quirk, restart home assistant and pair the thermostat again.

@Ohana_Means_family

Should I just copy it in there?

Yes, delete the input first. This is just for testing purpose. You can’t break anything.

[Michael_Dahl]

Must admit, I’d love to keep is simple and only use AHC with any hacks.

[Ohana_Means_family]

@panhans

Yes, delete the input first. This is just for testing purpose. You can’t break anything.

  "update.thermostat_pc_raum",
  "text.thermostat_pc_raum_schedule_settings",
  "switch.thermostat_pc_raum_schedule",
  "sensor.thermostat_pc_raum_device_temperature",
  "sensor.thermostat_pc_raum_battery",
  "number.thermostat_pc_raum_away_preset_temperature",
  "binary_sensor.thermostat_pc_raum_valve_alarm",
  "switch.thermostat_pc_raum_valve_detection",
  "binary_sensor.thermostat_pc_raum_window_open",
  "switch.thermostat_pc_raum_window_detection",
  "switch.thermostat_pc_raum_child_lock",
  "button.thermostat_pc_raum_calibrate",
  "binary_sensor.thermostat_pc_raum_calibrated",
  "number.thermostat_pc_raum_external_temperature_input",
  "select.thermostat_pc_raum_sensor",
  "climate.thermostat_pc_raum",
  "binary_sensor.thermostat_pc_raum_setup"

Is that enough for you or do you need more?

[nberndt (Nicola Berndt)]

@panhans

You have to remove the devices out of your zigbee mesh, delete / rename the extension of your old custom quirk, restart home assistant and pair the thermostat again.

That is exactly what I did. Maybe the quirk just makes it work better that without one, I don’t know. Also not important atm, because I don’t really care about setting the temperature offset, since it will be too small, anyway. Setting the target temperature should do the trick, I just have to get it to work…

Btw the quirk I used before, which exposes a bit more but hast issues with non-rounded setoff-values, came from here: Status of tuya TRVs implanted in ZHA. · zigpy/zigpy · Discussion #653 · GitHub

[Michael_Dahl]

A different issue

I have a normal schedule 08.30 to 21.30
I have a “Presence schedule 21.30-03.00”

(All motion, is group of all motion sensors and a mmwave in the living room, hence its constant on)
(AHC Stue, is the AHC sensor from the snip in OP)
(AHC tilstædeværelses tid, is the scheduler user for presence)

the issue is when normal scheduler end, and I must wait the (10 min in config) for the trvs to kick back it can take more then 10 min, and Danfoss Ally, will after a change from 23C->20C->23C, opens the valve quite a lot for the some time before reverting to normal.

I don’t know if there is a way to prevent this ?

[nberndt (Nicola Berndt)]

Using the quirk from the official zigpy/zha_handlers repository did not really work. It is loaded - found it in the logs - but while the device itself works, even though lacking some features, AHC gives me a warning in the logs: Your selected hvac mode auto isn't support by some of your climate entities: climate.tze200_hhrtiq0x_ts0601_thermostat This goes for"heat" and “auto”. In the end it shouldn’t matter, since all I want AHC to do is set the target-temperature, but still, it’s ugly in the logs…

Also it says I should install the “uptime integration”. Will look into that. In the meantime I will revert to my former quirk, which btw. is from here (posted a too generic link before): GitHub - jacekk015/zha_quirks: All quirks in one place