no problem…as i used it the first time, i was also confused 
Proximity test from today.
I have now disabled proximity, it does not work… 
will make a template so simulate person at home, when travling towards and distance under 8000m
which TRVs are you using?
Hi there and many thx for this blueprint! 
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:
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!
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
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 .
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
Unfortunately, the calibration does not seem to work. Has something been set incorrectly?
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.
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).
you forgot to set the generic calibration, than it should work!
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.
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.
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.
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.
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.
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.
1 Like
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.
Can reproduce it every time.
- Window open sets the TRV setpoint to a low temperature.
- When
Physical Temperature Change / Syncis active, this triggers the script again and it sets myComfort Temperaturehelper to this lower value.
- This change of the
Comfort Temperaturetriggers 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.