doesn’t matter, i think we have enough time to test during the next 4/5 months
i will update and test again
Could you also update the blueprint? The calculation and everything seems fine. There was (hopefully not is) an issue with the popp/danfoss/hive trigger evaluation.
I have updated the blueprint, and sorry, calibration is still not triggered. Here’s a trace, just in case: https://controlc.com/f547ee21
Thanks! Ok another try. Note logic for Danfoss, Popp and Hive differs a little to the rest of the manufactures. Those thermostats there are two triggers. First trigger is when the temperature sensor changed for 2s and another one every 10 minutes, e.g. 10:10, 10:20, 10:30 ect.
I was able to observe when the error is displayed in the TRV. It happens when you come home and the comfort temperature is set.
The whole action set of this blueprint are 2 service calls for the thermostats. I need the exact service call which results in you error. What temperature did the automation try to set? Maybe the number isn’t supported by your thermostat.
You have to find out what action did that. So navigate to your developer section and play around with climate.set_temperature and climate.set_hvac_mode or as I said the calibration action.
There is no other with such an error so I don’t think the issue is in this blueprint but maybe in your configuration.
Running on latest dev:
My TRVs seem to need the legacy restore mode for windows open. (without, they just stay on OFF mode after windows is closed again).
Strangely enough i had to delete the automation completely and set it up once again from the blueprint to make legacy restore work. Just re-importing did not help.
Question:
while trying to understand Traces I found (in Traces/Changed variables):
@panhans Does AHC check for the type of TRV and does it apply special settings if found? Can´t find (my) Tuya/Moes TS0601 here …?
Yes, some thermostats have problems to get restored from a scene. This is a known issue but that’s a home assistant issue. I don’t know how home assistant resolves a scene restore. But this is also the reason why the legacy restore exists.
I also wonder if this is integration dependent. (z2m/zha)
The different thermostat groups are for the different calibration strategies. The Tuya/Moes are in valves_calibration_common.
Hmm ok. I did a last change to calibration. If this doesn’t work I have to think about another way how I will debug this issue.
Unfortunately it doesn’t. When I look through the latest traces, it seems like there are different types of triggers that caused the automation to start, but they all lead to a quick halt after the first conditions are tested. Here is one of these traces: https://controlc.com/c2f97ba3
Some for me aggressiv does not add value, { "trace": { "last_step": "condition/0/conditions/3", "run_id": "8e - Pastebin.com
Did you check your calibration values with and without aggressive mode?
Yes, generic and aggressiv dont Work
Generic worked few days ago
Turn Generic Calibration on and Aggressive Mode Over Calibration off.
I did, i know both activ isnt good.^^
Both Not working currently
Yes, the values didn’t get generated. Do a last try. If this doesn’t work I will provide a special blueprint with some more logging.
Hello,
i use Advanced Heating Control in combination with a Bosch Radiator Thermostat II and an Aqara temperature sensor.
The windows on/to function in AHC will run as far as possible.
However, the thermostat does not go completely into the off function, but always into a break mode.
Here I have the impression that the valve is not completely closed.
With various other thermostats, this worked well. Here, then, it was always off on the display.
Do I have to adjust something else in the thermostat settings?
To the current default settings:
Did you try to disable the window detection toggle in your settings? This is a built-in function that detects temperature drops.
@stephanschleichstr13
Do you still have issues with generic calibration / aggressive mode?
Yep both add No values to the temp