Tado V2 Hitting API Limits and Cycling Valves endlessly

[MattCheetham]

I have a Tado V2 setup in my home that I've had for years and recently wanted to try using BetterThermostat. I have the IKEA TIMMERFLOTTE sensors in each room so gave setting this up a go. I live in a small 2 bedroom flat so I have set up 5 BetterThermostat instances, one for each room. Each room has a TRV.

Issue 1 - Cycling Valves

Initially I felt like it was managing the temperature well but what I noticed was that I can constantly hear valves opening all the way and closing again. I mean, quite literally multiple valves per minute, non-stop, all day. I figured maybe this was just an initial learning thing but it continued into the second day and didn't seem to let up. I'm using the Offset mode and my guess is that every single time an updated temperature measurement comes in for a room, BT sets the offset which causes the Tado integration to do a calibration. I cannot work out if there's a way I can stop that as hearing all the valves opening and closing non-stop is very annoying and also likely wearing out the batteries incredibly fast.

Issue 2 - API Limits

This morning I woke up and realised that my heating wasn't switching to the right modes when I was in a room, well BT said it was in the new mode, but when I opened Tado I realised the targets had not changed. I also noticed that the above issue had stopped, no valves were moving. I investigated and found that my Tado integration in Home Assistant had stopped working because I had hit my 20k API limit close to 3am. This means that somehow HA and BT had managed to make over 20k requests in 15 hours. This might be related to issue 1 that every single temperature update makes a request to change the valve temperature offset which in turn makes Tado do a full reload of the entire API hitting something like 6-12 API requests. I looked at maybe connecting Tado via HomeKit to HA but then it won't be able to use offset, which I believe is the right way.

Final Questions

BT is a very popular integration and I'm sure there are many many people using it with Tado, so I refuse to believe this is normal or expected else nobody would be able to use it. What am I missing here? Any advice on how I can resolve this behaviour?

I'm currently waiting for 12 for my API limit to reset so I can re-enable everything but I'm suspecting that I'll hit the API limit by the middle of the night again.

For reference my tolerance is set to 0.3 (though I don't think that stops offset changes anyway) and I'm using the default Time AI setting.

Any help greatly appreciated!

EDIT:

I tried switching to using Tado Hijack and one thing I've noticed is that BT keeps trying to set the offset to -10 however the Tado API responds saying the minimum value is -9.99 and throws an error. I can't see a way to make BT not set a lower offset than -10:

Logger: custom_components.tado_hijack.helpers.executor_base
Source: custom_components/tado_hijack/helpers/executor_base.py:123
Integration: Tado Hijack (documentation, issues)
First occurred: 12:20:46 (26 occurrences)
Last logged: 13:52:42

[v5.12.0] Executor failed [offset_VA...37600]: HTTP 422 /api/v2/devices/VA...37600/temperatureOffset. Response: {"errors":[{"code":"min.notmet","title":"Property [temperatureOffset] of class [class com.tado.hardware.valve.RadiatorValve] with value [-10] is less than minimum value [-9.99]"}]} (type: TadoError). Context: {'serial': 'VA...37600', 'offset': -10.0}
[v5.12.0] Executor failed [offset_VA...49824]: HTTP 422 /api/v2/devices/VA...49824/temperatureOffset. Response: {"errors":[{"code":"min.notmet","title":"Property [temperatureOffset] of class [class com.tado.hardware.valve.RadiatorValve] with value [-10] is less than minimum value [-9.99]"}]} (type: TadoError). Context: {'serial': 'VA...49824', 'offset': -10.0}

[XNinety9]

The -10 error in your edit probably explains a large part of both issues. Here is what the code does:

Where -10 comes from. The Tado adapter clamps offsets to ±10 (adapters/tado.py: get_min_offset returns -10, and set_offset does max(-10, offset)). Tado's API only accepts down to -9.99, so whenever BT wants the most negative offset, the write is rejected with the 422 you posted.

Why that becomes a write loop. On each control cycle, utils/controlling.py compares the offset the TRV reports with the one BT last sent (last_calibration, which is -10 after the clamp). The rejected write leaves the reported offset where it was, so BT sees a divergence and sends -10 again on the next cycle, indefinitely. Each attempt is at least one Tado API call, plus whatever refresh your Tado integration does after a write. That fits a 20k quota being gone overnight. The Tado adapter also declares an offset step of 0.01, so on top of that loop, almost every new external sensor reading produces a slightly different offset and therefore a new write.

Why BT is asking for -10 in the first place. A saturated offset means the TRV's own sensor reads ~10 K above your TIMMERFLOTTE. That usually means the valve sits right on the radiator heat. In that situation, offset calibration is already at its limit.

What I'd try:

1. Switch the calibration type to Target Temperature Based for the Tado TRVs (BT device → configure → TRV settings). BT then corrects by moving the TRV setpoint instead of writing offsets. That avoids the -10 rejection entirely and setpoint changes are much coarser than 0.01 K offset steps, so there are far fewer writes.
2. Before re-enabling, reset the offsets on the Tado side to 0. Otherwise the TRVs keep the old large offsets, and target-temperature calibration then has to fight them.
3. If you want to stay on offset mode, the clamp needs to be ±9.99 instead of ±10. That is a two-line change in adapters/tado.py and worth a bug report. It would stop the retry loop, but not the frequent writes caused by the 0.01 step.

The constant valve noise could well be the same thing, since each offset write makes the TRV re-evaluate its position. Once the writes stop, you should hear the difference quickly.

[cl445]

Thanks for the detailed report, and thanks @XNinety9 for tracking it down.

The ±9.99 clamp is fixed: #2862 for 1.9 and #2866 for the 2.0 line. It ships with 1.9.4. That stops the retry loop that writes -10 over and over and gets rejected every time.

The second point from that analysis is also real. BT writes a new offset as soon as the computed value changes on Tado's 0.01 grid, so almost every new reading from your TIMMERFLOTTE turns into a Tado API call. I've opened #2890 to cut that down for cloud TRVs.

Until 1.9.4 is out, switching the Tado TRVs to Target Temperature Based calibration avoids both problems, as XNinety9 suggested. Reset the offsets to 0 in the Tado app first.