đŸ”„ Advanced Heating Control


Not realy

Thanks for reporting. I could reproduce the problem. Will fix it soon. As a workaround you can try this:

- time: "00:00"
  calibration: "off"
- time: "09:00"
  calibration: "on"
- time: "20:00"
  calibration: "off"

Could you also check the graph (history) of your thermostat especially the target temperature. It may be possible to determine whether and when exactly the temperature was set.

1 Like

Looks like after it was “off” (5°C) however this came. No Window was open and everyone was at home. But this shouldn®t change the input value

Ok, I will try to reproduce it in my test environment later. Hopefully I can. :wink:

That was the case. In the entity list there was also the old one “lokaler_temperatur_offset”. I simply deactivated that and it just worked again!
The TRV uses the quirk zhaquirks.tuya.ts0601_trv.ZonnsmartTV01_ZG which I did not setup manually. But perhaps this was updated in 2024.01 and created the new offset entity what led to this fault.
Thank you very much for your support!

1 Like

@panhans
Regarding manual changes, couldnt you use a number helper per room to store the T° AHC has set? Then you can detect if TRV T° is different from this → manual change.

The goal was to take the target temperatur of the physical change and synchronize it with all thermostats and the number entities regarding current mode. (Eco/comfort)

I don’t believe the related bug will fixed in near future the only way is to decouple the target change from the automation. But the with every change (scheduler, window, person, ect.) temperature will get reset.

I have a TRV going rogue. T° shooting skyhigh. I Have 9 Sonoff smart TRV, in 6 different rooms.

All rooms run AHC, with 5 of them working just fine.

1 room, the home office/master bedroom is going rogue.

temps of 33°C with the AHC set off or eco-temp at 16°C.

there is no way to turn the TRV manual off, because the AHC just put it back on 16°C.
I reinstalled the TRV a couple of times, but the problem stays.

I don’t understand what’s going wrong.

i is like the TRV has a higher “0” point of some sort.

Hi again,
I am facing two annoying issues I cannot really pinpoint.

  1. Since I setup the Comfort Temperature Helpers to support physical temp change, the temp change works, but whenever the windows are opened, this helper is set to the min temp permanently.

  2. I set up a text input helper to select from three schedules in one automation. The text is set by an automation that changes it based on the state of some buttons in the UI (also helpers). Unfortunately AHC doesn’t seem to pick the correct schedule. Is there some restriction on the names? I used „Zeitplan - Gaestezimmer“, „Zeitplan - Gaestezimmer Urlaub“ and „Zeitplan - Gaestezimmer Gaeste“. Currently the input text is set to „Zeitplan - Gaestezimmer“ but the automation uses „Zeitplan - Gaestezimmer Urlaub“

I am running 4.0.3

Thanks a lot
jonathanarcher

hey, some weeks ago i had a similar prob. That the blueprint didn’t accapt the scheduler. A workaround for me was to delete the scheduler and recreate it , with the same name. Until now all worked fine!

1 Like

today i got some probs with on of my automations.
i set the comfort temp to 21. And normaly it would do what it should. But today the sun was shining. So the room was heating additional with the sun. So normaly the valves should close if the comfort temp is reached. But today it opend more and more, because the delta between the external sensor and the trv-sensor getting bigger and bigger. So the room was heating and heating!
grafik

At the screenshot you can see in the first part that the delt getting smaller and smaller. And than the sun comes out and heating goes on!

I miss the legend and the y-Axis values. Compared to my history the purple line is the target temperature, orange is state heat, and the blue line is the measured temperature of the thermostat.

So I think you’re using generic calibration, right?

At timestamp 11 am your problem takes in place. But it looks fine to me. The target temperature (purple) got lowered because the measured temperature (blue) has risen.

The graph doesn’t show if the valve had been closed. Mode heat (orange) doesn’t mean the valve is open. In this mode the thermostat tries to hold the target temperature.

The temperature rise can be caused by the sun and the residual heat from your radiators.

Thanks for reporting. Will check this soon.

Will also check this. I use a regex so the first matching scheduler will be selected and “Zeitplan - Gaestezimmer” is part of every scheduler name you’ve selected. This might be the problem. So I have to expand the logic to find a full matching string at first. As a workaround you can go with a unique names like:

  • Zeitplan - Gaestezimmer Standard
  • Zeitplan - Gaestezimmer Gaeste
  • Zeitplan - Gaestezimmer Urlaub

Could you post your blueprint configuration in yaml mode?

sry for the missing y-axis. As i can say, that the long straight between 9 and 10 is the temp i set as comfort temp! So in this case all is as expacted. and the purple line is the target temperature at the trv

yes i use the generic calibration.

yes thats true

but in this case the target temp at the trv raises but it should drop! And as i can say it was not the residual heat!!!

My imagine is, that there is something wrong with the calibration routine, when the real temp is above the target temp!
For my understanding it should be as follows:

real temp: 1
comfort: 21
→ diff: 21-17 =4
→ new target at the trv: 21+4 = 25 → thats how it works until real and target are identical

BUT:

real temp: 24
comfort: 21
→ diff: 21-24 = -3
→ new target at the trv should be 21-3 = 18 → but in my case it was still above the comfort temp. For my brain and me the target temp at the trv should be below the comfort temp.
And thats something i cant understand! :sweat_smile: :rofl:

Here is the part extracted from the logic. You can paste this into the template editor in dev tools and play around with the first three values. (target temperature, measured thermostat temperature, external sensor temperature)

{% set sensor_temp = 24 %} {- EXTERNAL VALVE TEMP -}
{% set current_valve_temp = 21 %} {- MEASURED VALVE TEMP -}
{% set valve_temp = 21 %} {- COMFORT TEMP -}

{% set max_temp = 30 %}
{% set min_temp = 5 %}

{% if current_valve_temp != sensor_temp %}
  {% set offset = sensor_temp | float(0) - current_valve_temp | float(0) %}
  {% set temp_with_offset = float(valve_temp) - float(offset) %}
  {% set step = float(0.5) %}

  {% set temp_with_offset = (temp_with_offset | float(0) / float(step)) | round(0) * float(step) %}

  {% if(temp_with_offset > max_temp) %}
    {% set temp_with_offset = max_temp %}
  {% elif (temp_with_offset < min_temp) %}
    {% set temp_with_offset = min_temp %}
  {% endif %}

  {% set valve_temp = iif(is_rounded_values == true, float(temp_with_offset) | round(), temp_with_offset | round(1)) %}
  
{% endif %}

{{ valve_temp }}

Also tested in my test environment:

// You could share a trace log with debug information. Maybe it helps


The graph of your external sensor is missing too.

thx for that
i will try :slight_smile:

i will made a new graph, the next days!..in the implied automation i combined 2 trvs! So i made now two automations, for both trvs and i will check this. Maybe than it will be clearer;)

Thank your for this great Blueprint. I have one question, i don’t understand. I have added a schedule helper in the automation for my Bathroom, e.g. 5am - 9 am weekdays to comfort, else it’s off. But when i want to heat outside the schedule and switch heating on via BetterThermostat Card in the gui, the Automation set it back to off, when it triggers, because it’s 11am or something else. I hope you understand me!?

The Party mode is only if i change the temps physical on the trv right?

1 Like

Yes, I will decouple changing temperatures by thermostats in the next version. So it does not trigger the automation again.

1 Like

Hi,
I found this amazing blueprint about two weeks ago.
Firstly thanks for your work!

Sadly I’m running into one small issue.
I’m using this blueprint with Homematic devices.

When I press the boost button on one of the thermostats or trv the valve fully opens as expected but after a few seconds the valve gets reset to the previous state and boost function is canceled.

Automation trigger:

platform: state
id: valve_temperature_change_aggressive_mode
entity_id:
  - climate.int0000007
  - climate.meq1779676
attribute: current_temperature

Any suggestions?