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.
1 Like
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
I’ve been running/testing this blueprint for some weeks now and just started testing the latest beta.
I have a Tado system running 8 TRVs some of which I’m controlling via the Tado integration and some via Homekit. Does anyone have a preference for running this blueprint with the Tado integration or the Homekit integration, I’d really appreciate hearing other peoples experiences of these 2 options.
Yes I like the idea of keeping everything local but not sure if it’s enough.
As for the calibration, I see it is only updated when the external temperature changes. This leads to quite some offsets in my setup, where the TRV temperature is “faster” than the external sensor and “runs away” until the next trigger by a change in the external sensor which will change the calibration and thus reset the TRV temperatureto that of the external sensor. See attached image (the filled line is the TRV sensor including calibration offset).
Wouldn’t it make sense to trigger the calibration only and always when the difference between the two temperatures exceeds a given threshold, like 0.5 degrees? That both avoids “noisy” updates on 0.1 degree steps and makes sure the offset is always limited, no matter which of the two sensor moves first.
1 Like
Hi there!
Also tested v3 and am blown away by the new features and clearer descriptions. It‘s been working great so far.
However, since I‘m using Tado and have installed external sensors now for every room, I can agree to what some user wrote before: unfortunately, Tado TRVs unnecessarily recalibrate whenever a new offset is put, which leads to an opening and closing of the valve for a short time. This obviously generates noise but also drains the battery. You can read more about it in the official Tado forum, where this has been addressed and people were asking for a firmware fix. Hasn‘t happened in three years.
For me, a couple of opening/closings a day would be an acceptable payoff for the increased comfort of using external sensors.
The question now is: is there a way to limit the number of calibrations by applying a rule like the following, which was suggested in the thread above:
Only apply recalibration…
- IF changing offset will immediately turn heat on or off AND required offset change will be >= 0.5 OR
- IF changing offset will prevent heat turning on or off prematurely AND required offset change will be >= 2.0. (This threshold is set higher because it probably doesn’t matter as much – worst case is the heating goes off/on a bit early but then gets turned back on/off a minute later – and hence to save offset adjustments/battery.)
I‘m not sure how many calibrations this would actually save, but it may be worth a try.
I‘m probably asking too much since this sounds fairly complicated and obviously only affects TADO users. But last night my bedroom TRV constantly recalibrated which created unbearable noise.
Thank you so much in advance. 
1 Like
@sben @dario2 @coldspark29 big thanks for your help. I’ve updated the v3 test version. Here is a small changelog:
- calibration triggers when external or current temperature of trv changes
- calibration service only gets called when the difference between external sensor temperature and current TRV temperature is greater/less than a specified delta (you can adjust this now in blueprint settings (default: 0.5 °C))
- service calls for mode or temperature can be split (tweak option in blueprint settings (default = off - mode and temp set in one call))
- service calls only get fired when temperature and/or mode changed and differs to current TRV settings
3 Likes
Will test once I’m home. Lots of love and thanks!
1 Like
Me again! First test very promising! Via the delta setting I can significantly reduce the number of calibrations!
I will monitor and report further details tomorrow.
1 Like
I had a play with this the other day, to control my Split system AC/Heat Pump.
I loved it, except for the fact I couldn’t get it to actually send the off command to the heat pump when the schedule was off, it would only set the minimum temperature. Any idea what I might have done wrong?
I’m using a IR blaster linked to a climate entity, that definitely has the ‘off’ option under HVAC options.
The call before was 10 minutes before. Did you identify the problem by now?
Tado support is really useless. They ask me for a bunch of photos of the thermostat. I really hate the attitude of this company. They treat their customers like they are idiots instead of communicating properly.
For now the blueprint is designed to hold a minimum temperature if scheduler is off. But if requested I would add a tweak option into the blueprint settings to turn climates off instead of lowering the temperature. I would add this to the v3 test version. I think it’s pretty stable now and so I can going to release it these days.
The problem is firmware related. (🔥 Advanced Heating Control - #219 by dario2)
But with the v3 version of this blueprint you can reduce calibrating significantly.
That would be amazing if you could add that feature please.
I absolutely love everything else about this blueprint, it’s exactly what I’ve been looking for, great job on it!
1 Like