🔥 Advanced Heating Control

Blueprints Exchange
, ,
1717

the aggressive mode adds a temperature offset to the target temp.
in your case:

target temp: 22
aggressive offset: 2
new target temp: 24

so the valve should open more, because the automation thinks that you want to heat to 24°! With the offset you have to try what will work well!

If the range is set to 1 the following will happen:
the aggressiv offset will be added until the real temperature reaches 21°. Between 21 and 22 the offset will be 0!
In your case i would set the range to 0,3, which means that the offset will added until the real temp is 21,7°. Starting from 21,7 till 22 the offset will be 0.

1 Like
1718

Ah, yes and no. If winter mode is off the automation sets the climates to off and blocks subsequent calls. But if the state changes it runs again and forces it to off.

Could you try a custom condition (tweak section)? Just check there for the correct value of your winter mode entity.

1719

Like this?

image
image1022×319 24.2 KB

1720

Addendum: it now shows 2° less than the target temperature in the settings. If I am interpreting this correctly, it will only start heating when the actual temperature is below 18°. ?

image

1721

your settings are right.
the following happend:
if the real temp is smaller than the target, than the offset is added.
if the real temp is lower than the offset than the offset will be substracted (until target temp and real are nearly identical)!
If i’m right, your real temp is 21 and the target is 20, so the offset will bis substracted and the new target is 18. If the real temp is lower than 20,3° the offset will be 0 and the target temp jumps to 20!

1722

Ah, now it’s a shoe. I’ve just tested it too and it seems to work exactly as you said.

If I set the target temperature to 21° (actual temperature also 21°), the displayed target temperature jumped from 18° to 21°. When I set the target temperature to 22°, it changed from 21° to 24°.

No wonder I didn’t understand that :wink:
Thank you very much!

1723

no problem…as i used it the first time, i was also confused :wink:

1724

Proximity test from today.

I have now disabled proximity, it does not work… :frowning: will make a template so simulate person at home, when travling towards and distance under 8000m

image
image1826×1008 52.8 KB

1725

which TRVs are you using?

1726

Hi there and many thx for this blueprint! :slightly_smiling_face:

I have some issues, though.

What I am after is simply adjusting for the offset given in the temperature measured by my thermostat (nedis ZBHRT10WT / TS0601 von _TZE200_hhrtiq0x, with ts0601_trv_siterwell.py quirk).

The problem in my installation is that the radiator is behind a cover with holes and so is the trv, so it gets pretty warm the moment heating kicks in. I bought a thermometer which I placed in the room to get accurate readings.

Direct offset adjustment doesn’t really work - the thermostat crashes or gets stuck on a reading, seemingly doing so whenever it is given a non-integer for the offset. 2, 3, 4 all work, but 3.2 leads to a fault right away. Rounding values lead to alternatig +10/-10 offsets.

OK, on to adjusting the target temperature… This somewhat works, but not on point. I can’t really figure out the logic behind it, but it doesn’t always adjust when I expect it and if it does, it would not go as high up as needed.

Here’s a screenshot which should show the issue:

thermo_01
thermo_011504×814 27.9 KB

Red is the temperature sensor, Blue is thermostat temperature and Yellow is the target temperature.

The target temperature simply does not go high enough.

I was so happy finding this solution after really being at a loss when I bought the devices, because I had (naively) thought I could just tell HA to use the room temperature sensor as the source for measurement. I had to learn that (of course) the actual TRV still does all the work and has no way of knowing my wishes…

How can I further debug this?

Best regards!

1727

Hi,

I found this blueprint by browsing the forum for a good automation for my heating and it seems very good and exactly what I needed. However I have couple of issues with it.

My set-up as the follows

  • Valiant natural gas heater with two zones and smart thermostats
  • Thermostats integrated in HA with myVaillant integration and it is working great
  • This smart system has some basic automation function like a weekly schedule and away / vacation mode and it is working and can be controlled from HA
  • I already have an automation which turn heating to ‘Away’ when nobody at home

The only thing is missing to detect if one of the two zones are unoccupied, so I’m trying to set-up this blueprint for this, so if nobody in one of the zone it should lower the temperature. The occupancy is detected by several motion / occupancy sensors combined as binary group entity.

So, the expected behaviour is the following

  • if one of the zone is unoccupied → change the heating to ECO (basically it will show as ‘Quick veto’ in myVaillant app). Unfortunately there is no option to run-on away mode per zone…

My automation looks like this

alias: Földszint fűtés - automation
description: ""
use_blueprint:
  path: panhans/heating_control.yaml
  input:
    input_trvs:
      - climate.potala_zone_fsz_circuit_0_climate
    input_temperature_minimum_static: 17
    input_temperature_comfort_static: 22.5
    input_persons:
      - person.viki
      - person.vlad
    input_presence_sensor: binary_sensor.foldszint_occupancy
    input_away_offset: 10
    input_away_options:
      - presence
    input_proximity: 371ddea2f0f18420c7425c0230af7ee9
    input_schedulers: []
    input_hvac_mode: heat
    input_log_level: error
    input_mode_outside_temperature: sensor.potala_outdoor_temperature
    input_mode_room_temperature_threshold: 24

Is there any thing wrong with this approach? I also have a smart radiator valve (Sonoff) where the automation seems ok and changes to the eco temperature when the room is unoccupied

alias: Konyha Fűtés - automation
description: ""
use_blueprint:
  path: panhans/heating_control.yaml
  input:
    input_trvs:
      - climate.konyha_valve_1
    input_temperature_minimum_static: 16
    input_presence_sensor: binary_sensor.konyha_occupancy
    input_away_options:
      - presence
    input_proximity: 371ddea2f0f18420c7425c0230af7ee9
    input_log_level: error
    input_hvac_mode: heat
    input_persons:
      - person.viki
      - person.vlad
    input_away_offset: 7
    input_liming_protection: true
    input_mode_outside_temperature: sensor.potala_outdoor_temperature
    input_mode_room_temperature_threshold: 24
    input_mode_outside_temperature_threshold: 18
    input_schedulers: []
    input_mode_room_temperature: sensor.konyha_temp_temperature
    input_temperature_comfort_static: 22.5
1728

TS0601 (and its siblings) has many internal advanced settings that do change the behavior of the internal logic / the TRV itself.

I opened a thread, where I try to collect all findings from all over the net and my own experience. (Still experimenting how to get the best out of them - in combination with AHC)

You can find it here: Tuya TS0601 - Moes HY368 TRV - Best Practices - Summary Thread .

1729

So, I figured out at this moment I don’t need so advanced solution, so I created simpler ones and I think it worth sharing it for someone who also need a simple solution

if nobody in the zone (lower the temp)

alias: Emelet - Fűtés - ECO ON
description: ""
triggers:
  - minutes: /10
    hours: "*"
    trigger: time_pattern
conditions:
  - condition: and
    conditions:
      - condition: template
        value_template: "{{ is_state('binary_sensor.emelet_occupancy', 'off') }}"
      - condition: template
        value_template: >-
          {{ state_attr('climate.potala_zone_emelet_circuit_1_climate',
          'temperature') | float > 17 }}
actions:
  - action: climate.set_temperature
    target:
      entity_id:
        - climate.potala_zone_emelet_circuit_1_climate
    data:
      temperature: 17
mode: single

if occupancy detected, so set the temperature to a higher value

alias: Emelet - Fűtés - ECO off
description: ""
triggers:
  - minutes: /10
    hours: "*"
    trigger: time_pattern
conditions:
  - condition: and
    conditions:
      - condition: template
        value_template: "{{ is_state('binary_sensor.emelet_occupancy', 'on') }}"
      - condition: time
        after: "05:00:00"
        before: "22:30:00"
      - condition: numeric_state
        entity_id: sensor.potala_outdoor_temperature
        below: 16
      - condition: template
        value_template: >-
          {{ state_attr('climate.potala_zone_emelet_circuit_1_climate',
          'temperature') | float < 22.5 }}
actions:
  - action: climate.set_temperature
    metadata: {}
    data:
      temperature: 22.5
      hvac_mode: auto
    target:
      entity_id: climate.potala_zone_emelet_circuit_1_climate
mode: single
1731

Unfortunately, the calibration does not seem to work. Has something been set incorrectly?

grafik
grafik1030×729 51.2 KB

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.

1732

Hey.
I think there is a little problem with the combination of Window Detection and Physical Temperature Change. After closing the window it will not reset back to the original temperatures. The window scene is deleted while the window is still open.

I think what happens is:

  • Window open triggers, scene is created, comfort temperature is modified, setpoint of the thermostat is modified
  • Changing the setpoint triggers the Physical Temperature Change detection and the comfort temperature is set again (to the same value, but the last modified time changes)
  • temperature_change_comfort gets triggered again, but since it was no physical change it will process normally and delete all scenes.
  • The window off trigger now cannot reset the temperature back since the scene was deleted

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

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).

1733

you forgot to set the generic calibration, than it should work!

1734

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.

1735

Thanks @panhans that did the trick!

1736

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.

grafik
grafik1007×452 26.7 KB

grafik
grafik392×703 25.5 KB

1737

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.

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.

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?

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

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.