You are most welcome 
I switched the calibration blueprint I mentioned above off and tried calibration through AHCV4, but the calibration never gets triggered.
The trace shows a huge temperature difference between the room sensor and the TRV, but it stays like that.
Could you have a look at it?
-
Could you share the entity_id of your calibration entity?
-
Could you enabled debug logs in your configuration like this:
logger:
default: warning
logs:
blueprints.panhans.heatingcontrol: debug
After restarting home assistant just wait some time and in your log will occur some entries like:
2024-01-08 11:59:30.818 DEBUG (MainThread) [blueprints.panhans.heatingcontrol] - generic calibration enabled: False
- current_valve_temp: 19.2
- sensor_temp: 19.2
- step: 0.5
- min_temp_r: 5.0
- max_temp_r: 30.0
- new_temperature: 19
- temp_without_offset: 19
or
2024-01-08 11:54:02.154 DEBUG (MainThread) [blueprints.panhans.heatingcontrol] Calibration:
offset_old: -1.0
offset_new: -1
step: 0.1
diff: 0.0
delta: 0.5 full_rounding: "True"
Thanks for your reply. I’ve found your documentation now, sorry I’m new to everything HA so at the bottom of the learning curve.
My devices do not show up as climate which is why I am struggling. They are Fibaro motion sensors that also monitor temperature. The relay switches (FGS-223) turn on the UFH valves. Is it possible to edit the entities so that they show as climate?
1 Like
Sure, you have to setup a generic thermostat. Just have a look in the docs. It’s documented quite well.
1 Like
… yesterday night something strange happened …
After switching off Party-Mode (or was it the Z2MQTT Update or another update?) … somehow the function “not heat but auto” seemed to not work any more.
The TuYa TRVs (which I only have in one room) kept switching to Heat again and again.
(i did two times restore from backups - and deleting AHC for that room and building anew from the blueprint) … pretty sure, that the problem starts when switching off Party Mode.
(only AHC - no other climate relevant automations)
At the moment “not heat but auto” works … deleted the boolean_input for party mode … hesitant to ty again.
Found the bug. Will fix it soon.
Strange. There is only one point where mode will be evaluated. And yes, there is a bug but only if you force max temperature. (Will also fix this soon)
But in other cases it’s not. Could you check if an internal schedule of the valve itself was active or did z2m did a firmwareupdate?
Does this blueprint support to update the external_measured_room_sensor from Danfoss, Hive and Popp thermosthat valves?
See here: | Zigbee2MQTT
1 Like
Could you share a screenshot of your device (thermostat/valve) in home assistant?
What type of entity is external_measured_room_sensor. It seems like it’s part of the thermostat.
@Appox Please, check out latest version. Calibration should work for you now.
here they are:
The entidy-id is: number.valve_bedr_danfoss_external_measured_room_sensor
external_measured_room_sensor is a possible value in this format:
21,05° == 2105
Here is a good explanation: Danfoss 014G2461 control via MQTT | Zigbee2MQTT
1 Like
Ok, it’s not supported yet but with a little help we can do this.
Could you post the exact return value of this command (dev tools):
{{ device_attr('climate.YOUR_DANFLOSS_TRV','manufacturer') }}
The result is:
Danfoss
I am quite sure that for Popp devices it will be
Popp
and for Hive
Hive
They are all from Danfoss but branded for other markets.
Sounds great. I would love to test blueprint.
1 Like
If you like, you can checkout the latest v4 version and test if calibration works for you. Simply setup your climate entities and your external temperature sensor for calibration. Be sure Radiator_covered is set to false, if I read the docs correctly and give it a go.
1 Like
You were quicker to fix TYPO 
1 Like
Firstly, thank you so much for all the work and dedication put into the template!
I am currently using version 4.0_beta1. My goal is to adjust the temperature in a room based on the time of day and the presence of a person. For this, I have defined the parameter input_time_based_comfort_change as per the example.
The temperature is adjusted as desired at the specified time. However, my expectation was that the temperature would only change again when the next scheduled event occurs. In reality, after just a few minutes, the temperature is reset to advanced_heating_control_masterbedroom_input_temperature_comfort.
Am I doing something wrong? Here is my configuration:
I would greatly appreciate any help or advice. Thank you in advance!
- id: "1702806217524"
alias: Advanced Heating Control v4 - Masterbedroom
description: ""
use_blueprint:
path: panhans/heating_control_v4.yaml
input:
input_trvs:
- climate.masterbedroom
input_temperature_minimum: >-
input_number.advanced_heating_control_masterbedroom_input_temperature_minimum
input_temperature_comfort: >-
input_number.advanced_heating_control_masterbedroom_input_temperature_comfort
input_persons:
- person.person1
input_time_based_comfort_change:
- time: "06:45"
temp: "18.5"
- time: "20:00"
temp: "15"
input_windows:
- binary_sensor.0x00158d0002bfebd8_contact
input_windows_reaction_time_close:
hours: 0
minutes: 5
seconds: 30
input_temperature_sensor: sensor.0x00158d000273a2c5_temperature
input_reset_comfort_temperature: true
input_service_call_delay:
hours: 0
minutes: 0
seconds: 5
input_mode_party: timer.timer_for_valve_change_in_the_masterbedroom
input_start_party_timer_on_physical_change: true
input_change_comfort_temperature_on_physical_change: true
And here’s the definition for the two input_numbers:
advanced_heating_control_masterbedroom_input_temperature_minimum:
name: Minimum Temperature used by automations
initial: 15.5
min: 4.0
max: 24.0
step: 0.5
mode: slider
unit_of_measurement: °C
icon: mdi:thermometer-auto
advanced_heating_control_masterbedroom_input_temperature_comfort:
name: Comfort temperature used by automations
initial: 19.5
min: 12.0
max: 30.0
step: 0.5
mode: slider
unit_of_measurement: °C
icon: mdi:thermometer-auto
I would greatly appreciate any help or advice. Thank you in advance!
1 Like
I have to put some work into comfort heating plan. Just disable reset comfort temperature this should do the trick. The heating plan feature is some kind of stupid atm.
The heating plan just adjust the comfort temperature entity you’ve select. But with reset comfort temperature it gets reset to the static one when party timer / presence or schedule ends.
But for scheduler or presence the temp only gets reset if comfort heating turns off. So if scheduled heating crosses active presence heating no reset happen just if it turns to minimum temperature. Only party mode has this priority.
Thank you for your prompt reply! Much appreciated. I’ll disable the reset comfort temperature as suggested and report back. I believe I turned this on in order to reset the temperature one the timer for the manual override has finished. Let’s see.
If you need any assistance with testing or anything else, feel free to reach out. I’m happy to help contribute to improving. Thanks again!
1 Like
Just tried it. Seems to work as expected. 
One question to the proximity sensor. I currently monitor our two phones using the proximity sensor. Do I need to set the device tracker in the blueprint too?
1 Like
It depends. If you want to make scheduled / present based heating depending on persons you just need to select the persons.
Proximity has two funcions:
- If travel direction of proximity is set to arrived it’s like somebody is home. So it gets treaten like a person.
- If the distance of the sensor (state) is below your threshold and the travel direction is towards for a specific time. It’s also like there is somebody home. With that functionality you can achieve some kind of preheating when you’re on your way home.
If you don’t want to use this and you’re fine that heating starts when you’re home then you don’t have to select your proximity sensor.
1 Like
hey again …
Internal schedule should be off / never activated them … confirmed in Z2MQTT (device/details)
I rolled back the Z2MQTT Update and others (via restoring full backup) to rule out any involvement from this site.
Happened again at 1800 hrs today. pr.TRVs switched to Heat (means full power - no regulation for the TuYa - hence the addition of not heat but auto function)
as i read it in the logbook the end of my heating scheduler (pr.heizzeiten) triggered AHC which then triggered Heat / Force Open … (greyed out unrelated logs)
happened again some minutes ago … this time AHC got triggered by state of the TRV and then force changed both TRVs to Open.
and just to confirm that Not Heat But Auto is activated:
1 Like