Tado X Proxy Thermostat - Temperature Control for Tado X

Hi Daniel,

thanks for the incredibly thorough write-up. You basically handed me the root cause on a plate, right down to the exact restore paths. Really appreciate the effort. :folded_hands:

You’re spot on: comfort_target only gets written into the config entry once the Comfort Target number entity is edited at least once. Until then the key is absent, and every Comfort-restore path read it without a default and skipped the update behind if comfort is not None: — so _target_temp stayed stuck on the last frost/eco value even though preset_mode correctly showed comfort. The number entity still shows 20 °C via options.get(key, default), which is exactly why the missing option wasn’t obvious.

What changed: all comfort-target reads now go through a single helper that falls back to the default comfort target (20 °C) when the option was never set. That covers everything you listed — startup restore, window open/close, presence away/home, HVAC off→on, and re-selecting Comfort — plus a latent variant in the boost-restore fallback that could revert to a stale value too. Nothing to reconfigure: it fixes existing setups automatically, and the manual workaround (setting the Comfort Target once) is no longer needed.

This ships in v1.1.6. If you get a chance, let me know it behaves after updating.

Thanks again. Reports like this make the whole thing better for everyone. :+1:

2 Likes

Question to the community: how should the proxy behave while a window is open?

I’d like some input on a design decision before I change anything.

Current behaviour: when the window sensor reports “open” (after the configured delay), the proxy switches to the Frost Protection preset. If you then set a temperature manually or pick a different preset while the window is still open, the proxy immediately falls back to Frost Protection and your change is discarded.

That’s intentional in the sense that window detection currently has absolute priority, similar to how AWAY beats schedules since v1.0.4. But I’m not sure it’s what people actually expect when they’re standing in the room turning up the dial.

What should happen when you set a temperature or preset while a window is open?
  1. Keep it as is. Window open means no heating, full stop.
  2. Manual input wins. Accept it and heat, even with the window open.
  3. Make it configurable, with an option or switch that allows the override, default off.
  4. Something else (I’ll explain in a reply)
0 voters

If we end up at option 2 or 3, there are a few details to decide, so I’d really appreciate a comment on any of these:

  • How should the override end? Automatically when the window closes, after a timeout (say 30 minutes) even if the window stays open, or only when you change it back yourself?
  • Should schedules and automations be able to bypass window detection too, or only a direct user action? My gut says only direct actions, otherwise a scheduled Comfort at 08:00 quietly defeats the whole feature.
  • If it becomes configurable: one global option, or a switch entity per room so you can toggle it from a dashboard?
  • Has anyone actually run into this in practice? Did it annoy you, or were you glad the proxy refused?

Thanks. This one goes either way for me, so the votes and your comments will decide it.

Afternoon,

Before I go ahead and install this, a few questions, if you don’t mind?

I have a Tado X up and running, I’m using the Tado up for scheduling, home/away etc.

Can I replace all that with this integration, or do I still need to use the Tado app and the Tado sub in parallel?

I do have one room with two radiators that is always cold, so I think this virtual thermostat for that area could be exactly what I need! I have Tado X integration by exabird up and running currently.

Lastly any recommended devices I can get in the UK that you know work with your code?

Thanks in advance,

Greg

1 Like

Hi Greg,

happy to answer before you install.

Tado app and subscription

You can drop the subscription. Scheduling is handled by the Scheduler Component from HACS, which has already come up in this thread. It is made exactly for this: send a given preset to a given entity at a given time, one schedule per room, pointed at the proxy thermostat. Actively maintained, no YAML needed. Presence and open window detection are built into the integration, using any binary_sensor for presence and a window contact for frost protection. Those are the two Auto-Assist features, running locally.

I still have the app installed, but I only open it to check firmware versions, and the bridge stays powered as a fallback in case my Home Assistant ever dies. In daily use neither is needed.

Also worth knowing: you can skip exabird’s cloud integration completely and pair the TRVs locally over Matter/Thread. That is the cleanest setup and the proxy defaults are tuned for it. If you do stay on exabird, set Configure, TRV Communication, Overlay refresh interval to around 900 seconds, because that integration uses a 30 minute overlay timer which otherwise expires once the proxy goes quiet.

One rule: in rooms where the proxy runs, switch the Tado schedule off and leave the TRV in Manual. Otherwise two controllers fight each other and the temperature oscillates.

Two radiators

Good fit for this. Add the integration twice, once per TRV, both pointing at the same room sensor. Each loop then works out how much overshoot its own radiator needs, which matters because two radiators in one room are rarely matched. The Scheduler Component can drive both entities from a single schedule entry.

You are not committing to anything up front, so move room by room. Take the least important room first, set it up, let it settle for a few days, then do the next one. Rooms still on Tado carry on as before.

Sensors in the UK

Anything that appears as a temperature sensor entity works. What matters is 0.1 °C resolution and reporting every few minutes or on small changes. Sensors that only report every 15 or 30 minutes are not suitable.

Two worth looking at, both on Amazon UK: the SONOFF SNZB-02P (around £12, ±0.2 °C) and the Aqara Temperature and Humidity Sensor (±0.3 °C). Both are Zigbee, so you need a coordinator such as a SONOFF ZBDongle-E or the Home Assistant Connect ZBT-1. Ignore the “hub required” on the listings, that only applies to the vendor apps, not to Home Assistant. Placement matters more than the model: roughly 1.2 m up, away from radiator, window and door, out of direct sun.

Leave the control defaults alone at first (Kp 0.8, Ki 0.003) and watch the feedforward_offset_c attribute during heat up. Between 1.0 and 5.0 °C is healthy, a negative value means the sensor is catching radiator heat. TUNING.md covers the rest.

Ask away if anything is unclear, and please report back how it goes in that cold room. Feedback from real setups is what the defaults get tuned on.

2 Likes

That’s really helpful thanks, turned out the two temp sensors I had to keep an eye on things were bluetooth enabled, so I’ve added an ESP controller into HA and they are now seen :slight_smile:

So in Tado I have the following areas:

Downstairs : open plan4 TRVs and one Tado thermostat
Study: 1 TRV
Gym: 2 TRVs
Lounge (the cold room): 2 TRVs and now a Govee temp sensor that HA can see
Master bedroom: 1 TRV

Each room comes on/off at different times of day currently in Tado.

So I understand to set up the Proxy thermostat for the lounge, what do I do about all the other rooms so I get the home/away and scheduling features of Home Assistant to work?

1 Like

If I read well your question, you add Tado X Proxy Thermostat as 1 device per room where you have a TRV active. See my screen, 5 rooms with TRVs, 5 proxies integrations, each with their own settings/schedule, etc.

1 Like

Thanks, do you have an external room temp sensor in each of your rooms?

1 Like

Nice, adding the ESP proxy for the Bluetooth sensors was the right move.

The good news is there is nothing new to learn after the lounge. The recipe is the same in every room.

The baseline per room is one temperature sensor plus your TRVs. You create one proxy entry per TRV, and every TRV in a room points at that room’s sensor. That is what fixes the underlying problem: the TRV measures at the valve, right next to the hot radiator, so it shuts off too early. A sensor somewhere in the middle of the room is what makes the control loop honest. Everything else is optional on top.

For your layout that means: Study 1 entry, Master bedroom 1 entry, Gym 2 entries on the same sensor, Lounge 2 entries on the Govee, Downstairs 4 entries on one sensor.

Worth checking for downstairs: if your Tado wall thermostat shows up in HA with its own temperature reading, you can use that as the room sensor for those four entries. It sits in the room rather than on a radiator, so it should do the job and saves you buying another one.

For the remaining rooms a temperature sensor each is the only real shopping list.

Home and away. Build one helper for the whole house and reuse it in every room. Settings, Devices and Services, Helpers, create a Template binary sensor with something like {{ is_state('person.you','home') or is_state('person.partner','home') }}. Mine is a single sensor covering both me and my partner: on while either of us is home, off when the flat is empty. Then set that helper as the Presence sensor in each proxy under Configure and pick your delays. When it goes off, every room drops to its Away preset.

Windows. You need a contact sensor on each window you actually open. If a room has several, make a Binary sensor group helper for that room set to “any”, so it is on when at least one window is open, and use that as the window sensor. Frost protection holds while it is open and your previous preset returns after it closes.

Scheduling. Scheduler Component, one schedule per room pointed at that room’s proxy entities. That replaces the per room timings you have in Tado now. Switch the Tado schedule off for each room as you migrate it, otherwise both controllers fight.

Those helper groups are the only fiddly part of the whole thing. Let me know if you need help. Letting the integration take several window sensors directly is on my list.

1 Like

Thank you for your help answering these questions. Much appreciated​:smiling_face_with_sunglasses:

1 Like

Hello @kinimod.b,

I’m very new to Home Assistant, and I have Tado X thermostats myself. Your add-on is really cool, but I have a question about it. Generally speaking, I can use an automation to tell the Tado device to use the temperature reading from an external sensor instead of its own internal one, right? Or am I mistaken? I realize the add-on offers a lot more than that; I just want to fully understand it first.

Kind regarts.

1 Like

Hi, welcome. Good question.

Short answer: no, this is not possible. A Tado X TRV cannot use the temperature from another sensor. You can only send it a target temperature. No automation can change that.

Here is the problem. The TRV measures right next to the hot radiator. So it thinks the room is already warm, and it stops heating too early. The room stays 1 to 3 degrees too cold.

The Tado app has an offset setting, but a fixed offset does not fix this. When the radiator is cold, the error is small. When the radiator is hot, the error is big. The value keeps changing.

This is what the integration does. It reads your external sensor. Then it calculates a new target and sends that to the TRV. For example: you want 21 degrees in the room, so it may tell the TRV 24 degrees. It checks again every minute and adjusts. It also waits between commands, so the TRV batteries last long.

You do not need to write an automation. You only choose the TRV and the sensor when you add the integration. That is all.

One small note, because you are new to Home Assistant: this is an integration, not an add-on. Add-ons are extra programs. Integrations talk to devices.

Just ask if something is not clear

Thank you for your fast answer.
If I understand your explanation correctly—taking an automation as an example:
Trigger: external temperature sensor drops below 20

Action: turn on Tado thermostat

And then for the switch-off function:
Trigger: external temperature sensor rises above 21

Action: turn off Tado thermostat

…that wouldn’t work as intended, because you’re essentially just telling the Tado to turn on or off, rather than telling it to turn on and heat to 21°C right?
Thanks for clarifying that this isn’t an add-on!

1 Like

Your conclusion is right, and the reason goes one step deeper.

Even if you tell the TRV “heat to 21”, you still do not get 21 in the room. The TRV measures next to the hot radiator. So it stops when that spot reaches 21, and your room is maybe 19. The number you send is not the room temperature. An automation cannot fix this, because the correct number to send keeps changing while the room heats up.

Your questions made me realise something else: my documentation was not doing its job. If you have to ask these things, that is my fault, not yours. So I sat down and rewrote all of it. It now starts very simple and goes deeper only if you want it to.

v1.1.7 is up NOW

Please have a look:

The section “What this integration does” answers exactly what you asked, with a concrete example. If you want the full picture afterwards, there is a “How it works” page linked at the bottom of that table.

There are also translation links at the very top of the page, in case English is not your first language.

Have a read and tell me if it makes sense now. And if something is still unclear, please do ask here. I mean that seriously: if you still have questions after reading it, then the documentation is still not good enough and I want to know about it.

1 Like

Thanks for all the help so far, I’ve now got a Govee in each room.

Can I just check on the setup, the instructions say:

Source Climate Entity Your real Tado X thermostat. It starts with climate.

I have one Tado X thermostat in the whole house, so do I use this for every room, despite the fact it is only in the “downstairs” room?

I’ve created the Lounge Proxy Thermostat, how does that know I have two TRVs in that room?