@panhans I think the Winter Mode and the weather Mode are different Things.
Winter Mode is a General Heating Option, and the weather Mode should be only Heat when the Winter Mode is on and the outside temp is Low.
I dont wanna lose my “General” Heat selector, weather is for me a seperaten option next Winter mode
1 Like
Is there an easy way to convert this to Fahrenheit?
1 Like
I’ll see if this is easy to implement. If so, I will adjust the blueprint selectors and add a toggle to change the unit.
1 Like
Hi, here is another Feature request.
Is it possible to add Days in the Comfort Heating Plan ?
so that I can distinguish between working days and weekends?
Hi there! I’m also interested in this! love this Tado feature and would love to retain it in this blueprint!
1 Like
Hi! I’ve been browsing this thread for a while but couldn’t find the instructions to access the beta. Could you possibly point me in the right direction?
thanks!
1 Like
Hi panhans,
It is impressive what you have achieved, thanks for sharing this with the community. Hats off!!
I yesterday set up the corresponding presence, zones and proximity sensor in preparation for testing this blueprint. My idea is to try and adopt it when version 4 is released as I want to have multiple comfort temperatures across the day. I plan to play around with one TRV and the beta version and contribute to v4 release with my feedback, if I find anything during my testing.
I’m also interested in understanding how you plan to leverage proximity. Could you share here how do you plan to use that sensor? This can definitely be a game changer in terms of experience and savings.
Thanks you!!
1 Like
Hello, thank you very much for this great blueprint. I use this with an AC system from Daikin via Tado.
I use several window sensors. When the windows are opened and the heating is activated (scheduler or presence), the heating is switched off depending on the configured time: Correct.
However, if I open the windows when the heating is not active - i.e. no scheduler or presence has not been active long enough to activate the heating - the heating is still activated when the windows are closed.
I hope I have described this clearly. Is this an intended behavior or am I doing something wrong?
Another small point: Every time the automation is changed, the heating is activated by the “automation.reload” service when it is saved. Strange 
Many thanks for your help!
1 Like
Just have a look in the first post of this thread → Become a tester
I think this will be a little experiment. I will add two modifiers to adjust the distance and direction of a person and if everything matches including scheduler state, heating will be enabled.
Heating is always active but thats only the manual mode of the valves. Just the temperatures change. If your room has a temperatrue of 20 °C and your valve is set to heat and target temperature 17°C that doesn’t mean that the valve is open.
So if you want the valve is completely off there is an option for this in settings:
1 Like
Thank you very much for your quick reply. I have indeed activated this option, as otherwise the system would always run through.
This probably has to do with the different logic of controlling an AC system. My “regular” Tado devices work exactly as intended.
1 Like
So, your issue still exists? If yes a trace log would be great. Just have a look in the first post there is a way described how to share it.
Tested → works fine in my test environment. Are you on alpha10 if yes could you share a trace log? 
Hello, I have just tested it again:
- Scheduler: Off
- Presence (since not yet 15 minutes in the room): Off
Expectation:
After closing the window, the heating should not be activated. However, it was reactivated immediately after closing.
The heating should only be reactivated if the conditions are met. An offset after closing the window would be great (currently I can only set an offset for opening and closing) but this would just be the icing on the cake.
Here is the trace. I hope I’ve got the right one. Many thanks for your help and a happy new year!
If it was a snake, it would have bit me… pffff
I scanned through a number of posts, and kept seeing references to the beta bluerpint, but couln’t find a pointer. Thank you!
I’ve cloned the beta blueprint and I have set it up the best way my judgment suggested, but I’m not sure I understand how a few features work. I wonder if you are already working on v4 documentation that I can check. Specifically, I want to understand this:
- Comfort Heating Plan: I understand this scheduler is what will change the confort temperature through the day. The hint suggests an input_number is needed, yet the cue on the right hand side looks like a plain text canvas.
How are we supposed to interact with the heating plan from the frontend if it is a plain text canvas?
I already created 2 input_number are represented as sliders on the frontend, that I can use to define the minimum and confort temperatures. I don’t know if these 2 input numbers (or more probably the confort input number) are pre-requisites for the Confort Plan to work.
Maybe this is not yet developed (as it is a WIP). If that is the case, please consider this as feedback. I think it would be very useful if a method would be implemented that allows defining a heating plan from the frontend. - I created three schedules in the helper section and created a text input, and ensured the naming convention matches the name of the schedule. Is there anyway I can confirm my automation is actually seeing the schedule that I defined?
- What is the difference between
Force Max TemperatureandParty mode? Guest modestill relies on schedules, right? If I have a babysitter at home and enable the corresponding boolean, heating will not be active unless the schedule tells the heating system to kick in, right?- If I have a
Scheduler Selectorin place it overrides the so calledScheduler (optional)?Scheduler (optional)looks like a simplified version of theScheduler Selector, right? - Any tip on a nice front-end that already has all the inputs that your integration uses? This is what my front-end now looks like after implementing the few elements that I believe I need to use, but I’m sure there are already better developed cards than my mundane buttons
One last question: If I went all-in with your blueprint, would I will depend on Tado Cloud or in case Tado Cloud was down, the automation that I build thanks to cloning your blueprint would give me independence from their cloud?
THANKS A MILLION for such an awesome work! It is truly inspiring and engaging.
PS: I hope you enjoy the coffee I sent your way
Thanks! I wish a happy new year, too. Here is a part of your trace:
"is_person_based": true,
"is_anybody_home": true,
"is_presence_sensor_defined": true,
"is_presence_scheduler_defined": false,
"state_presence_sensor": true,
You configured persons combined with a presence sensor. So if somebody is home and presence is detected heating is on. You didn’t setup a scheduler for presence detection.
In your case presence is detected so heating is turned on.
Atm there is no documentation for v4 but I will add everything to existing one when v4 leaves alpha state. That means when every planed feature is implemented.
I think I will rename this. Indeed it seems like it is plaintext, but it will be parsed as an dictionary an internal jinja object that stores some values.
I want to include some more modifiers here and it also should work without an additional entity.
But the schedulers or other conditions only toggle between two temperatures or lets say modes: minimal and comfort heating. I’d like to plan everything so no input is needed.
Yes, you can check the logs or you can define an custom action to get access to some variables. In your case active_scheduler. If you like you can store the value in a text input.
Party mode enables heating no matter if other condition match. Winter mode, if defined, must be enabled and temperature will be set to comfort temperature.
Force Max Temperature will also work if automation is disabled, e.g. winter mode is off. The valves will set to the maximum values. I need this when my boiler needs service to prevent heat build-up and this is mostly in summer.
Exactly!
Scheduler (optional): Here you define all the different schedulers you want to use. But here is no possibility to set the active one.
Scheduler Selector: You need this if you want to switch between your defined schedulers. If you don’t use a selector the first defined scheduler is always the active one.
Some others here have some nice combinations of ha card elements. (Just have a look some posts before) But I only have a custom button card. That only shows state of heating, a party timer and the comfort temperature. I personally stay very basic.
I can’t tell. This blueprint is very generic and works with default entities of home assistant. The only special about tado is it’s valve calibration. But I am also looking forward to implement some special characteristics if I can.
Many many thanks for the coffee and your support! I really really appreciate it!
I use the implementation via the HomeKit Device integration instead of the Tado Cloud. This means everything is local and thanks to the great blueprint, the presence detection etc. still works.
Many thanks for your analysis and support!
1 Like
What I have noticed when going via HomeKit to keep local control is that calibration with an external temperature sensor doesn’t work. This is probably expected and is not a limitation of the Blueprint more the way Tado calibration works.