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.
@panhans i have a new problem, that worked with the v4 without problems. If i switch the input_mode_winter bootlean from on to off both trvs switched to off mode. If i switch it back to on, only the raumthermostat_wohnzimmer reacts and go to heating mode. The raumthermostat_kuche stays in off mode. If i switch the both tvrs the last one in the configs stays off.
alias: Heizplan Erdgeschoss v5
description: Heizplan für Erdgeschoss
use_blueprint:
path: panhans/advanced_heating_control.yaml
input:
input_trvs:
- climate.raumthermostat_wohnzimmer
- climate.raumthermostat_kuche
input_temperature_minimum_static: 18
input_temperature_comfort_static: 21
input_windows:
- binary_sensor.kuchenfenster_window_door_is_open
- binary_sensor.terrassenture_sensor_window_door_is_open
input_mode_outside_temperature: weather.solingen_hohenscheid_h641
input_mode_winter: input_boolean.heizung_automatik_erdgeschoss
input_persons:
- person.1
- person.2
- person.3
- person.4
input_proximity: da641e096e869a8aadcc68f3e0da7b9e
input_mode_party:
- timer.heizplan_erdgeschoss_partymodus
input_mode_guest: input_boolean.heizplan_erdgeschoss_gastmodus
input_windows_reaction_time_open:
hours: 0
minutes: 0
seconds: 5
input_windows_reaction_time_close:
hours: 0
minutes: 0
seconds: 5
input_hvac_mode: heat
input_party_legacy_restore: true
I cannot reproduce this behavior. Could you switch the log level to warning. Turn off your winter mode entity so both thermostats are off. Enable it again and wait until the first thermostat turns on.
Then download and share the trace log.
Did you check your logs? I think there is something wrong with your climate entity.
Set temperature action was used with the target temperature parameter but the entity does not support it
This message is not thrown by AHC but by home assistant. Maybe this error exists because the thermostat stays off. But hvac mode is set to heat for the first defined thermostat climate.raumthermostat_wohnzimmer. The automation breaks because of this error and the last thermostat never came in touch with a change.
Could you disable the automation and navigate to the service/action tab of your developer tools. Then try to set the target temperature one by one with a service/action call. Check your logs for an error after you call the service/action.
Also check if there is another automation “fighting” each other. Maybe have a look into the logbook if there is something that resets the hvac mode of your thermostats.
1 Like
Hi @panhans,
running 5.0.4_b now which is working fine, except that I get these warnings in the log I cannot really figure out what they mean:
Logger: blueprints.panhans.heatingcontrol
Quelle: components/system_log/__init__.py:331
Erstmals aufgetreten: 12. November 2024 um 19:00:00 (63 Vorkommnisse)
Zuletzt protokolliert: 07:30:04
AHC - Calibration - Thermostatsteuerung Wohnzimmer reset data: [{'entity': 'input_number.comfort_temp_wohnzimmer', 'temp': 21}]
AHC - Change - Thermostatsteuerung A Badezimmer Trigger ID: temperature_change_scheduler_off Thermostat: climate.thermostat_a_badezimmer Mode: heat New Target Temp: 18 Current Target Temp: 22
AHC - Change - Thermostatsteuerung Wohnzimmer Trigger ID: temperature_change_scheduler_off Thermostat: climate.thermostat_wohnbereich Mode: heat New Target Temp: 17 Current Target Temp: 21
AHC - Change - Thermostatsteuerung A Badezimmer Trigger ID: temperature_change_scheduler_off Thermostat: climate.thermostat_a_handtuchhalter Mode: heat New Target Temp: 18 Current Target Temp: 22
AHC - Change - Thermostatsteuerung Wohnzimmer Trigger ID: temperature_change_scheduler_off Thermostat: climate.thermostat_essbereich Mode: heat New Target Temp: 17 Current Target Temp: 21
Also I think that the combination of Physical Temperature Change and Reset Temperature doesn’t seem to work. In the room where I have set this up for testing the temperature was increased while the schedule was active but the set person away. This led to increase of the ECO temp helper. However after the end of the schedule the ECO-temp helper remained at the increased temperature and also the thermostat set-point. I had expected that it would have been set back to the static eco-temp then.
1 Like
For the logs you have to set the log level in the blueprint settings to debug instead of e.g. warning.
Atm. the temperatures gets resets when an eco or comfort period ends. So if your schedule is active and the persons aren’t home eco is active. As long as comfort mode doesn’t kicks in the temperature won’t get a reset.
Imagine your using presence detection but blacked out it as you don’t want it for a specific time window. Presence is maybe triggered more often than a schedule and with every time the temperature gets a reset.
Maybe I should add a toggle for this purpose to do a reset on every change also if the heating mode doesn’t change?!
Good morning everyone, while using this wonderul automation, I’m still struggling with my Tuya TRV’s Zigbee TV-02. I don’t get this working when I want to use them as thermostat because I can add their entity climate.radiator.xxxx to see in HA with Generic or Better Thermostat but if I put them in the configuration.yaml file and add the switch of my pump and boiler like I also do with the Zigbee thermostat in the living room which is a sensor, their is a problem and the switch will not turn on. I think it has to do something with the fact that the TRV’s have the entity climate and the normal has the entity sensor.
So I have been searching and came to this blueprint but it’s good and so many features that I don’t get starting because of my issue.
I hope somebody could help me out here and get me starting.
Hello
I’m using the current version with “nedis Zigbee Radiator Thermostat”.
I have 2 questions:
to the 1st question, do I use → operation / HVAC mode → heat or auto for thermostats & sensors?
Question 2:
I want the thermostats to turn off when the temperature is reached, or is this not recommended?
Here are my YML:
alias: Clima _ Badezimmer (blueprint)
description: “”
use_blueprint:
path: panhans/advanced_heating_control.yaml
input:
input_trvs:
- climate.thermostat_badezimmer
input_temperature_comfort_static: 18
input_temperature_eco_static: 17
input_windows:
- binary_sensor.tur_badezimmer_contact
input_windows_reaction_time_open:
hours: 0
minutes: 1
seconds: 0
input_windows_reaction_time_close:
hours: 0
minutes: 1
seconds: 30
input_window_open_temperature: 0
input_off_instead_of_eco: false
input_min_instead_of_off: false
input_off_if_above_room_temperature: true
input_reset_temperature: false
input_hvac_mode: auto
input_persons:
input_temperature_sensor: sensor.temperatur_badezimmer
input_calibration_timeout:
hours: 0
minutes: 1
seconds: 0
input_people_entering_home_duration:
hours: 0
minutes: 1
seconds: 0
input_people_leaving_home_duration:
hours: 0
minutes: 0
seconds: 2
(use a translator)
Okay, I actually thougt “warning” would trigger less log entries. Will go with debug then…
I think such a toggle or maybe even some kind of delay timer could make sense:
I could imagine if someone uses actual presence detection he would not want to have a reset when say he leaves the room for a few minutes to gran some coffee or the like but maybe after an hour or so. In my case I just monitor if someone is home so I would want the reset when someone leaves (or arrives for simplicity).
In my case what happened is that the reset didn’t happen even after the schedule ended however (maybe because the state changed from eco to comfort by me coming home instead of schedule start)?
1 Like
@panhans On v4 I just noticed that the AHC event is not issued when applying the scene to restore the thermostat state after a window has been closed. Not sure if this also happens in v5, as I didn’t update yet.
Hey group.
I’ve migrated all my heating automations to AHC v5_0_4_d and on the whole, it works brilliantly so thanks to @panhans for all the hard work getting this blueprint to this level of control.
However, I’m having one or two issues with presence and person-based control. I’m using presence over scheduled so have not set anything in the schedule section. There is no-one home right now, but a couple of rooms are reacting to presence or not registering that no-one is home.
Here’s a couple of examples.
Our cloakroom settings:
alias: Cloakroom Heating
description: ""
use_blueprint:
path: panhans/advanced_heating_control.yaml
input:
input_temperature_eco: input_number.heating_eco_temperature
input_trvs:
- climate.cloakroom
input_temperature_sensor: sensor.h5075_b444_temperature
input_temperature_comfort: input_number.heating_comfort_temperature
input_off_instead_of_eco: false
input_min_instead_of_off: true
input_persons:
- person.david_forrester
- person.gem_forrester
input_people_leaving_home_duration:
hours: 0
minutes: 1
seconds: 2
input_mode_guest: input_boolean.guest_mode
input_schedulers: []
input_presence_sensor: binary_sensor.cloakroom_occupied
input_scheduler_presence: schedule.general_heating_schedule
input_presence_reaction_on_time:
hours: 0
minutes: 0
seconds: 2
input_presence_reaction_off_time:
hours: 0
minutes: 0
seconds: 2
input_force_max_temperature: input_boolean.boost_heating
input_proximity: 4ceb8d4d4c0bfd33a044373150933207
input_proximity_duration:
hours: 0
minutes: 1
seconds: 0
input_proximity_distance: 250
input_away_offset: 2
input_away_presence_mode: true
input_away_presence_ignor_people: false
input_windows:
- binary_sensor.cloakroom_window_contact
input_calibration_timeout:
hours: 0
minutes: 0
seconds: 30
input_calibration_key_word: offset
input_frost_protection_duration:
hours: 1
minutes: 0
seconds: 0
days: 0
input_mode_winter: input_boolean.winter_mode
input_mode_party:
- input_boolean.party_mode
Yet the heating is set to Away rather than Eco and switched to Eco when I went home?
Similarly, our kitchen seems to be reacting to presence despite no-one being home (the dog is in the kitchen so will be triggering presence)?
Any ideas? I’m wondering if the person-based detection looks for away rather than not_home or anything other than home, but having said that, I have other rooms that are currently set to Eco as no-one is home.
@rytecbe Maybe you describe first what do you want to achieve? Heating schedule, person based, presence detection ect.
-
Depends on your thermostats. Mostly the manual mode is heat but there are some thermostats where heat is the boost mode. You need to chose the manual mode here for your thermostats.
The thermostats close the valve automatically. I won’t recommend that. You can enable it in the temperature tweak section but it makes more sense for A/C devices.
@andreip
Yes, that’s fixed in v5.
@P6Dave
I can’t reproduce this. Is your guest mode entity enabled? Any trace log would be helpful (when nobody is at home).
2 Likes
Thank you. Following simple thing I want to do
use the TRV as thermostat in each room and if I change the request temperature to open the valve of the TRV for example from 19°C to 21°C and the internal temperature sensor from TRV says it’s 20°C it should activate the zigbee switch for my heater and circulation pump.
This I can do now with the thermostat in my livingroom wit this config
climate:
- platform: awesome_thermostat
name: Woonkamer
heater: light.cv_sturing
target_sensor: sensor.thermostaat_woonkamer_temperature
eco_temp: 18
away_temp: 15
boost_temp: 22
comfort_temp: 19.5
sleep_temp: 16
but it doesn’t work if I use the same thermostat template for the TRV like this
- platform: better_thermostat
name: Radiator Keuken
heater: light.cv_sturing
target_sensor: climate.radiator_keuken
eco_temp: 18
away_temp: 15
boost_temp: 22
comfort_temp: 19.5
sleep_temp: 16
don’t pay attention on the zigbee switch with entity light.cv_sturing it’s a Tuya zigbee switch which I cannot program as switch entity but it works fine, if possible to rename the entity later then I’ll do that.
This is way offtopic, but:
You need a input_boolean helpers for each of your room as your virtual heater switch. Then create a generic thermostat for each room (can be done over the UI, too):
climate:
- platform: generic_thermostat
name: Livingroom Thermostat
heater: input_boolean.heater_livingroom
target_sensor: sensor.livingroom_temperature
- platform: generic_thermostat
name: Kitchen Thermostat
heater: input_boolean.heater_kitchen
target_sensor: sensor.ktichen_temperature
(Note: this a minimal setup you can add min and max values ect. hav a look into the docs)
Then create a binary template sensor (I will call it binary_sensor.boiler). Also possible over the UI in the helper section. And fill in your input_boolean entities.
{% set inputs = ['input_boolean.heater_kitchen,'input_boolean.heater_livingroom']%}
{{ inputs | expand | selectattr('state', 'eq', 'on') | list | count > 0 }}
The template sensor checks your thermostats if any of them is in heating mode.
And then you wrap your light into a switch that get toggled by this new binary template sensor:
switch:
- platform: template
switches:
boiler:
value_template: "{{ is_state('binary_sensor.boiler', 'on') }}"
turn_on:
service: light.turn_on
target:
entity_id: light.cv_sturing
turn_off:
service: light.turn_off
target:
entity_id: light.cv_sturing
1 Like
Oh man, I hope this will solve my issue and sorry for the off-topic post but I’ll test this tonight when I’m at home to program.
Do I have to add some things into my configuration.yaml like
input_boolean:
etc?
With UI you mean to use your Blueprint?
Just the switch wrapper. Generic thermostats, input_booleans and templates sensor can be created in the UI.
No, this all has nothing to do with this blueprint. I mean home assistant integration (generic thermostat) and helper (input_boolean, template sensor).
1 Like