As far as i know there isn’t a seperate frost protection mode. Most TRVs come with that feature build in. Even if they are off the frost protection is working. If TRVs don’t come with frost protection I would never turn them off in winter. As @odwide said, it’s recommended to stay at minimum 18°C, but it depends on the age of the building, insolation, humidity… I think it’s almost impossible today to get frost in the rooms except you leave windows open. The main reason to stay at least at 18°C is to prevent mold.
2 Likes
@panhans I have discovered an issue with the Tado temperature calibration. For some reason the calibration triggers an opening of the valve for 1-2 seconds. So the valve opens and closes periodically and this drains the battery. It is also quite annoying.
I am not sure what causes this. Is it possible that you are somehow telling the thermostat to also recalibrate itself for the valve?
The calibration is only called every 10 minutes and new values get only set if the new calibration value differs from the old ones.
My TRVs had that issue yesterday, too. But in my opinion it hast nothing todo with the automation. Did you updated to the new version of home assistant?
Two of my TRVs act like this yesterday but just for that time window.
Will see if this appears again.
Just see when the automation got called the last 3 times and have a look into your logbook especially your Tado. Then compare the times.
Did you integrate them using the Tado Bridge?
Alright, then it doesn’t sound like it is the root of the problem, although it did no occur anymore after I removed the recalibration from the automation.
I’ve been experiencing this issues for weeks now and not only yesterday. I already asked the support about this. No answer so far. I also have to say that I don’t like the whole closed-off cloud-based setup and am thinking of switching to Bosch or something else which uses Zigbee. I really like the compact design of the Tados, but the lack of control is frustrating. Whatever we send to the API, we never know what is actually happening under the hood.
I am using the latest HA version, yes.
Btw, I just put back the calibration and it happened again. When I look at the automations window, I can see that it has been triggered seconds ago. I think there is a link somehow. The trace also did end up at the calculated offset
Alright, when was the second last call? You can step back with the arrows next to the time stamp.
What happens if you take out the external sensor out of the automation and set the -3.5 offset manually. Also try full rounded values like -3.
ADVANCED HEATING CONTROL 3.0 BETA
logger:
default: warning
logs:
blueprints.panhans.heatingcontrol: debug
What changed?
- Guest Mode can be a timer
- multiple windows / doors possible
- calibration only triggers when external sensor gets updated - not time based anymore
- comfort temperature can be set in automation or provided by input_number
- party mode overrides all other settings
- simplified and more functional presence detection
- completely new logic for presence sensors
- presence detection only is possible now
//EDIT: Link deleted, since final version is out.
Happy testing! 
1 Like
I tried v3_beta2 (as a new user, just started with heating control today:)).
Getting errors in the log that brought me here: GitHub source code where is_heating_if_presence_only is evaluated but had never been written before.
1 Like
also here where the temperature setpoint is calculated, I couldn’t find a branch for my use case where I didn’t configure any presence setting but only the regular scheduler. Did I miss something or is this currently not supported (opposed to what the “optional” flag on all presence settings suggests)
Edit: defined a dummy toggle helper and used this as “guest mode” entity to make it work for now.
1 Like
Thanks for reporting. That was some old code. I deleted it from here but cant test it right now. Just reimport the blueprint.
1 Like
Thx for the fix. Another issue I see is that calibration doesn’t seem to work: it is correctly triggered but then exits with the first condition:
Any Idea how I could further debug this? Mode is “heat” in the last debug-log entry and I have an input-temperature_sensor defined - this is what triggers the automation in the first place as can be seen in the trace timeline:
1 Like
Calibration condition is fixed now. Thank you for testing and reporting.
Did you commit to the “non-v3” yaml intentionally? Commits · panhans/homeassistant · GitHub
Using the updated yaml, the above problem is fixed and calibration executed 
1 Like
Thanks… was a little too late for me. Now it’s commited on the correct blueprint.
I’ve added some logic to decrease zigbee / service calls. Before I push this to the v3 branch I will test it a little locally. The whole action is now more complex but some people had problems with the zigbee mesh utilisation. With that feature climates will only set if there is really something to change (temperature / mode). I’ve also combined the service call for setting temp and mode into one and added an option to split them if TRVs can’t handle the combined service call.
Question: when i have a “Party” it is automatically warmer then default, so why party mode is heating?
i think it would be better to have a option for timebased lower temp when more peoples are inhouse
Party is just a common term that is also used in previous heating systems. (Jura, Vaillant, etc.) The name does not come from me. 
It is only used for heating for a certain time outside the heating schedule.
2 Likes
ahhh okay, sorry 
is it possible to add a automatic timebased inputnumber? (Many peoples here and i wanna have a lower Temp for example 4 hours and than go back to normal setted temp)
Thats very tricky with the limited elements of home assistant and causes into a complicated blueprint setup imho since the default schedulers are only binary.
To achieve this that scheduler component would be better:
I would be easier to set the input_number comfort temperature in a 2nd automation or with help of this scheduler component.
1 Like
alright thank you.
Scheduler card/custom component this integration would be great when he would finally add a better Scheduler or add an external HomeAssistant Scheduler (helper), currently you need so many schedulers.
Hello! I don’t know if I’m doing something wrong or missing something, but is there an easy way to return to schedule after a time when manually setting a temperature (like on the thermostat itself)? If I switch temperature I don’t want to stay like this until the next schedule kicks in, just for like an hour or something.
Thank you!
Hi, this blueprint is designed for fully automated control. You can set temperature manually but if something triggers the automation like scheduler, window, guest mode ect. the temperature will be resetted.
Sadly there is - as far as I know - no way to figure out the source of temperature change. (device or home assistant)
Of course you can trigger the automation and reset temperature by calling automation.trigger or triggering the automation using the UI.
//EDIT: Ok, I think there is a way. With help of a timer this should be possible. Will set it on my feature list. When v3 runs stable enough I will have a look into this.
2 Likes