šŸ”„ Advanced Heating Control

also here where the temperature setpoint is calculated, I couldnā€™t find a branch for my use case where I didnā€™t configure any presence setting but only the regular scheduler. Did I miss something or is this currently not supported (opposed to what the ā€œoptionalā€ flag on all presence settings suggests)

Edit: defined a dummy toggle helper and used this as ā€œguest modeā€ entity to make it work for now.

1 Like

Thanks for reporting. That was some old code. I deleted it from here but cant test it right now. Just reimport the blueprint.

1 Like

Thx for the fix. Another issue I see is that calibration doesnā€™t seem to work: it is correctly triggered but then exits with the first condition:

Any Idea how I could further debug this? Mode is ā€œheatā€ in the last debug-log entry and I have an input-temperature_sensor defined - this is what triggers the automation in the first place as can be seen in the trace timeline:

1 Like

Calibration condition is fixed now. Thank you for testing and reporting.

Did you commit to the ā€œnon-v3ā€ yaml intentionally? Commits Ā· panhans/homeassistant Ā· GitHub

Using the updated yaml, the above problem is fixed and calibration executed :+1:

1 Like

Thanksā€¦ was a little too late for me. Now itā€™s commited on the correct blueprint.

Iā€™ve added some logic to decrease zigbee / service calls. Before I push this to the v3 branch I will test it a little locally. The whole action is now more complex but some people had problems with the zigbee mesh utilisation. With that feature climates will only set if there is really something to change (temperature / mode). Iā€™ve also combined the service call for setting temp and mode into one and added an option to split them if TRVs canā€™t handle the combined service call.

Question: when i have a ā€œPartyā€ it is automatically warmer then default, so why party mode is heating?
i think it would be better to have a option for timebased lower temp when more peoples are inhouse

Party is just a common term that is also used in previous heating systems. (Jura, Vaillant, etc.) The name does not come from me. :stuck_out_tongue:
It is only used for heating for a certain time outside the heating schedule.

1 Like

ahhh okay, sorry :slight_smile:
is it possible to add a automatic timebased inputnumber? (Many peoples here and i wanna have a lower Temp for example 4 hours and than go back to normal setted temp)

Thats very tricky with the limited elements of home assistant and causes into a complicated blueprint setup imho since the default schedulers are only binary.

To achieve this that scheduler component would be better:

I would be easier to set the input_number comfort temperature in a 2nd automation or with help of this scheduler component.

1 Like

alright thank you.
Scheduler card/custom component this integration would be great when he would finally add a better Scheduler or add an external HomeAssistant Scheduler (helper), currently you need so many schedulers.

Hello! I donā€™t know if Iā€™m doing something wrong or missing something, but is there an easy way to return to schedule after a time when manually setting a temperature (like on the thermostat itself)? If I switch temperature I donā€™t want to stay like this until the next schedule kicks in, just for like an hour or something.
Thank you!

Hi, this blueprint is designed for fully automated control. You can set temperature manually but if something triggers the automation like scheduler, window, guest mode ect. the temperature will be resetted.

Sadly there is - as far as I know - no way to figure out the source of temperature change. (device or home assistant)

Of course you can trigger the automation and reset temperature by calling automation.trigger or triggering the automation using the UI.

//EDIT: Ok, I think there is a way. With help of a timer this should be possible. Will set it on my feature list. When v3 runs stable enough I will have a look into this.

2 Likes

Iā€™ve been running/testing this blueprint for some weeks now and just started testing the latest beta.

I have a Tado system running 8 TRVs some of which Iā€™m controlling via the Tado integration and some via Homekit. Does anyone have a preference for running this blueprint with the Tado integration or the Homekit integration, Iā€™d really appreciate hearing other peoples experiences of these 2 options.

Yes I like the idea of keeping everything local but not sure if itā€™s enough.

As for the calibration, I see it is only updated when the external temperature changes. This leads to quite some offsets in my setup, where the TRV temperature is ā€œfasterā€ than the external sensor and ā€œruns awayā€ until the next trigger by a change in the external sensor which will change the calibration and thus reset the TRV temperatureto that of the external sensor. See attached image (the filled line is the TRV sensor including calibration offset).

Wouldnā€™t it make sense to trigger the calibration only and always when the difference between the two temperatures exceeds a given threshold, like 0.5 degrees? That both avoids ā€œnoisyā€ updates on 0.1 degree steps and makes sure the offset is always limited, no matter which of the two sensor moves first.

1 Like

Hi there!
Also tested v3 and am blown away by the new features and clearer descriptions. Itā€˜s been working great so far.
However, since Iā€˜m using Tado and have installed external sensors now for every room, I can agree to what some user wrote before: unfortunately, Tado TRVs unnecessarily recalibrate whenever a new offset is put, which leads to an opening and closing of the valve for a short time. This obviously generates noise but also drains the battery. You can read more about it in the official Tado forum, where this has been addressed and people were asking for a firmware fix. Hasnā€˜t happened in three years.

For me, a couple of opening/closings a day would be an acceptable payoff for the increased comfort of using external sensors.

The question now is: is there a way to limit the number of calibrations by applying a rule like the following, which was suggested in the thread above:
Only apply recalibrationā€¦

  • IF changing offset will immediately turn heat on or off AND required offset change will be >= 0.5 OR
  • IF changing offset will prevent heat turning on or off prematurely AND required offset change will be >= 2.0. (This threshold is set higher because it probably doesnā€™t matter as much ā€“ worst case is the heating goes off/on a bit early but then gets turned back on/off a minute later ā€“ and hence to save offset adjustments/battery.)

Iā€˜m not sure how many calibrations this would actually save, but it may be worth a try.
Iā€˜m probably asking too much since this sounds fairly complicated and obviously only affects TADO users. But last night my bedroom TRV constantly recalibrated which created unbearable noise.

Thank you so much in advance. :smiley:

1 Like

@sben @dario2 @coldspark29 big thanks for your help. Iā€™ve updated the v3 test version. Here is a small changelog:

  • calibration triggers when external or current temperature of trv changes
  • calibration service only gets called when the difference between external sensor temperature and current TRV temperature is greater/less than a specified delta (you can adjust this now in blueprint settings (default: 0.5 Ā°C))
  • service calls for mode or temperature can be split (tweak option in blueprint settings (default = off - mode and temp set in one call))
  • service calls only get fired when temperature and/or mode changed and differs to current TRV settings
3 Likes

Will test once Iā€™m home. Lots of love and thanks!

1 Like

Me again! First test very promising! Via the delta setting I can significantly reduce the number of calibrations! :slight_smile:
I will monitor and report further details tomorrow.

1 Like

I had a play with this the other day, to control my Split system AC/Heat Pump.
I loved it, except for the fact I couldnā€™t get it to actually send the off command to the heat pump when the schedule was off, it would only set the minimum temperature. Any idea what I might have done wrong?
Iā€™m using a IR blaster linked to a climate entity, that definitely has the ā€˜offā€™ option under HVAC options.