was there any update on this? Or still a HA bug?
1 Like
Great blueprint, works like a charm for my central heating system. But i also want to use this template to control my daikin ac. Is there a way to program that under 19° it will heat and above 24° it will cool?
Hi,
i seem to have one problem fixed.
I deactivated my BT and also realized that i was running a ancient Zigbee2MQTT COntainer on docker. I did upgrade the system to 2.0.0.1 and it is running now. I havent had a shutdown issue since then.
But now i have an temperature issue. When i leave the room and the temps go down they sink lower then they should. I have a external room sensor tefined, so the temperature in the room should be calibrated on that one, right? Instead it looks like that:
It looks like it its calibrating the room temperature on the thermostats temperature sensor (16,9°C).
That was my trace:
https://controlc.com/8d3db55b
What am i doing wrong?
Unfortunately this is a dead link. 
Did you disable the whole BT integration or just for specific thermostat?
Unfortunately I didn’t have time to take care of it. Also I did not created an issue in the github.
No not possible atm. Do you mean the outside temperature with the values?
Yes or even inside temperature from a room temperature sensor. If i can make a future request, this will be it.
I have developed a flow in NodeRED that does that, maintains inside dew point comfort levels based on outside and indoor dew point.
I am just at version 4 at the moment and it is holding quite steady, while being power efficient. Version 5 will be uploaded soon.
Apologies not meaning to the hi-jack thread. Dew point control is a tighter way to handle indoor comfort.
I use Daikin with TADO.
Here are the Trace Links (last 5):
https://controlc.com/8b7e53cc
https://controlc.com/0e22ed87
https://controlc.com/ca0475f9
https://controlc.com/f0b8c7ea
https://controlc.com/b21d3193
I only deactivated the specific BT. I have the same thermostat in my livingroom and it works there (BT climate entitie as thermostat in the AHC Blueprint).
I could try doing the same thing in my office… but shouldnt it work anyway without the BT? i dont thing BT is causing isuues with the office thermostat eather when it is deactivated…
That would be cool, the only issue, that I have with that component, is that I currently see no option to alter the entity, that is used to evaluate weekday and weekend. Currently with AHC, I have created my own workday sensor and use it as a switcher to select one of two schedules. Like it is described in your blueprint and that is working very good.
Awesome. Yes I did a update/reimport.
The correct calibration keyword does the job. The error message is gone.
But I have some other issues to figure out… for example: the valve is fully open despite an open window. 
Could you update to the latest version first like described in the troubleshooting section? I don’t know what version you’re using but there are some variables missing. Also try to reset the calibration entities of your thermostats manually to zero.
A user here also reported that calibration won’t work after he cloned the automation, did you?
But I think the switch of the schedule integration does not represent the state if something is scheduled but the schedule entity itself. So it needs a binary input, e.g. a presence entity and the temperature inputs. This could be set by the custom schedule integration easily.
Have a look into the troubleshooting section in the first post, please.
I have a question on the ECO and Comfort Temperature settings.
I’m using a helper for both temperatures.
Every once in a while the Eco temperature is dropping from 18 degrees to 17 degrees without interaction from my side.
What could cause that?
I have checked trough the blueprint settings but can’t find any explanation…
alias: Wohnzimmer 🔥 Advanced Heating Control V5
description: ""
use_blueprint:
path: panhans/advanced_heating_control.yaml
input:
input_trvs:
- climate.jurgen_wohnzimmer
input_temperature_sensor: sensor.jurgen_temperatursensor_wohnzimmer_temperature
input_windows:
- binary_sensor.jurgen_tur_wohnzimmer
- binary_sensor.jurgen_haustur_turkontakt
input_window_open_temperature: 15
input_valve_positioning_mode: pessimistic
input_mode_party: []
input_persons:
- person.angie
- person.jurgen
input_mode_room_temperature: false
input_mode_outside_temperature_threshold: 16
input_temperature_comfort: input_number.comfort_temperature_wohnzimmer
input_schedulers:
- schedule.heizung_wohnzimmer
input_calibration_generic: false
input_frost_protection_temp: 8
input_mode_outside_temperature: sensor.aussentemperatur_temperature
input_temperature_eco: input_number.eco_temperature_wohnzimmer
input_mode_room_temperature_threshold: 22
input_valve_positioning_timeout:
hours: 0
minutes: 10
seconds: 0
input_physical_change: true
input_party_legacy_restore: true
input_reset_temperature: false
input_window_legacy_restore: true
input_temperature_eco_static: 0
input_temperature_comfort_static: 0
input_valve_opening_keyword: _heating
input_fully_open_difference: 1
Is your input number also set to this value? Could you let run the automation into that issue and take a trace log of this situation. (see troubleshooting in the first post)
I habe two options, to use the Scheduler component:
- create a schedule and select, that I want to control a thermostat
- create a schedule and select, that I want to control a binary_sensor for instance
If I choose a thermostat entity, I can set a timeslot and a temperature:
The switch represents the state of the heating. If you only change the temperature from time slot to time slot, the switch will never turn off.
More information to the temperature, the controlled entities and so on, can be seen in the attributes of the switch:
If you add a schedule for a binary_sensor for instance, you can only turn it Off or On. The scheduler component also creates a switch, with a similar structure:
However, from my perspective, it makes no sense to create a binary_sensor only, because you want to create a schedule with that component.
I am very interested in your opinion, because I could control and set the thermostat and its temperature and On/Off, but to control Windows, Presence Detection, and so on, your blueprint is just gold!
By the way, I solved the workday topic, by creating a daily schedule and added a condition, that the schedule is only active, if my custom workday sensor is true. Yeah!
Schedule for triggering an input boolean, e.g. presence sensor (I could add a more comfortable selector, but this should work as well.):
And just add input numbers to another schedule for the temperatures (comfort or eco):
I guess, that I just want to have the usability of the scheduler card for the regular schedule helper.
Your post shows a very flexible way, to handle different temperatures for comfort or Eco, but that is too much for me. Unfortunately I can not see to alter a schedule helper with a script, like a schedule.edit, that would write the information from the schedule component into a schedule helper.
for the same usage I set up :
- value change of eco via scheduler (same as 2nd screenshot)
- I run the blueprint every 5min instead of additional scheduler to trigger „presence sensor“.
this way I maintain only 1 scheduler.
it is very comfortable but I am not sure if that is bad for the rest (generic calibration for example)
So my question is : is it good practice to force the run the blueprint every 5 min ?
I am trying to figure out transition from summer to winter and the other way around. I have a multi split air conditioner, which means they can either heat or cool. The climate entity provides off, heat and cool.
First I thought, I could put this automation twice per room, once with winter mode, and once with reversed winter mode, put eco and comfort temperature into a helper and then controlled it by setting my winter mode helper accordingly.
Unfortunately that does not work, as the automation currently on winter mode switching off the thermostat, not letting the summer mode claim it.
What are the best practices for separating summer / winter? Also, I can under no circumstance use auto, because requesting heat and cool from the same outside unit might damage it (sic!). I am looking for a solution my wife can easily use (a toggle) when I am away…
Edit: Also, a window/door open temperature other than 0 seems to be preventing the climate entity from being turned off when winter mode is used and off.
Hi. I’m new here.
I have got only one schedule yet. Can I set custom comfort temperature in a timeslot like giving extra data or the only way I can do this is Adjustments / Heating Plan?
For example the light:
friday:
- from: "07:00:00"
to: "10:00:00"
data:
brightness: 80
color_temp: 3000
1 Like
Yes, atm you have to create 2 automations like you did but you have to add a custom condition where you check weather the winter mode entity is on or off (depending on your automation) to make prevent the automation turns off the climates.
I think I won’t add a toggle mode to the blueprint since the needs differ between cooling and heating. But I could add another selector for blocking those actions like turning off. So the automation won’t change anything.
Yes, thats the idea. Some users wanted just lowering the temperature to save battery or one user needs a minimal temperature to prevent pipe freezing. (He comes from a very cold area.)
If you want the climates turn to turn off when windows are open just set the window open temperature to 0.
Yes, just use the heating plan feature. Have a look into the examples in the description. You can also set the comfort temperature entity with help of another automation.
1 Like
Hi,
I noticed that now that I’m using zones (work and home) as well as the input_number it goes down to the lowest allowed in the variable.
INcldued the trace:
VB adv heating - Pastebin.com