welcome back 
I dont unterstand why my party modes starts themselves…
How can I find out why the party mode was started (the left arrow is grey - there are no “older” traces?!)
How can I find out why the party mode was started (the left arrow is grey - there are no “older” traces?!)
Hi panhans,
Tried it, did not work:
But then I had a look into my entity list and found the entity_id number.heizung_wozi_number_temperature_offset. With that ID the service call works (I checked also in the device settings):
Stupid question, I’m currently on version 3.7.2, what do I have to reconfigure when I update to version 4.x?
- Save v3 config
- Create v4 and import v3 config, Check Missing or new values
I think there is something wrong with physical detection of temperature changes. Will check this soon. Sry, I am a little busy atm.
//EDIT: Sorry this issue is related to the home assistant bug. The automation calls itself recursively. The bug makes it impossible to differ between if the target changed by the device or the automation. So if there is an automation/system trigger it could accidentally start the timer. The bug still exits since half a year. 
I think I will open an specific issue for that. And push it again and again and again. The devs should do a feature stop an fix current code base. Now they bring another experimental stuff but this issue is known more than a year now.
Ok, could you navigate to your device overview of your thermostat. If I am not wrong there must be both entities listed. But I don’t know how I could separate the working one from the faulty one. Are you using ZHA with a custom quirk? You can also try to disable the faulty one by selecting the entity and clicking on the gear.
If it’s not available in home assistant the code should select the correct number entity dynamically.
I recommend to rename your old blueprint and disable the automation based of it. Then reimport the new one and resetup them with your entities. There were several users that reported issues (misleading errors) by just overwriting the blueprint with the new one and addiing missing entities.
2 Likes
could it be, that the new dev-version has the same name as the new non-dev version ?
I’ve merged the dev version a few days ago.
In the current dev version is a fix for the option “Minimum temperature instead of off”. Maybe I should add this hint in the initial post.
Hy,
iam new to your blueprint. I want to use it to control my aquara TRVs time based. so i enter under the point:
Heating Schedule Adjustments:
"[
-
time: “08:00”
comfort: “20” -
time: “21:30”
eco: “19”
]"
But after i save, idont se this anymore. its deleted or sth. else. What iam doing wrong ?
OK. my fault. its not yaml conform. So now i use the following
- time: “22:00”
comfort: “22”
This is not working but:
- time: “22:00”
eco: “22”
its working. Whats my fault here ?? Why the temperature change for comfort is not working ??
First, when you post code like yaml please use the code block.
Could you post your configuration in yaml? And just wait a bit. The change is sometimes very delayed.
I think I’m on the wrong track, how can you rename a blueprint? The option to rename is grayed out.
It’s just in case if something isn’t working for you (backup). You can rename the blueprint with code server or file editor addon. Just navigate to blueprints/panhans/heating_control.yaml
If you don’t want to backup simply delete your old automations and the blueprint itself and reimport it. Then just setup you automations again.
1 Like
i updated yesterday to 4.0.3 and this morning my room was cold 
Normally the room should be heated.
Automation Config
alias: Heizung - Kinderzimmer
description: ""
use_blueprint:
path: panhans/heating_control.yaml
input:
input_trvs:
- climate.kinderzimmer_thermostat
input_temperature_minimum: input_number.heizung_minimum_temperatur
input_temperature_comfort: input_number.heizung_comfort_temperatur
input_persons:
- person.marius
- person.nathalie
input_people_entering_home_duration:
hours: 0
minutes: 5
seconds: 0
input_people_leaving_home_duration:
hours: 0
minutes: 5
seconds: 0
input_schedulers:
- schedule.heizung_scheduler
input_mode_party: input_boolean.heizung_manuell
input_mode_guest: input_boolean.gaste_modus
input_windows:
- binary_sensor.kinderzimmer_balkontur
input_windows_reaction_time_open:
hours: 0
minutes: 0
seconds: 10
input_windows_reaction_time_close:
hours: 0
minutes: 10
seconds: 0
input_temperature_sensor: sensor.kinderzimmer_raumthermostat_temperature
input_calibration_delta: 0.2
input_mode_winter: input_boolean.heizung_winter_modus
input_force_max_temperature: input_boolean.heizung_maintenance_modus
input_log_level: debug
Trace:
I don’t have a solution to your problem, but thanks for the food for thought in this line.
I’ve been thinking for a while about how I can realize an anti-scale run of the thermostats in the non-heating period.
Thank you for that.
1 Like
For some reason your comfort temperature is set to 12°C. Could you have a look into your logbook when and by what the comfort temperature was lowered?
You can try latest dev version. There are some issues related to changing temperature by UI (thermostat card), automaton and physical device. i think I have to sort some things but I am working on it.
AHC got triggered by the state of your thermostat. Looks like something / someone changed the temperature of it and AHC tries to synchronize it with all defined thermostats.
Could you also have a look what changed the state (temperature) of your thermostat at this time maybe some seconds before.
I’m just wondering where the 12°C comes from. It could be that the thermostat was initially set to 12°C and when it was switched on, this value was taken and the comfort temperature was set accordingly.
I will analyze the logic for evaluating the temperature again and adjust it if necessary.
//EDIT: Is there an entry in your logbook where the thermostat and not the comfort temperature is set to 12°C? This should also have taken place at an earlier point in time.
Am I understanding the Heating Schedule Adjustments correctly – I thought setting calibration: "off" would pause calibration at the specified time, but it calibrated around 01:00 this morning. Any ideas?
- time: "09:00"
calibration: "on"
- time: "20:00"
calibration: "off"
The full automation code:
alias: Bedroom climate schedule v4.0.3
description: >-
Handles the temperature in the bedroom. Synced on the same schedule as the
rest of the house, but uses a secondary sensor to calibrate the TRV.
use_blueprint:
path: panhans/heating_control.yaml
input:
input_trvs:
- climate.bedroom_trv_controller
input_temperature_minimum_static: 16
input_temperature_comfort_static: 18
input_temperature_comfort: input_number.bedroom_climate_temperature
input_time_based_temperature_change_valve_target:
- time: "09:00"
calibration: "on"
- time: "20:00"
calibration: "off"
input_persons:
- person.samuel
input_schedulers:
- schedule.climate_daytime_schedule
input_presence_sensor: binary_sensor.climate_presence_tracker
input_scheduler_presence: schedule.climate_presence_schedule
input_mode_guest: input_boolean.guest_mode
input_temperature_sensor: sensor.bedroom_climate_sensor_temperature
input_calibration_timeout:
hours: 0
minutes: 15
seconds: 0
input_calibration_delta: 0.6
input_tweaks_experimental:
- physical_temperature_change