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.
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:
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.
It is only used for heating for a certain time outside the heating schedule.
ahhh okay, sorry
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.
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.
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.
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.
@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
Me again! First test very promising! Via the delta setting I can significantly reduce the number of calibrations!
I will monitor and report further details tomorrow.
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.