šŸ”„ Advanced Heating Control

You can define a time window with a presence scheduler if presence detection is to be active.
As long as the scheduler is not changed and presence detection is ignored, you can set your thermostat as you wish. The automation should only set changes again when the scheduler changes status.
Alternatively, you can also set a custom condition. This can be, for example, a period of time when the automation is active or should be blocked.

Nice! I will try!! Thanks!! Great Blueprint!! :sunglasses:

1 Like

Question with regard to "Physical Temperature Change / Sync ":

Do I understand it correctly that with this option I can set the temperature by the TRV itself or thermostat card? How long the temperature is being set? At the moment, when I set it, only the comfort temperature is set by the option when it is enabled. It would be nice, if I can overwrite the desired temperature for a specific time frame until the automation kicks in or until the target temperature is reached. How can I do it?

1 Like

Hey, unfortunately the issue still persists. :cry:

This is my automation that somehow bugs around wirh the calibration


alias: šŸ”„ AHC Martin
description: ""
use_blueprint:
  path: panhans/advanced_heating_control.yaml
  input:
    input_trvs:
      - climate.heizung_martin
    input_temperature_sensor: sensor.zsensor_martin_temperatur_temperature
    input_temperature_eco_static: 17
    input_temperature_comfort_static: 21
    input_adjustments:
      - time: "05:00"
        comfort: "20"
        calibration: "on"
      - time: "09:00"
        calibration: "on"
      - time: "16:00"
        comfort: "18"
        calibration: "on"
      - time: "21:00"
        comfort: "18"
        calibration: "on"
    input_persons:
      - person.daniela
      - person.martin
    input_presence_sensor: binary_sensor.mmwave_presence_sensor_martin_belegung
    input_presence_reaction_on_time:
      hours: 0
      minutes: 0
      seconds: 10
    input_presence_reaction_off_time:
      hours: 0
      minutes: 5
      seconds: 0
    input_away_offset: 2
    input_away_presence_mode: false
    input_windows:
      - binary_sensor.fenster_martin
    input_liming_protection: true
    input_liming_in_winter: false
    input_mode_winter: input_boolean.sommer_winter
    input_mode_outside_temperature: sensor.gw2000a_outdoor_temperature
    input_mode_outside_temperature_threshold: 20
    input_generic_calibration_offset: 5

@fir3drag0n

If you disable this feature you can set the temperature you want. The temperature will get reset when scheduler / presence, ect. change its state next time. But there is no synchronization between them.

If you enable it, the temperature of the current mode (eco/comfort) will be changed. And all thermostats will be synced to that temperature. When enabling reset temperature the entities gets reset to the static temperature that are defined when presence, schedule, ect. ends / starts.

@Break
Could you check the lates version? I donā€™t know exactly what the Tado Offset consumes. The example on the docs is a little bit confusing. Is this an offset with a specific range, e.g. -6Ā° - +6Ā° or an absolute temperature? Are floating values allowed or just integers? Is there a max/min offset? That information would help a lot.

Maybe I find something here in the community board.

im now running 5.0.4b and it looks like its working. In general I can say it worked with V4 before.

Regarding your question with the offset value for taco, there is unforuantly no entity ore something similar that I can check to assist. sorry . The only thing a can tell you is that on the Tado app you can just the Offset from +10.9Ā° to -10.9Ā°.

But I have something in mind, that I already hat some similar issues a year ago where I started with our Automation.

@panhans sourcecode Link in First Post ist broken

Hey panhans,

I just set up version 5.0.3 of your blueprint, but Iā€™m seeing some strange behavior with the calibration. Iā€™m using Bosch thermostats, which worked fine in version 4, but now the automation seems a bit broken. The calibration oscillates across the whole range (10Ā°C), moving up and down.

It seems there might be an issue with the calculation of the difference between the thermostat and room temperatures. When the calibration offset is applied, the thermostat temperature is lowered accordingly, and if itā€™s checked again in short succession, it ends up overcompensating in the opposite direction. This repeats with each cycle. I suspect the oscillation is linked to my room temperature sensor, which reports new values every 2 seconds and provides fluctuating data when the room temperature cools by 0.1Ā°C.

It could be due to how frequently my temperature sensor triggers the automation, but this wasnā€™t an issue in version 4 using the same settings. Iā€™d be happy if you could look into that as I was excited to try out the new aggressive calibration mode. Thanks a lot!

Can you please add this features:

  • When outside temperature above turns off heating.
  • Add to comfort and eco also night temperature.
  • Add preheat schedule when no one is home but it is a usual time so you want warm house alredy when you come.

I know I can do that with another automations and I did that, but it will be simpler to just have it all in one. Thanks.

How I did that:

  • first one easy automation that turn the winter mode off
  • second I use eco as a night mode and have the main schedule set for it
  • thirdly automation turns on party mode based on schedule

Hi, can someone point me in the right direction?

I setup the automation, the schedule and the presence sensor and now Iā€™m here sitting in my room but the thermostat is off.

Hereā€™s my config.

and hereā€™s the log.

Thanks

Maybe a suggestion as ā€œfeature requestā€ if it is somehow not already implemented. With a schedule to activate specific modes. Example: 05:00-07:00, 21:00-23:00 comfort (and the rest eco).

@panhans

Testing your latest version now witch is amazing.
I have multiple thermostats in the automation.
Will it be possible in the future to select witch thermostat receive the generic calibration or aggressive mode?

1 Like

Thanks, that helped a lot. I will implement this as the limits.

I use the same calibration method like the Bosch. I will have a look into this. But would be helpful if you share your automation configuration in yaml. Could you also check if the keyword for selecting the calibration entity is correct? Some thermostats provide an entity for an absolut temperature value and an entity for an offset.

//EDIT: I did a small change to the latest version. The calculation is now the same like for Tado. Feel free to test and give some feedback.

Itā€™s already implemented.

Just use temperature adjustments and lower the eco temp for the night with that feature.

Thatā€™s why proximity support exist. If this doesnā€™t fit I could implement something to force comfort using the heating adjustments.

I would suggest to update to the latest stable version first. Please setup it from scatch because some selectors changed.

Good idea. I will put it on my list.

You just have to add a heating schedule.

I upgraded from version 4 to 5.0.3 last night. I have a room with 3 Tado TRVā€™s and a central temperature sensor. This morning I woke up to a quite warm room and realised that one of the 3 TRVā€™s received a very large calibration offset. It may be the same issue as Break and myriad is describing.

You can see one of the offsets starting to drift

SkƦrmbillede 2024-11-13 kl. 09.53.00

These are the current values from the TRVā€™s as well as the temperature sensor and the room temp sensor

The two TRVā€™s named ā€œalrumā€ are very close to to each other and should report more or less the same temperature

ā€¦and the automation:

Finally I tried turning on debugging on the blueprint but it doesnā€™t currently seem to update calibration values:

1 Like

Yes, the issue was reported yesterday and is (maybe) fixed. You can update to the latest version. Let me know if this fixes your problem.

hey panhans,

for now I can confirm that the TADO Calibration issue is fixed with version 5.0.4b.

1 Like

The heating schedule as I can see allows me to set temperature in the various presets, doesnā€™t look that I can select a preset like eco or comfort as it is.

Thanks @panhans for the v5 Version. Version 4 works great for me. Now i have problems with the v5 and input_mode_winter option. It will not trigger the automation. Here ist my test automation.

alias: Heizplan Badezimmer v5
description: ""
use_blueprint:
  path: panhans/advanced_heating_control.yaml
  input:
    input_trvs:
      - climate.badezimmer
    input_mode_winter: input_boolean.heating_automation_badezimmer

just check the example as provided in the Automation it should really fit your needs:

- time: "08:00"
  comfort: "20"
  calibration: "off"
- time: "16:00"
  eco: "19"
  calibration: "on"
- time: "20:00"
  days: ['Sat','Sun']
  scheduler: 'Holidays'
  comfort: "24"
  eco: "17"

@fumantsu
Do you want to select the internal presets of your thermostats? If yes, no thatā€™s not possible because not every thermostat supports this.

The blueprint works mainly with two temperatures (comfort and eco). And the schedule decides when comfort temperature will be set. Thatā€™s the case if you define the schedule to be on for a specific time window.

Yes, with this setup only calibration is active. Because there is no entity that toggles between eco and comfort. You can set your input_boolean.heating_automation_badezimmer for guest mode and presence, too. But then comfort is always set. Donā€™t know if this is what you want to archive.