🔥 Advanced Heating Control

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. :frowning:

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:

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

sorry for stealing the question, but how do you get that nice ui for schedules? :o

Finally found the issue. Just reimport the blueprint.

1 Like

wow nice, thank you so much :slight_smile:

thats the scheduler card, you can find in hacs

Unfortunately, they won’t work together. Scheduler cards and AHC.

Since upgrading from 5.2.10 to 5.2.15, calibration does not work any more. Log fills with error entries like this:

2025-01-22 05:09:25.581 ERROR (MainThread) [blueprints.panhans.heatingcontrol] AHC - Calibration - FZ: Thermostat Steuerung 
Jan 22 05:09:25 server homeassistant[2819821]:  calibration data set: {'number.fz_thermostat_external_temperature_input': [{'value': 19.4, 'valve': 'climate.fz_thermostat'}]}
Jan 22 05:09:25 server homeassistant[2819821]: 2025-01-22 05:09:25.584 ERROR (MainThread) [blueprints.panhans.heatingcontrol] AHC - Calibration - FZ: Thermostat Steuerung 
Jan 22 05:09:25 server homeassistant[2819821]:  calibration entity: number.fz_thermostat_external_temperature_input 
Jan 22 05:09:25 server homeassistant[2819821]:  offset: 19.4

The value (19.4 in this case) has nothing to do with value reported from the external temperature sensor, I don’t know where it comes from.
This is with Aqara SRTS-A01 sensors. I use the number.*_external_temperature_input for calibration, and this has worked until now.