is it possible that you rename the dev-version? Its still the same name as the stable version!
1 Like
I figured out, why the temps are done so confusing things like heating, when its off etc. It was, because i have 2 valves combined to one. I separate the two valves with its own automation and now it looks fine!
1 Like
Thank your for resolving this issue!
And pushed a change for the name of the dev version.
I just started to set up this blueprint migrating away from NodeRED to HA Automations. Somehow I seem to miss something. I do have 2 schedules one for working day, one for non working day. Since I run about 17 radiators almost each one with a different schedule I choose to have the generic schedules, an automation to switch the dropdown helper depending on a working and non working day and wanted to make the individual adjustments within the blueprint. So I did just always have both schedules set to run (one entry each day from 00:00 to 23:59) and put them both into the automation along with the selector. However I just noticed that all the adjustments are pretty much ignored. I want to change the comfort temperature based on the time and selected schedule but it totally ignores it and remains with the manual set comfort temperature and does not do anything.
What am I missing? Do I have to create a trigger event in the schedule for each possible change over all radiators? Or do I need a distinct schedule for each automation? I could not yet find the answer to this but just see, that all the automation intended to work based on times are not running at all.
I hope someone can enlighten me since I seem to be stuck understanding how it is intend to work coming from a slightly different approach I used within NodeRED.
Thanks in advance, I appreciate it!
Hi, thanks for your question.
Could you share your blueprint configuration or a trace log. If you share a trace log just follow these steps before downloading:
- navigatie to your blueprint settings
- scroll down and select debug level warning
- add a schedule adjustment for a next time
- save your automation
- wait until the time you configured
- download and share the trace log
Thanks
Thanks for the quick reply. I did adjust the schedule but again, nothing was triggered. Here’s my blueprint config to start with till I get a tracelog:
description: ""
use_blueprint:
path: panhans/heating_control.yaml
input:
input_trvs:
- climate.heizkorper_schlafzimmer_og
input_temperature_minimum_static: 15
input_persons:
- person.bianca
- person.christian
input_people_leaving_home_duration:
hours: 0
minutes: 5
seconds: 0
input_people_entering_home_duration:
hours: 0
minutes: 1
seconds: 0
input_proximity_distance: 5000
input_mode_winter: input_boolean.heizmodus
input_mode_outside_temperature: sensor.gw1100a_outdoor_temperature
input_mode_outside_temperature_threshold: 20
input_tweaks:
- reset_temperature
input_temperature_comfort_static: 22
input_time_based_temperature_change_valve_target:
- time: "08:15"
scheduler: Arbeitswoche
comfort: "17"
calibration: "off"
- time: "06:00"
days:
- Mon
- Tue
- Wed
- Thu
- Fri
scheduler: Arbeitswoche
comfort: "17"
calibration: "off"
- time: "20:00"
days:
- Sun
- Mon
- Tue
- Wed
- Thu
scheduler: Arbeitswoche
comfort: "22"
calibration: "off"
- time: "22:30"
days:
- Sun
- Mon
- Tue
- Wed
- Thu
scheduler: Arbeitswoche
comfort: "20"
calibration: "off"
- time: "00:30"
days:
- Sat
- Sun
scheduler: Arbeitswoche
comfort: "18"
calibration: "off"
- time: "10:00"
days:
- Sat
- Sun
scheduler: Arbeitswoche
comfort: "17"
calibration: "off"
- time: "21:30"
days:
- Fri
scheduler: Arbeitswoche
comfort: "22"
calibration: "off"
- time: "23:00"
days:
- Fri
scheduler: Arbeitswoche
comfort: "20"
calibration: "off"
- time: "00:30"
scheduler: Feiertag/Urlaub/Krankheit
comfort: "18"
calibration: "off"
- time: "10:00"
scheduler: Feiertag/Urlaub/Krankheit
comfort: "17"
calibration: "off"
- time: "21:30"
scheduler: Feiertag/Urlaub/Krankheit
comfort: "22"
calibration: "off"
- time: "23:00"
scheduler: Feiertag/Urlaub/Krankheit
comfort: "20"
calibration: "off"
input_temperature_comfort: input_number.schlafzimmer_og_manual_comfort_temperature
input_proximity: 89a390e651335751f50b7b10d4a81c0b
input_scheduler_selector: input_select.zeitplan_heizprofil
input_schedulers:
- schedule.arbeitswoche
- schedule.feiertag_urlaub_krankheit
input_service_call_delay:
hours: 0
minutes: 0
seconds: 5
input_log_level: warning
Thanks. 
Question: Instead of one entry in the schedule, do I need to put another one each half an our to have the automation check and adjust to the manual schedule adjustments? I’m totally new to the HA automation. In NR I was able to just check for any time of the payload but here it seems that if the manual adjustment times do not meet a single event start time in the schedule nothing gets triggered? Or do I even need a separate schedule for each automation?
No, that’s not necessary. Simply define the heating periods in a single part. The adjustments triggered by time you defined when the current timestamp HH:MM matches a time attribute of an entry.
To your problem: Indeed there was a bug when comparing the schedule name. Instead of comparing the friendly name the entity_id was taken.
I pushed a fix for this in the DEV version. So if you want to test this, just import the DEV-Version (have a look into the initial post). Open your automation.yaml in an editor. Edit the path of your automation from path: panhans/heating_control.yaml to path: panhans/heating_control_dev.yaml and reload the automations e.g. in developer tools.
I will merge the DEV version to stable branch soon. Since it contains a lot of bug fixes.
1 Like
One additional vote from me for the calendar integration. This would definetly improve the acceptance in my household 
The even bigger issue is the handling of physical changes on the thermostat. Lets hope this bug gets fixed soon.
@panhans : thank you so much for your hard work and this awesome plugin!
1 Like
AHC4.0.4
Just some fixes:
- revised logic for setting target temperature
- fix for option Minimum temperature instead of OFF
- decouple thermostat temperature changes
- deleted experimental features (will come back if developers fix that damn bug)
- trigger filtering by id’s (just under the hood improvement)
- fixed generic calibration sets thermostat to max if external sensor has non numeric state
- generic calibration offset range is set to min -2 and max +2 ° now
- fixed bug in scheduler selection
- fixed entry selection in scheduler adjustments
- fixed bug when comparing scheduler attribute for heating adjustments
3 Likes
Please removed ‘dev’ Label from stable😉
Great Work 
1 Like
What do you mean?
Did you reload your automations? In the title is definitely no DEV. And can you confirm it’s version 4.0.4? If yes, it must be some caching issue. In my setup it has the correct naming.
I copied manuell the new Code in the stable yaml, now it looks good.
I have copied the dev manuelly to the stable to publish it earlier, i had think when i reload the blueprint he take the original stable again
i test the dev verison on some tvr’s and than i pushlish it to stable for hard test
ah i found the problem, when i copy the dev i changed the " source_url" too, so it takes the dev when i reload it - my misstake sorry
1 Like
Just tried the boot function with the latest version.
Worked fine and issue seems to be fixed.
Thanks!
1 Like
AHC 4.1.0_dev
New features incoming in current development version:
- ADD: multiple party entities
- ADD: temperatures in names of party entities
- ADD: selectable hvac mode (heat, cool, auto) → summer ready
I’ve also edited the initial post: You’re are able to vote for the planned features now to give it some priority.
3 Likes
i have tested the new dev with my air conditioner, but he does not start up.
Do you see any wrong setting?
Edit: can you tell where i can made a selfcheck in the log? example: from line to line?
I have been using this blueprint for a long time and it works great, but I have an issue with one specific room. It’s the largest room in the house (a combined kitchen and dinner area), with many windows and a wood stove. Due to the amount of windows, and the wood stove, the room temperature changes much more rapidly, and over a larger temperature range, than other rooms in the house. The room is heated by 3 radiators each with a Tado TRV. There’s a temperature sensor centrally located in the room. It’s not uncommon for the calibration to change +/- 3 degrees celsius
The rapid temperature changes significantly affect the battery life of the TRV’s, since Tado turns on/off for each calibration.
I assume turning on “generic calibration” would fix this issue, but it somewhat defeats the purpose of having a TRV with calibration support. Would it be feasible to implement a feature that disables calibration, until either the room temperature sensor, or the set point of the TRV, drops below the chosen temperature for the room? My issue only occurs at temperatures above when the radiators should turn on . The ideal solution would of course be, if Tado decides not to turn the TRV on/off for each calibration – I think there’s an enhancement request somewhere in the Tado forum.
1 Like
This trace has no changes. If you search n the log for changes you will see it’s empty. I’ve just tested ac in my test environment with a generic thermostat since I don’t own an AC. Here it works as expected.
Could you have a look at you automation, change the comfort temperature, wait until it got triggered and download and share that trace log?
For this purpose the blueprint offers three options:
- you can disable / enable calibration in schedule adjustments
- You can go with a higher calibration delta. So the difference between the thermostat temperature and sensor temperature must be greater before a calibration takes place
- you can adjust the calibration timeout. That means the external calibration sensor must hold the value for this duration without a change before calibration gets called.
Did you already play with these options?