You aren’t enabled aggressive mode, right? ATM there are some limitation when changing something using the device itself. It’s related to a bug of home assistant. But currently I am working on it to decrease these side effects. I will add more blockers so the automation gets way calmer this week. I think your problem will be solved with it, but only for non aggressive / generic calibration users.
Could you disable the automation and enable your boost mode? Could you filter for your thermostat in developers state section and share a screenshot with its state and attributes with me? Maybe there is something specific to evaluate in the blueprint in order to block those resets. Thanks
Here is my current blueprint config:
alias: AHC - Büro
description: ""
use_blueprint:
path: panhans/heating_control.yaml
input:
input_trvs:
- climate.int0000007
- climate.meq1779676
input_temperature_minimum_static: 19
input_windows:
- binary_sensor.0023dd89a5120a_state
input_windows_reaction_time_open:
hours: 0
minutes: 2
seconds: 30
input_windows_reaction_time_close:
hours: 0
minutes: 20
seconds: 0
input_calibration_delta: 0
input_mode_outside_temperature: sensor.wetterstation_temperatur
input_log_level: debug
input_mode_winter: input_boolean.wintermode
input_temperature_comfort_static: 21.5
input_persons:
- person.mia
input_people_entering_home_duration:
hours: 0
minutes: 10
seconds: 0
input_people_leaving_home_duration:
hours: 0
minutes: 10
seconds: 0
input_mode_outside_temperature_threshold: 17
currently I added both, the hm group entity (which consists out of a room thermostat and a trv) and the tvr itself since this solved my problem with the window close reaction time.
I had the same issue there, after closing the window the trv was instantly set back to my comfort themperature instead of waiting 20m. This was also caused by the valve_temperature_change_aggressive_mode trigger.
I disabled the automation as requested and here the attributes of the entities:
int0000007 (hm group):
hvac_modes: auto, heat, off
min_temp: 4.5
max_temp: 30.5
target_temp_step: 0.5
preset_modes: boost, comfort, eco
current_temperature: 21.9
temperature: 21.5
preset_mode: none
id: INT0000007
interface: groups
valve:
mode: Boost
friendly_name: HM-GRP-Büro
supported_features: 401
climate.meq1779676 (trv):
hvac_modes: auto, heat, off
min_temp: 4.5
max_temp: 30.5
target_temp_step: 0.5
preset_modes: boost, comfort, eco
current_temperature: 21.9
temperature: 21.5
preset_mode: none
id: MEQ1779676
interface: funk
battery: 2.9
rssi_peer: -65535
valve: 80
mode: Boost
friendly_name: Heizkörper Büro
supported_features: 401
Thanks! 
Ok. seems quiet easy to block the automation since your thermostat is in mode boost. I will reject them if they are in this state.
Hot Fix 4.0.3_HotFix1
FIX: generic calibration sets thermostat to max if external sensor has non numeric state
FIX: generic calibration offset range is set to min -2 and max +2 ° now
Hi this is the yaml blueprint.
alias: Zolder AHC
description: ""
use_blueprint:
path: panhans/heating_control.yaml
input:
input_trvs:
- climate.0x0cae5ffffeacb883
input_temperature_minimum_static: 15
input_temperature_comfort_static: 20
input_schedulers:
- schedule.zolder_trv_schedule
- schedule.empty_schedule
input_scheduler_selector: input_boolean.zolder_trv_weg
input_mode_party: input_boolean.zolder_trv_party
input_temperature_sensor: sensor.0xf4b3b1fffe44f22a_temperature
input_tweaks:
- reset_temperature
- off_instead_min
Looks good to me. Could you check if there is an internal scheduling active for your thermostat? Some thermostats use mode auto for manual mode and heat for boost. (There is also an option in the blueprint configuration for this case. auto means heat)
But you can have a look into your logbook and check what or who set your thermostat target temperature to 33°C. Maybe you share a screenshot here. If the source is AHC it would be great if you can share a trace log from this point of time. If you need help let me know. Also check the initial post.
oh, i did a full swap yesterday, so i think there are no logs from the initial heating settings. where can i found the trace logs? and what do u mean by check te initial post? sorry for the questions…
yet another question (just started HA for 1 month…) how to set debug level to warning?
did you add this hotfix also to the dev version?
Hi, I am trying to understand the interaction between Presence and Schedulers.
The behaviour I want to achieve is if presence is true AND schedule is true, then comfort temperature. Otherwise (nobody is home or we are sleeping), eco temperature.
Presence works as expected on its own. Schedule also works on its own. However when configuring both, I can’t get the desired behaviour. With or without a Presence Schedule, presence just seems to be ignored entirely as far as I can tell from poking around.
Is there a clean way to achieve this? I was thinking of just ANDing the schedule and the presence variable in a helper, and using that for presence in AHC, but maybe there is a better way.
Not yet. Atm pushed in stable.
Schedulers and presence detection is not combinable. Both can be coupled with persons. But there is a presence scheduler you can define. But atm it’s only possible to chose only one.
…ok…
Yep, will implement this in the next step if the dev version has no major issues so far.
AHC4.0.4_dev2
ADD: decouple thermostat temperature changes (not for aggressive mode / generic calibration)
DEL: experimental features (will come back if developers fix that damn bug)
ADD: trigger filtering by id’s (just under the hood improvement)
FIX: generic calibration sets thermostat to max if external sensor has non numeric state
FIX: generic calibration offset range is set to min -2 and max +2 ° now
FIX: bug in scheduler selection
FIX: entry selection in scheduler adjustments
1 Like
does this mean if the external sensor is unavailable the TRV goes to max?
For me it would be economically better if he TRV goes low.
Nope, that was a bug and is fixed now. It was only related to generic calibration.
If calibration sensor is unavailable now the thermostat will set to target temperature without calibration offset. Maybe it should also produce a waring in the log.
1 Like
I think it would be nice to change the operation mode in a smart way.
The simplest way is to implement a selector for the operation mode in the blueprint settings. But I think there must be a way to control this dynamically. So here are some ideas:
-
If winter mode is on → hvac mode is heat / winter mode off → hvac mode cool
-
Overwrite the hvac mode with scheduler names like Work Scheduler Cool
-
Use outside temperature threshold to switch to hvac mode cool
Ideas are always welcome. 
2 Likes
Thanks for reply and think about it.
A Smart way would be nice, in my case i use different Automations because in Cooling time i have different temperatur settings as in heating slots, so a selector would be nessersery, and we have also the function dry and fan.