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
Shame on me! I double checked that part of code. Indeed there was a bug. Please check out latest version and have a test again!
ups … you were faster … reimporting newest version … will be on the watch
BTW - i changed to generic calibration as the TuYa TRV seem to write calibration in flash memory with 100.000 write cycles max (calibrating every 10 minutes renders your TRV dead after approx. 2 years).
as stated here on the forum
EDIT: 
reimporting switched to Auto immediately
1 Like
Ok, but is there a reliable source? Fast google research didn’t gave me information about this.
//EDIT: The target temperature must be also stored in flash memory. So if it’s like this every change kill our TRVs more and more. Yes, it is but I am not sure if it’s so drastically as described. I have my TS0601 for round about 2,5 years now and changed temperatures and calibration values a lot. Until now they keep working fine. 
well, the guy is playing with oscilloscopes and firmwares in some of his posts … but maybe too drastic … wanted to be on the safe side … good to hear though, that yours are running fine (i am pretty 
with them)
this could be easily tested - set some crazy temp - remove batts - wait … (may try on some of the next days)
Hi guys,
I’ve had similar issues to @JamieMe with my SONOFF TRVZB thermostats. After updating Home Assistant to 2024.xx, the current temperature on the thermostats were jumping from -10 to 55 degree Celsius. I then discovered that the calibration started adjusting the thermostat temperatures based on my thermometer, using the offset function. The offset feature for my thermostats was introduced in the new version of Home Assistant. If anyone is facing similar issues (with SONOFF), I’ve managed to create a workaround using Version 4 of Advanced Heating Control.
Greetings
Hello @Panhans, I have been able to test the aggressive mode for some time now and would like to suggest two improvements. The current state of the aggressive mode opens or closes the thermostatic valve completely. This means that if I have a difference of 0.5 C° between the desired and the actual state, the valve opens or closes completely again and thus high battery consumption, wear and constant noise from the thermostat valve. If I have a fluctuation due to rounding of the temperature value or a change in the room temperature in the 1 degree range, the thermostat constantly opens and closes again every few minutes. To optimize this behavior, it might be possible to specify two configurable values in the blueprint. 1. the 0.5 degrees should be changeable. 2. the number of degrees that the thermostat valve is opened or closed when the aggressive mode is activated so that the valve only opens/closes a little further and not completely. what do you think about it? Is that possible and does it make sense in your opinion?
1 Like
I was going to ask for proximity support and I see it is in V4.
1 Like
People, don’t hesitate to show some love to @panhans! I am simply amazed by his relentless dedication and support to all of us.
Some ways to do that:
- buy him a coffee (see in the header),
- like the answers (there is a rating in this forum based on the “like to post ratio”).
1 Like
This really looks great. I think this will finally replace Better Thermostat for me 
1 Like
Yes, I understand. My valves only support open/close completely. I will add something to make the adjustment more granular.
Here you are. Just give it a try. It’s hard for me to test since I am working mainly from home. 
2 Likes
Hey @panhans,
thank a lot for you effort in making you automation better every day.
I stumbled upon a calibration error:
2024-01-11 20:57:02.422 DEBUG (MainThread) [blueprints.panhans.heatingcontrol] - state_mode_party: False
- state_mode_guest: False
- state_mode_winter: True
- state_force_max_temperature: False
- state_window: False
- state_presence_sensor: False
- state_temperature_comfort: 22
- state_mode_holiday: False
- mode: heat
- active_scheduler: schedule.heizung_pauline_schulzeit
- is_anybody_home: True
- is_mode_holiday_configured: False
- is_scheduler_on: False
- is_presence_sensor_defined: False
- is_presence_scheduler_defined: False
- is_presence: False
- temperature: 19
- valves: ['climate.heizung_pauline']
- valves_off_mode: ['climate.heizung_pauline']
- valves_without_off_mode: []
- valves_tado: []
- trvs_temp_not_set: []
- trvs_mode_not_set: []
- trvs_mode_and_temp_not_set: []
- trigger.id: calibration_trv_temp
- is_presence_heating: False
- is_presence_heating_with_scheduler: False
- is_presence_heating_without_persons: False
- is_presence_heating_with_persons: False
- is_no_presence_heating_or_presence_with_scheduler: True
- is_scheduled_heating: True
- is_scheduled_heating_without_persons: False
- is_scheduled_heating_with_persons: True
- no_person_is_defined: False
- input_persons_count: False
2024-01-11 20:57:02.470 DEBUG (MainThread) [blueprints.panhans.heatingcontrol] Calibration:
offset_old: 1.4
offset_new: 2.3000000000000003
step: 0.1
diff: 0.9000000000000004
delta: 0.2 full_rounding: "False"
2024-01-11 20:57:02.483 DEBUG (MainThread) [blueprints.panhans.heatingcontrol] Calibration set to: 2.3000000000000003 on number.heizung_pauline_local_temperature_calibration
2024-01-11 20:57:03.536 ERROR (MainThread) [homeassistant.components.mqtt.number] Invalid value for number.heizung_pauline_local_temperature_calibration: -390909132.7 (range -5.0 - 5.0)
Looks like a rounding issue. What do you think?
1 Like
Thank you so much for reporting this! Some users reported strange calibration values using z2m. This should be the reason. I just updated v4 to resolve this issue.
2 Likes
Sounds great. Fyi, i use the v3 and v4-beta. The issue is present in both versions.
1 Like
Hi Panhans,
Please can you explain a little more about the comfort temperature (optional) and winter modes please?
When I click on the entity boxes for those it says I have no matching entries so not sure what I’m supposed to do with them if I want to make use of them.
I looked through the documentation but couldn’t find specific reference to them and searching through this thread didn’t really help me sorry.
For me i would need something like this,
Name: Heating Bathroom
Start: 6AM
End: 7AM
Start: 3PM
End: 10PM
Description: Temp=22
Because i want heat when i get up, but not when at work.But it works very fine as it is for me, so no need for updates. I can set what i want in diffent schedules, It
I’ve added a custom action but it does not get triggered. Maybe it would make sense to be able to add some custom triggers?