Disable TRV "calibration" when offset is changed [required for using external sensor]
As you may have read elsewhere on this forum, myself and other Tado users have been working on ways to make Tado TRVs more usable by using cheaper external sensor to read the actual room temperature and dinamically update the temperature offset of the valves with great results.
The only drawback of that is that we have to limit the frequency at which we update the offset; this is because everytime the offset is updated (either manually via the app, which everyone can experience, or automatically via the API) the valve moves the spindle for reasons that nobody understands; this is a waste of energy and creates unnecessary noise.
If this was disabled in the next firware update, I'm sure many will appreciate it.
Comments
-
Like jacopo2 said, the motor operates every time an offset is put. This opens the radiator full blast. Even though it's only for a second, it can significantly increase the temperature of the room, rendering the much needed offset feature counter productive at best if you're using it to dynamically correct the room temperature. Disabling dazzle does not resolve this.
0 -
As a curiosity, does it do the same unnecessary calibration if a real Tado Smart Thermostat is used as the reference external sensor?
0 -
@jelockwood no, it doesn’t do any calibration when the measuring device is a Smart Thermostat; I just tried
it’s really annoying; the TRVs even recalibrate when I ‘change’ the offset from 0 to 0 (i.e. I apply the existing offset from the app)0 -
Agree - this is really annoying and limits how useful being able to set the offset dynamically is. Please can you fix this tado?
0 -
Agree for all the reasons mentioned by others.0
-
Fix it please, very annoying0
-
This sounds like a very easy fix. Can we get someone to comment on when a fix can be made?
0 -
Agree, it should be simple yet very useful
0 -
+1 can be get this fixed?
0 -
Please Tado, can you fix this?0
-
This is a very good idea, much better than Tado very expensive new "solution" (re-hashed Thermostat)
0 -
Please fix it Tado !
0 -
Can this be fixed, please?0
-
Agree, it should be fixed as it's very easy to fix.
0 -
+1, please fix, would be very useful.
0 -
@Jacopo2
May I ask where can I find “dynamic offset” solution that you and other members of the community are working on?
I am new to tado, but the TRV inaccuracies is annoying me.
I “hacked” the 25° limit by putting an extra tado TRV in same room as another tado TRV. The one that’s not at the heat source reading 22°, the one at installed at the radiator reads 28°!0 -
Mine is here
Apparently the discussion is “closed”
https://community.tado.com/en-gb/discussion/4525/trv-offset-correction-using-home-assistant-external-sensor-script-here
There is also one on github that can be flashed into an esp8266 development board without any additional home automation platforms needed
https://github.com/jon-riches/ESP8266-TADO2 -
TL;DR: please fix this Tado. One shouldn't have to pay a premium of 6x for your temperature sensor compared to other products just because your product (TRV) doesn't deliver to begin with. If you need a beta tester for an experimental firmware, I'm up for it.
I tried to integrate Tado radiator with an external sensor so that I can have decent heat in the bedroom overnight and this was basically a showstopper. The TRVs are so worthless (after 75' the offset was at +7-8C) at tracking temperature that one need to adjusts every 10' of so when the heating is ON. This might be OK in any other time of day, but woke me up at least thrice.0 -
You just need the esp8266, a dht22 sensor, a usb cable and a usb charger, nothing else as hardware needed, maybe just a breadboard if you don’t want to solder things0
-
@Jacopo2 Thank you very much for posting your script. hainvg seen my offsets going all over the place during this cold spell, I'll be implementing this on HA when my sensors arrive from China! In the meantime, can I please just check my understanding of the script, in paricular using it with more than one sensor/zone?
If I set the ZONE variable to something like [14, 16] and the SENSOR variable to ["{zone 14 sensor HA ID}", "{zone 16 sensor HA ID}"], will this do the trick? If I'm reading it right it'll recurse down the two lists but my python (indeed coding generally) is pretty rudimentary so I just wanted to check.
More closely on the subject of this thread, is running this script (or an esp8266 equivalent) enough to workaround the TRV calibration problem?
Many thanks for all your hard work on this!
0 -
@zacchaeus I don't use this specific script (I don't have home assistant) but yes, adjusting offset based on an external sensor is enough to workaround the TRV calibration problem. A couple of interesting observations I made is that
1) while the offset is applied quickly to the room settings, it may take some time to take effect when it comes to heating
2) constantly adjusting takes a non-trivial toll on the TRV battery. I put a simple logic in place to only adjust if it makes sense, namely only if a) HEAT in a room is off and adjusting would turn it on 2) the opposite HEAT is on, would turn it off 3) HEAT is on and the offset should decrease, i.e. go from -1 to -1.5. This can still thrash the batteries pretty quickly
0 -
Thank you for that. Your comments are really helpful. Looking back at my last message, I'd missed out a few important words from my last question. I should have said: "is running this script (or similar) something like every 5 minutes enoug to work around the TRV calibration problem?"
However ... your solution strikes me as a better solution. With that in place, it sounds like the script can be run as often as you like (within reason), which is excellent. I don't suppose you'd mind sharing the relevant part(s) of your code, by any chance? I can hopefully adapt to the code for Home Assistant, modifing @Jacopo2's script, which I'll post.
Out of interest, what are you running it on? Are you using an esp8266?
Many thanks.
0 -
I am using Shelly H&T as a temperature sensor (they offer a simple web API to retrieve temperature) and the script runs on a Raspberry Pi. It does so through a cron job every 10' during the day. During night I prefer to have a fixed offset and pre-warm the bedroom (the frequent noise due to recalibration is seriously annoying and honestly I don't expect Tado to fix it).
You can find the script at https://pastebin.com/1dA2myVG I use it to control the temp across three different rooms. I'll probably rewrite this in Python eventually, but for two hours during the weekend it gets the job done for me. You should be able to reuse the logic.
P.S. funnily enough H&T is based on ESP8266, but I am not brave enough to flash it :)
1 -
Thanks again. This is really helpful.
Everything makes sense down to line 116, but I'm not sure the purpose of 118 to 139. These lines seem to be either resetting offset to zero if this doesn't turn the heat back on (121 to 133), or setting it if the delta between current offset and target offset is above +/- 0.5 and this ioesn't turn on the heat (135 to 141).
What I can't quite get my head around is why these are needed . Re 121 to 133 (also possibly 68 to 77?), these bits don't feature in your three change conditions in your 9.40 comment. Is there a particular reason why we need to reset to zero if this doesn't make any difference to whether the heat is on or off? Is it just about "tidying things up" or would not doing it cause a problem further down the line? If we're not worried about the offset being wrong unless it's actually impacting whether heat is being produced then can we just leave the offset as non-zero and save some battery?
135 to 141 seems to act as a catch all - any time the , other than keeping the offset within 0.5 of a degree even if it's not going to impact the heat state of the zone. Is that right? Again, is there a reason why we can't just leave it with a potentially wrong offset and save a bit of battery?
Essentially, the question is: can these two if statements go (so we effectively end at line 116) and/or can 68 to 77 go, or am I missing something?
Thanks again.
0 -
You should be able to eliminate these.
With regards to (121 ... 133) I have noticed that when a decimal offset is applied then the display on my bedroom TRV occasionally displays three dashes if I turn the knob instead of a temp. The side effect is that one loses the convenience to do a quick and dirty manual adjustment through the TRV, one needs to go through the app instead. "Tidying up" conveniently avoids this issue. You may not run into the issue or you may not care about manual adjustment, YMMV.
135-141 were indeed there for a more accurate reading. Eventually I wanted to convert the output to JSON and send it to ELK but this will take another weekend project for me. May just comment it out for now.0 -
@Jurian given your feedback on the "cheaper external sensor" thread (probably not going to happen in 2021) is it possible to chime in on this one?
Using offset change with an external sensor is the only way to make heating work as intended. However it comes at a measurable cost, last year TRV batteries lasted me almost the entire season whereas this year it appears that I have to change them every couple of months or so. In addition the noise during offset adjustment makes the approach largely a non-starter during the night for bedrooms.
0 -
This content has been removed.
-
I (and presumably others based on the 68 upvotes) are one way or another using the API to constantly adjust the offset based on an external sensor. During daytime the calibration is simply an annoyance which eats batteries faster. During night, let's just say that if you are a light sleeper the TRV noise can be annoying enough as it is, if you have to hear it twice or thrice as often you probably won't sleep at all
0 -
We're using third party temperature sensors and scripts running on Raspberry Pis or other devices to calibrate the offset via the Tado API. This means the temperature is measured near to where the people are rather than right beside the primary heat source in the room, keeping the temperature more stable and accurate.
I'm currently running my script once a minute, so in theory the offset could get updated every minute.
... however, @mperedim, in the time (admittedly only a week) since my sensors arrived, my script seems to have been working OK and yet I'm not seeing a huge number of offset adjustments. e.g. I had 14 yesterday across 6 zones, all of which were running for a good few hours.
As per our exchange above, I've cut down the number of conditions in which the offset is adjusted, to only:
- 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.)
This might explain the difference we're seeing (although I realise that all sorts of factors, such as room layouts, radiator types, etc, could explain it).
I’m toying with getting rid of the second condition so it only triggers when it will immediately lead to heat turning on/off. Interestingly, none of the 14 changes yesterday was caused by the second condition. I need to think this through a bit more to understand why.
Any resemblances between the room temperatures shown in the Tado app and the actual temperatures are now, of course, purely coincidental. What would be amazing is if Tado would add an API parameter (or 2?) to ignore the TRV temperature reading and replace it with an external one. (@Jurian, any hope? 😁)
0
