Usually the fallback to the static temps only happen when a schedule or a presence change happens, lets say when a switch from comfort to eco happens, when windows are open. Could this be the case?
Hello @panhans,
Thanks for this great Blueprint!!
I need a little help, how can i do this?
Home + presence : comfort
Home + not presence: eco
Not Home: Off
Thanks.
Nobody can help a little ?
You need one automation (ie blueprint) for each room you want to control. I have 7 rooms I want to control the heating in, so I went through the blueprint 7 times adding the relevant trvs etc then naming it as heating control for that room.
Sure.
I’m sorry but I’m still totally unable to get presence to work. It definitely is an user error but I can’t trouble shoot it.
The motion sensor group is on. There is a person home as well.
The motion sensor schedule is on.
The heating schedule is off.
I don’t get it 
And the away part:
I want away only o happen if no one is home and no motion is detected.
When motion is detected I want comfort to be set.
Same goes for when the normal heating schedule (so not motion) is on and someone is home. It should jump to comfort till the heating schedule goes off and motion schedule kicks in (wotj someone home) then it should go to eco
Motion sensors are unlike presence sensors and its higly recommended to b
Oh, I think this needs another tweak. Will implement this these days.
This is not part of the blueprint but can be solved with a template sensor:
- platform: template
switches:
boiler:
value_template: >
{% set climates = ['climate.TADO_THERMOSTAT_1',
'climate.TADO_THERMOSTAT_2',
'climate.TADO_THERMOSTAT_N'] %}
{% set climates_heating = climates | expand | selectattr('state','in',['heat','auto']) | map(attribute='entity_id') | list %}
{% set heat = climates_heating | count > 0 %}
{% set result = namespace(r=none) %}
{% for climate in climates_heating %}
{% if result.r == none %}
{% set result.r = state_attr(climate,'temperature') > state_attr(climate,'current_temperature') %}
{% else %}
{% set result.r = result.r or state_attr(climate,'temperature') > state_attr(climate,'current_temperature') %}
{% endif %}
{% endfor %}
{{ heat and result.r }}
turn_on:
service: switch.turn_on
target:
entity_id: switch.YOUR_HEATER
turn_off:
service: switch.turn_off
target:
entity_id: switch.YOUR_HEATER
Just edit you climates / thermostat in the first part. Maybe you need to expand the array and set your heater entity id in the lower part. The template sensor checks your thermostat if they are heating and if the target temperature is higher than the current temperature. If this is the case the heater turns on, if not it will be turned off.
But wait? How is the nest thermostat integrated? Is this a climate entity, too?
Could you share a screenshot of the history of your presence sensor? Mostly motion sensors needs to be debounced and wrapped by a template sensor. They have too much disadvantage compared to real presence mmwave sensors, e.g.:
- reset to off after a certain duration
- only detect motion but not seated or lying persons
1 Like
removed the blueprint and started from scratch - applying the v5 must have messed it up.
Schedules are working but the Schedule selector (an input selector with exact matching entries to the schedules) doesn’t. If I deselect that and then set a single schedule all works ok, including adjustments again.
So just appears to be an issue with the schedule selector.
Attached is the trace from the 11:00am trigger (i.e. when the set schedule, "Summer Schedule’ should have triggered).
The presence sensor is a mm waved and pir based group. So there is quite some de bouncing happening. Presence can be on for hours indeed.
I looked this morning again.
It stays at away temp even during the heating scedhule is on and motion scedhule is off. I can’t get it to work then.
@ajb538
You have no schedules specified. Just the selector.
@victoroos
Just share your durations for your presence sensors and the history graph. Presence works flawlessly so it must be a configuration problem.
Okay. O noticed it has to do with away being on.
When I ze away to on for presence based heating, it stays at away temp. Even when when the normal schedule is on.
Presence 
As you can see it needs to be debounces. the sensor switches from on and off too often. The yellow parts in the graph should be solid without any spacing between. When using z2m some device have an option for this if not you have to fix this by e.g. wrapping it with a template sensor and some logic
Ah Okey,
I’ll work on that. Thank you ^^.! Template sensors are still scary for me but I’ll try.
Could you next to that help with the away temp vs eco temp when no person is home?
I just noticed a scene with “window” added at the end of the name was created, for one of the three rooms where i have set window sensors. not sure when, is this done automatically by your blueprint? It has never activated, and only created for this one room while i have more rooms with window sensors. Is this a left over from an old version?
I’m starting to go crazy here 
(and the wife acceptance levels are reaching critical levels…)
I have a schedule set for the office-room, it should only turn on during the weekdays. But for some reasons today, Sunday, it is constantly turning on randomly. I have a presence sensor there as well, it looks like it’s reacting to some ghosts and detecting movement all the time. But even so why is it turning on my heating even though my schedule is set for only weekdays
The scenes will get destroyed with every home assistant restart. Could you share a trace log of your office room? (Would be great if you hit the point when comfort is set by the ghost detection)
I have also a problem with the input_scheduler_selector and AHC v5.
Everyday at 00.00 my holiday selector gets active by accidental, the eco temp will be set to 15C° and override everything else. I can’t remember that this was an issue with v4.
My config:
alias: Heizung Bad
description: ""
use_blueprint:
path: panhans/advanced_heating_control.yaml
input:
input_trvs:
- climate.thermo_bad
input_temperature_sensor: sensor.meter_d755_bad_temp
input_temperature_eco: input_number.bad_eco_temp_eingabe
input_temperature_comfort_static: 20
input_temperature_eco_static: 18
input_temperature_comfort: input_number.bad_komfort_temp_eingabe
input_adjustments:
- time: "09:00"
days:
- Mon
- Tue
- Wed
- Thu
- Fri
comfort: "20.0"
calibration: "on"
- time: "10:00"
days:
- Sat
- Sun
comfort: "20.0"
calibration: "on"
- time: "20:00"
days:
- Mon
- Tue
- Wed
- Thu
- Fri
- Sat
- Sun
eco: "18"
calibration: "on"
- time: "00:00"
days:
- Mon
- Tue
- Wed
- Thu
- Fri
- Sat
- Sun
scheduler: schedule.24_7_urlaub
eco: "15"
calibration: "on"
input_off_if_above_room_temperature: false
input_schedulers:
- schedule.heizung_bad_komfort_temp
- schedule.24_7_urlaub
input_scheduler_selector: input_boolean.heizungs_urlaubs_temperatur
input_windows:
- binary_sensor.fensterkontakt_bad_contact
input_windows_reaction_time_open:
hours: 0
minutes: 0
seconds: 20
input_windows_reaction_time_close:
hours: 0
minutes: 0
seconds: 5
input_calibration_timeout:
hours: 0
minutes: 1
seconds: 0
input_calibration_delta: 0.2
input_aggressive_mode_range: 0.1
input_aggressive_mode_offset: 0.5
input_aggressive_mode_calibration: true
input_mode_winter: input_boolean.heizung_automation_an_aus
input_mode_outside_temperature: sensor.berlin_tempelhof_temperatur
input_mode_outside_temperature_threshold: 19
input_hvac_mode: auto
I wrote the v5 config from scratch. Maybe something needs to be changed?
Are you on the latest version because I made some changes to the adjustments a few days ago?
I use 5.09 version. i will check if there is a new one.
Edit: Thanks for the hint. I will update to 5.1.2 . Hopefully you have fix it already
1 Like
@panhans aha! This may be the problem, I incorrectly assumed if a selector was defined you didnt need to enter the schedule entities also, as they are defined in the input selector.
Makes sense! Trying again…
1 Like
Ah thanks. It was the schedule. Somehow I played with it and forgot to deactivate it
1 Like