The automation only sets the target temperature. If the valve gets opened is handled by your thermostat.
If your thermostat can only open and close the valve fully, the offset is as good as irrelevant. It only needs to be large enough for the thermostat to react. So to be on the safe side, make it larger.
If your thermostat opens the valve opening as a percentage, you can work with smaller values for the offset.
1 Like
Ok, I got. it.
I have normal open and closed valves for underfloor heating. And to avoid overheating I wanted to use this function. The offset must then be greater than the switching control of the thermostat. Thanks for the explanation
1 Like
@panhans 2 Points:
- please add unique id parameter HomeAssistant/snippets/ahc_version_sensor.yaml at 3c6894819af8f8866f597bf97a7d1513db83885b · panhans/HomeAssistant · GitHub
- Tempalte Sensor “Last calibration” has no data
- done
- I’ve added also the variable to the event when using generic calibration.
1 Like
Hello @panhans Thank you very much for your Blueprint! I have a question, if I wanted to activate the thermostat with the dashboard, Automation will pause, for example when I want to warm up the office before going to work. Do you have any ideas? Thank you very much!
Hey, im currenlty playing around with the newest dev Version for all of my Heaters (Tado Theromostat) . But somehow on one unit the calibration goes crazy and pushes the value ob to -8°C. When I turn the AHC DEV Automation off and enable the regular AHC Automation everything works well. How could I assist you on the issue tracking?
thanks, Martin
@cediqqu Do you want to block the automation? Could you explain your use case a bit more?
@Break You could import the stable blueprint. I removed the dev version from the initial post. If the problem occurs again, I will carry out further investigations.
You can just import the stable blueprint and edit the link in your automations.yaml to it. Or you setup the automation from scratch.
ok, could you may give me a short example how to change the link?
as Setting up again 10 Automation isn’t something I want to do again today ;D
Open your automation.yaml and search for advanced_heating_control_dev.yaml. If you have imported the stable blueprint just remove the _dev in the blueprint reference and reload your automations in the developer tools.
ohh ok, then i need to remove my stable version before. got it. thanks
no need to remove the old ones. v4 files named like heating_control.yaml. Now the file name is advanced_heating_control.yaml
@panhans
What I want is, for example, when I go to the office in the morning, to set the temperature with the thermostat itself (physical) or through the thermostat card. And when i leave the room (with presence detection), the thermostat does not turn off automatically!
You can define a time window with a presence scheduler if presence detection is to be active.
As long as the scheduler is not changed and presence detection is ignored, you can set your thermostat as you wish. The automation should only set changes again when the scheduler changes status.
Alternatively, you can also set a custom condition. This can be, for example, a period of time when the automation is active or should be blocked.
Nice! I will try!! Thanks!! Great Blueprint!! 
1 Like
Question with regard to "Physical Temperature Change / Sync ":
Do I understand it correctly that with this option I can set the temperature by the TRV itself or thermostat card? How long the temperature is being set? At the moment, when I set it, only the comfort temperature is set by the option when it is enabled. It would be nice, if I can overwrite the desired temperature for a specific time frame until the automation kicks in or until the target temperature is reached. How can I do it?
1 Like
Hey, unfortunately the issue still persists. 
This is my automation that somehow bugs around wirh the calibration
alias: 🔥 AHC Martin
description: ""
use_blueprint:
path: panhans/advanced_heating_control.yaml
input:
input_trvs:
- climate.heizung_martin
input_temperature_sensor: sensor.zsensor_martin_temperatur_temperature
input_temperature_eco_static: 17
input_temperature_comfort_static: 21
input_adjustments:
- time: "05:00"
comfort: "20"
calibration: "on"
- time: "09:00"
calibration: "on"
- time: "16:00"
comfort: "18"
calibration: "on"
- time: "21:00"
comfort: "18"
calibration: "on"
input_persons:
- person.daniela
- person.martin
input_presence_sensor: binary_sensor.mmwave_presence_sensor_martin_belegung
input_presence_reaction_on_time:
hours: 0
minutes: 0
seconds: 10
input_presence_reaction_off_time:
hours: 0
minutes: 5
seconds: 0
input_away_offset: 2
input_away_presence_mode: false
input_windows:
- binary_sensor.fenster_martin
input_liming_protection: true
input_liming_in_winter: false
input_mode_winter: input_boolean.sommer_winter
input_mode_outside_temperature: sensor.gw2000a_outdoor_temperature
input_mode_outside_temperature_threshold: 20
input_generic_calibration_offset: 5
If you disable this feature you can set the temperature you want. The temperature will get reset when scheduler / presence, ect. change its state next time. But there is no synchronization between them.
If you enable it, the temperature of the current mode (eco/comfort) will be changed. And all thermostats will be synced to that temperature. When enabling reset temperature the entities gets reset to the static temperature that are defined when presence, schedule, ect. ends / starts.
@Break
Could you check the lates version? I don’t know exactly what the Tado Offset consumes. The example on the docs is a little bit confusing. Is this an offset with a specific range, e.g. -6° - +6° or an absolute temperature? Are floating values allowed or just integers? Is there a max/min offset? That information would help a lot.
Maybe I find something here in the community board.
im now running 5.0.4b and it looks like its working. In general I can say it worked with V4 before.
Regarding your question with the offset value for taco, there is unforuantly no entity ore something similar that I can check to assist. sorry . The only thing a can tell you is that on the Tado app you can just the Offset from +10.9° to -10.9°.
But I have something in mind, that I already hat some similar issues a year ago where I started with our Automation.
Hey panhans,
I just set up version 5.0.3 of your blueprint, but I’m seeing some strange behavior with the calibration. I’m using Bosch thermostats, which worked fine in version 4, but now the automation seems a bit broken. The calibration oscillates across the whole range (10°C), moving up and down.
It seems there might be an issue with the calculation of the difference between the thermostat and room temperatures. When the calibration offset is applied, the thermostat temperature is lowered accordingly, and if it’s checked again in short succession, it ends up overcompensating in the opposite direction. This repeats with each cycle. I suspect the oscillation is linked to my room temperature sensor, which reports new values every 2 seconds and provides fluctuating data when the room temperature cools by 0.1°C.
It could be due to how frequently my temperature sensor triggers the automation, but this wasn’t an issue in version 4 using the same settings. I’d be happy if you could look into that as I was excited to try out the new aggressive calibration mode. Thanks a lot!
