đŸ”„ Advanced Heating Control

Nope, same but now I’m pretty sure that the blueprint set’s the away_preset_temperature property to the desired external temperature instead of the external_temperature_input is that intentional?

Yes, the new version filters for external so the away_preset_temperature is ignored. You have to wait some time or trigger the calibration by manipulate the value of the external temperature sensor by setting its state in dev tools or by hold it in your hands for example.

No, I don’t see an exclamation mark in the trace.

Yep - works now. Thanks :slightly_smiling_face: But that means I’ve to set the thermostats to external manually upfront, right? Will you add that to the regular version?

If this is the way the calibration entity gets exposed now I will merge this change into the main branch.
What did you mean with “set the thermostats to external manually upfront”? Do you have to enable an option in the device options first to make calibration possible?

Yes, according to the documentation Aqara SRTS-A01 you’ve to select the temperture sensor to use through the sensor property first. The previsously mentioned blueprint: [Z2M] Aqara TRV E1 link external temperature sensor - #50 by ThWoell does this automatically as well.

1 Like

Wonder if the same entities are exposed using ZHA. Would be great if someone can confirm that or send a screenshot of the device page using ZHA.

I will see how to check if this entity exists and will implement this later. The fix is merged in main branch now.

//EDIT: But I have an idea to implement this safely. :slight_smile:

@matty.van.heesch check out the latest version and have a look in the tweak section. You can enable legacy restore to avoid scene based restore.

1 Like

Checked for a few rooms and seems to be working :-).
Will enable it for all others and monitor the coming days and let you know the result.

Thanks a lot!! Really appreciate all the time and effort you put in this!

1 Like

So if my heating was set to 21c, I would want it to heat up to 21, then have a value like 20c it must drop back down to before heating will resume.
This will prevent it from turning on and off repeatedly as the temp hovers around the set point.

How I can achieve similar with durations?

1 Like

Hey @panhans - thanks for your reply:

Look, for me and probably for all other newcomers in the TVR or AHC “business,” your few lines above could be worth gold and save money, time, and nerves. Shouldn’t you include them in the first post, or how could we, as the HA community, better share these experiences? Should I open a new post for this? I won’t be as active or close to the AHC topic as you, which is why I’m asking again.

Hi,

thanks for the wonderful Blue Prince.

on 1 unit I use tweak above room temperature to switch off unit. but I want it to ventilate when the unit is out of command.

Is there anything I can adjust when the unit is turned off and enters ventilation mode?

Thanks for your explanation. I just didn’t get the context of your hysteresis request. I though you meant some hysteresis around triggering the automation first.
But no, atm there is nothing implemented like this, but I see if I am able to implement this.
Most Tuya thermostats are reacting sluggish and open their valves when the real temperature is 0.5° till 1°C lower than the target. There is the aggressive mode to compensate this. But this is the exact behaviour you’re looking for. :smiley:

Yes, would be a great addition. Wonder if there is a thread already about thermostats for home assistant.

You can try a custom action, with a condition on top. But I don’t know if this works. Could be that the automation resets the state to off with the next change of temperature meassurement. So maybe it needs an additional input for selecting the desired mode when the temperature hits the target.

- condition: template
  value_template: |-
    {{ (input_hvac_mode == 'cool' and sensor_temp <= temperature) or 
    (input_hvac_mode == 'heat' and sensor_temp >= temperature) }}
- action: climate.set_hvac_mode
  data:
    hvac_mode: fan_only
  target:
    entity_id: climate.YOUR_AC

//EDIT: You could also add this as a custom condition:

condition: template
value_template: |-
    {{ (input_hvac_mode == 'cool' and sensor_temp > temperature) or 
    (input_hvac_mode == 'heat' and sensor_temp < temperature) }}

This should block unwanted resets.

I’m sorry to report that it does not work for me

Proximity set at 8000m, it does not trigger when drive around at work, that’s perfect.

But when driving home, the comfort mode was only triggered when arriving home.

Can you help in debugging? (Pictures are almost the same as above, only change is the change to 8000 in distance)

Dear panhans!
Thank you for the excellent Blueprint. I am happy to see how much it has developed since last year when I used it. Now it is time to heat our home again, and I started to use the latest version.
My TRVs tend to react quite slowly, so I decided to enable the aggressive mode. It works flawlessly. However, I was a bit disappointed to find that I have to disable the “Physical Temperature Change” option since the aggressive mode also changes the set temperature. I was wondering if it would be possible for the aggressive mode to adjust the temperature offset instead of the target temperature if I have a “temperature calibration sensor” set. That way the aggressive mode and the physical temperature change options could be enabled at the same time. What do you think?
Anyway, I highly appreciate your work. Thank you very much for sharing this blueprint with the community! :slight_smile:

1 Like

Hey, I pushed a fix for proximity but there was only an issue if you use proximity only. Maybe you could share a screenshot of the history graph of your proximity sensor when you’re on the way home. It could be that this feature needs a little bit more tuning since I doesn’t use it for my own.

Heating is only triggerd if you’re in the radius and the state of one device tracker is towards for the selected duration. If the state changes for the same duration comfort heating get’s disabled again. May be this is not the best logic.

1 Like

Good point! Never had this idea before. But I don’t know how suitable this is. I would add an checkbox for enabling this because some calibration entities only allow max ±2-5°C. There is not much space for the aggressive mode offset in much cases.

1 Like

Hello,

I just updated to version 4.3.12 of the blueprint. There is now a minor bug with the presence detection. If my presence sensor detects some movement, the temperature is not setting to the comfort temperature anymore.

In the past version (I don’t know exactly which one), this was not a problem.
What’s working now is the window detection. That wasn’t working in the version before :smiley: . If you need more information, I can maybe share it with you, @panhans.

thats a good idea i think! i also use the aggressive mode with and calibration sensor and in some rooms it would be good to do a physical change!..

2 Likes

No problem here with presence detection. Could you share a trace log or at least your configuration?

Exactly what im trying to achieve as well. This is less applicable for Central Heating with gas. During this autumn period I want to stick with HVAC heating to avoid using gas. Then this mode is more desirable to avoid the HVAC going on and off.

A solution is to keep it on and dont turn it off but then it will blow neutral temp air and the wife acceptance factor goes down.

Im thinking about an automation that will bump the max temp as soon as the automation hits. When reached lower the max temp again. This will create some buffer. Great addition for the developer (and something to append to the loooong list of requests haha) keep up the good work!

1 Like