šŸ”„ Advanced Heating Control

"input_mode_outside_temperature": "sensor.temp_carport_temperature",
"input_mode_outside_temperature_threshold": 21,
"state_outside_temp": false,
"state_ahc": false

It seems your outside temperature sensor is not ready and does not report a valid value so the automation is set to off. Is this a zigbee sensor (zha)?

//EDIT: I could add a delay for all automation calls after a restart. Would be nice if there is an event when ha is fully loaded. I will do some researchā€¦

1 Like

Nice!!! Thanks

hi,
that would be nice.
Itā€™s zigbee sensor.
which is connect with zigbee2mqtt.
the addon needs some seconds to start.
thanks and regards

For zigbee2mqtt make sure to enable the state cache, else the values will be invalid after a normal HA startup until the sensor updates.

But I have also seen similar behaviour after a complete restart of the host OS, where the automation will send a seemingly random number as external temperature to the thermostat.
Tested it like an hour ago and the temperature was set to 19.9C instead of the actual 20.4C. There is no other temperature anywhere that would be close to this.
Did not save traces unfortunately and of course for the last couple of restarts it now behaves normally :man_shrugging:
For now I just assume it is some persistence weirdness somewhere in z2m.

2 Likes

Hi,
the cache status is already activated.
I have now created an automation that enables and disables the winter mode with a 2 minute delay after ha start.
This triggers all heat control automations.

alias: heat_control_after_restart
description: ""
triggers:
  - trigger: homeassistant
    event: start
conditions: []
actions:
  - if:
      - condition: state
        entity_id: input_boolean.heat_control_wintermode
        state: "off"
    then:
      - delay:
          hours: 0
          minutes: 2
          seconds: 0
          milliseconds: 0
      - action: input_boolean.turn_on
        metadata: {}
        data: {}
        target:
          entity_id: input_boolean.heat_control_wintermode
      - delay:
          hours: 0
          minutes: 1
          seconds: 0
          milliseconds: 0
      - action: input_boolean.turn_off
        metadata: {}
        data: {}
        target:
          entity_id: input_boolean.heat_control_wintermode
mode: single


this morning similar things happened in another room.
I checked the trace log and noticed that for some reason the input_number eco temp gets set to a HIGHER number (from 15 to 19) than the static eco temp(15). and thats why the TRV gets turned on. My mistake was to use one eco-entity for all versions of the blueprint for every room. so i hope giving each room their own entity will fix my issues.
Can you give some insight as to why the automation decides to higher the ECO temp sometimes?

Update - Version: 5.1.4

ADD: custom condition for calibration
ADD: delay option for home assistant start
ADD: trigger if climate gets available again

@qwert1 @david.jirovec @P6Dave

@mauritsivs
The eco temperature entity could be changed by heating adjustments only. But is it the target temperature of your climates or the eco temperature entity? Did you enabled physical change / sync?

3 Likes

@panhans
Thanks, after a couple of days off, I finally found the right setting.

set level = 0.37 %
set inclination = 0.7 %

I tried to continue myself but unfortunately Iā€™m, by far, not having the right competence. So I kindly ask you to add the climates as mentioned.

Thank you

it was the eco temp entity, and i have physical change enabled as well.
The heating of another room that used the same eco temp entity was turned on manually, so it reacted to that in the second room also because it changed to 19, wich was higher than the room temperature at that moment. Just not sure why it would set the eco temp to 19 in the room that was turned on manually. But i guess that has to do with some calibration?

Just setup a template sensor in the helper section and paste this code. Edit your outside temperature sensor and your climates.

Your climates will be filtered by the hvac mode heat or auto and the highest target temperature gets selected for the formula.

{% set outside_temp_sensor = 'sensor.OUTSIDE_TEMP_SENSOR' %}
{% set climates = ['climate.THERMOSTAT_1',
                    'climate.THERMOSTAT_2',
                   'climate.THERMOSTAT_N'] %}

{% set level = 0.37 %}
{% set inclination = 0.7 %}

{% set highest_target_temp = climates | expand 
            | selectattr('state','in',['heat','auto']) 
            | map(attribute='attributes.temperature') 
            | sort(reverse=true) 
            | first | default(0) %}

{% set t_room_target = highest_target_temp | float %}
{% set t_outside = states(outside_temp_sensor) | float %}
{% set dar = t_outside - t_room_target | float %}

{{ (t_room_target + inclination - (level * dar * (1.4347 + float(0.021) * dar + float(247.9) * float(10**-6) * dar**2))) | int }}

Only if youā€™ve enabled generic calibration or if youā€™re using aggressive mode.

Yeap, 5.12 fixes the issue with input_scheduler_selector.
Thanks a lot.

1 Like

wow, thank you so much! :slight_smile:

1 Like

Thank you :fist_right:

1 Like

Thank you :slight_smile:

1 Like

Iā€™ve looking into ā€œsmartā€ ways to deal with 10 thermostats over 3 floors and 3 peopleā€¦I was using shedy app for the last 2 years and discovered this blueprint and now testingā€¦

How would you suggest me to deploy this blueprint?

  • I have temp sensors + thermostats
  • I use presence detection
  • II use a wood stove sometimes in the winter to help heatā€¦ Anyway to compensate for this with heating metrics?
  • Under high demands, my electricity provider dives me rebates if I use less energy as usual and would like to exploit this by making sure I heat more within specific schedule (like 3-9am or 16-19h) without disrupting comfortā€¦ Like postponing heating in those hours if It can.

I would like to make sure they all ā€œheat togetherā€ if it makes senseā€¦

Is there anyway to stop heating to target a temperature at a certain time, like sleep time?

Regards,

Hi,
I updated now to version 5.1.4 and configured a startup delay of 5 minutes in the automation.
Now the temperature is not changing at all.
It looks like the automation is waiting forever.
I removed the delay now the automation is changing the temperature.

trace

snip1

Wow panhans, what an extensive blueprint! Looks great, Iā€™m testing with this now instead of the ā€œdumbā€ schedule I used that was made on my Daikin integration.

Do I understand it correctly if I say the input_mode_guest setting makes the automation ignore the person=home condition? But does this also ignore the input_scheduler_presence: schedule.xxx I set up? Because even in ā€œguest modeā€ there is no reason to heat up the room in the middle of the night because the dog is triggering the occupancy sensor.

Same goes for my wife is in bed, so person state=home, but the AC (used for additional heating because she is always coldā€¦) should not turn on when my kids stay up late. No need to have the aircon on. Is this also the behaviour when I set up the schedule to stop at 22:30?

And I set the presence time-out to 20min because the occupancy sensor is PIR and not radar, does the aicon automatically switch off at the end of the schedule directly, or does it wait for the occupancy to be gone for >20m as well?

My setup config is here

@panhans: for me it was the same, i set the delay to 30 sec and 2 of 5 automation didnā€™t react to anything! After setting the delay to 0 everything worked fine!

@qwert1 @tco95ttocs

Yes, Iā€™d doubled the time in order to keep the action calls in the correct sequence. With the latest version the automation will be called after the delay duration is over. But I wouldnā€™t recommend to set the delay to e.g. 5min. Maybe 30s to max 1min. Note that in this time nothing works like window detection ect. and if the automation que is full other calls will be rejected.

//EDIT: but maybe there is still an issue :wink:

No, the guest entity acts like a person. If on the automation handles it like anybody is home.

If you combine presence with persons and you donā€™t want comfort for a specific time window, just go with a presence schedule to whitelist the periods of time where presence detection shall be used.

Maybe I get this wrong. You should have an indicator when your wife is not in bed. (Maybe a pressure sensor under her mat :P) This indicator can be used as a presence sensor for the AC. Also donā€™t forget to whitelist this sensor for the evening.

Yes. The presence sensor must stay off for 20min before eco kicks in.

Hello panhans,

here is the Trace Log from today:

Durch binary_sensor.esszimmer_aktivitat via template am 13. Dezember 2024 um 08:20:38 ausgelƶst

Wenn irgendeine von 4 Bedingungen erfĆ¼llt ist., dann fahre fort

Gestoppt, weil eine Bedingung am 13. Dezember 2024 um 08:20:38 fehlgeschlagen ist (Laufzeit: 0.04 Sekunden)

Durch binary_sensor.wohnzimmer_aktivitat via template am 13. Dezember 2024 um 13:49:14 ausgelƶst
Wenn irgendeine von 4 Bedingungen erfĆ¼llt ist., dann fahre fort

Gestoppt, weil eine Bedingung am 13. Dezember 2024 um 13:49:14fehlgeschlagen ist (Laufzeit: 0.04 Sekunden)

Mƶglicherweise beziehen sich nicht alle angezeigten LogbucheintrƤge auf diese Automatisierung.

The sensor goes on which is detected successfully.
But it talks about a condition that is not met,
I have as a condition on time 1 minute and off time 5 minutes. But even after the said minute, the temperature is not changed.

At the moment in another room with same problem (Tracelog above ā€œWohnzimmerā€").
The problem doesnā€™t always occur.
I really donā€™t know where the problem is.

Thanks dude