Thank you for walking me through the debug process.
I set the two TRVs to turn on at 10:42 am this morning and both traces show that the set_temperature service was called but it was only executed on one TRV. After going through and comparing both devices activity in the ZHA logs I can see (1) no evidence of DeliveryError and (2) what seems to be absent in the ‘failing’ TRV logs is the lines:
I have not installed a custom quirk for this device myself but when pairing with ZHA I think this quirk that you’ve linked to was used by ZHA? This is what I see:
thank you for this awesome blueprint!
I have one question left… if i manual change the temperature of a TRV is there a way to automatic set the scheduled temperature back?
One other question a few post ago there was a question about the aqara trv and the External Temperatur Sensor. In the meantime the trv is now more compatible with ZHA but don´t have number value for the calibration instead an external sensor:
Wish I have an aqara e1 in my hands. Seems external senseor is a binary_sensor which just shows if an external sensor is given. From that what I read the Aqara E1 can only be calibrated using zigbee2mqtt. You have to puplish the external sensor in the mqtt topic and then you are able to set it using an automation. Technically it’s easy because the trv calculates the difference by itself. But for ZHA there is no possibility atm.
If there is some code or a blueprint for that I would be very pleased. Maybe you have other information.
Ok. I’ve read a bit about that problem. Other TRVs have this issue, too. Mostly Moes/TUYA based. Since so many specialities are out there I will provide a little workaround section in that blueprint.
So, here you are. At the end of the blueprint you will find an number slider so increase/decrease the delay between the two service calls. Waiting for your feedback. (Don’t forget to test out the guest mode )
The blueprint has been running for three days now and the Guest Mode feature is working as expected.
With the input slider, I increased the delay on my ‘problem’ TRV to 7 seconds (picked it at random) and it has worked as expected 100% of the time. I left the other TRV on 2 seconds and it mostly worked as expected except for one occasion where it did not change the set temperature based on the schedule.
I’m now going to expand the use of the blueprint to all 8 TRVs (4 Siterwell _TZE200_zivfvd7h and 4 Aqara lumi.airrtc.agl001) and will update here later in the week. Thanks!
(One new use case that I’ve been thinking of is when we’re out of the house and about to journey back home and want the heating to come on ahead of time so the house is warm on arrival. I think that the Guest Mode can be used for this purpose too?)
Yes, for that purpose there is the proximity integration which measures the distance between home and persons / device trackers. I test it atm. It has an attribute which shows the travel direction. For me it would be interesting if someone on the way home inside the tolerance window. Think thats the smartest way.
All eight TRVs appear to be working correctly this week. I’ve so far only had to adjust the delay on the first ‘problem’ TRV and it has been working as expected.
Separately, I’ve noticed that when a TRV schedule is ‘on’ and if I change the target temperature on the TRV then sometimes after a few minutes the TRV will reset the target temperature back to the number defined in the blueprint config. Is this expected behaviour?
Yes, every trigger cause in setting mode and temperature of the trvs. The only way to change the target temperature is the comfort temperature input.
Since there is a delay for setting the temperature in the blueprint you can use an automation which instantly maps the manual set temperature of a trv to the comfort temperature input. Be sure to check in a condition if the new trv temperature value in’t equal to the number_input of the comfort temperature.
Okay thanks. I was thinking of a more temporary use case where you want to change the target temp until the schedule changes. For example, the kitchen TRV morning schedule is from 6:00 to 9:00 but this morning I’m feeling like I want to override the comfort temp of 20C to 21.5C and that override stays in place until 9:00 when the min temperature kicks in as scheduled. (The next morning the TRV comes on at 6:00 at the ‘usual’ target temp of 20C.)
Thats not possible with current blueprint or better with that binary scheduler. For that purpose we need schedulers with multiple states. There is a custom component for that but I want to go with the standard tools.
So if you want to achieve this, you need a 2nd. automation that sets the comfort temperatur input depending on time.
I think this may require that the min temperature be updated to accept an input_number helper to build a simple automation for such a purpose? I was thinking of something like:
input_number.set_min_temp with a value of e.g. 15
input_number.set_comfort_temp with a value of e.g. 20
input_number.boost_temp_amount
input_boolean.boost_temp
Then a simple automation where a change in the boolean state could trigger a change in the value of the boost_temp_amount between 0 and some number e.g. 1. (The automation would also trigger a change in the boolean state of the Party mode to ensure the heating comes on.) After a fixed time period the automation would then revert the boolean states back to ‘off’.
The actual min_temp and comfort_temp used by the blueprint would be the sum of the boost_temp_amount and the set_min_temp and set_comfort_temp (that can be created by combining sensors in the UI.)
)