Tado X Proxy Thermostat - Temperature Control for Tado X

[kinimod.b (Dominik)]

Hello everyone,

I’d like to share my custom Home Assistant integration: Tado X Proxy Thermostat.

https://github.com/kinimodb/ha-tadox-proxy

With v1.0.0, the first stable community release is now available.

Why this integration exists

Radiator thermostats often measure the temperature very close to the radiator itself. This frequently results in readings that are warmer than the actual room temperature, which can lead to less accurate heating control and reduced comfort.

This integration addresses that problem by creating a virtual proxy thermostat in Home Assistant for Tado X radiator thermostats (TRVs). Instead of relying mainly on the radiator sensor, heating can be controlled using an external room temperature sensor, allowing the system to react to the real room conditions.

How it works

The proxy thermostat adjusts the target temperature of the underlying Tado X thermostat using a combination of:

• Feedforward compensation
• PI control (Proportional–Integral control)

This allows the system to compensate for the temperature difference between the radiator and the room while still working within the normal behavior of the thermostat.

One of the design goals was also to take inspiration from Versatile Thermostat, while adapting the idea specifically to Tado X and its particular quirks. Whether that approach works well in practice is something the community can best judge.

Current features

• Feedforward + PI control
• 6 presets: Comfort, Eco, Boost, Away, Frost Protection, Manual
• Dedicated preset temperature entities
• Window and presence triggers
• Short-dropout sensor resilience
• Option to follow the physical thermostat
• Diagnostic attributes for easier troubleshooting
• Documentation with setup and tuning guidance
• Automated tests with CI

The integration has now been validated across multiple rooms, achieving an accuracy of roughly ±0.3–0.5 °C.

Design goals

Another important goal was to keep the setup compatible with the standard Matter integration that many of us use with Tado X. This means the integration works without requiring additional paid services or a more complex cloud-based setup.

There is also a forum project for a more feature-rich API-based Tado X integration. This project simply takes a different approach and focuses on improving temperature control while staying within the typical local Matter-based setup.

Transparency

To be fully transparent: I’m not a professional developer, just a hobbyist. This project was built through a lot of experimenting, learning, and some AI-assisted coding along the way.

Feedback welcome

If you’re using Tado X with Home Assistant and would like to try external room-temperature-based control, I’d be very happy if you gave it a try.

Feedback, criticism, test reports, and suggestions for improvement are all very welcome — and contributions are of course appreciated as well.

[z1dtwdlc]

Nice one, thank you!
So to get it clearly, this is intended to work with HA thread mesh, not the tado thread network (official, closed and cloud based).

I thought the above is a losing game, but if the basics are exposed and reliably working (no weird dropouts, etc) I will gladly try and migrate. Currently Im using exabird tado x integration.

[kinimod.b (Dominik)]

Thanks! To clarify: ha-tadox-proxy doesn’t care whether your Tado X TRV is connected via Matter (HA Thread mesh) or via a cloud-based integration like exabird’s ha-tado-x. It just needs a working climate.* entity in HA as source, plus an external room temperature sensor.
The proxy sits on top as a control layer: it takes the real room temperature from your external sensor, compares it to the Tado’s internal (inaccurate) reading, and applies a Feedforward+PI correction to the setpoint. That’s the core value — accurate room temperature control instead of radiator surface temperature.
So you can keep using exabird’s integration and add the proxy on top. Or if you ever switch to pure Matter/Thread, the proxy will work just the same.
Regarding stability: I’ve been running it for a while now with good results.Tado X TRVs paired directly via Matter into Home Assistant — fully local, no cloud dependency for the climate control. The Tado Bridge X is still running alongside but the TRVs are controlled through HA’s Matter integration. Tuning might be necessary. The tuning guide (TUNING.md) covers how to dial it in for different rooms.

[z1dtwdlc]

Amazing. Currently Im using mkucharek’s blueprint Homeassistant blueprint to set Tado offset using separate temperature sensor · GitHub
which solves sensor inaccuracy - it adjusts the offset to compensate, so a blunt correction, while your PI control actually closes the loop.

I will add ha-tadox-proxy on top of my existing exabird setup as a temp accuracy layer only (hope I can disable its window and presence features since I already have those covered in my automations).
This gives me the PI control benefit without disrupting anything I’ve built. If it proves stable over a few weeks, then I will consider the full Matter migration to local.

So your proxy creates its own virtual climate entities, right? (eg climate.proxy_dormitor`) that sit on top of the real tado ones. My heating pause/restore automations currently target climate.dormitor directly (one of the rooms example). What I’ll need to check after installing the proxy is whether my automations should continue targeting the underlying tado entity or your proxy entity, so it depend on how the proxy passes through set_hvac_mode: off, if it doesn’t forward it to the underlying entity, my pause automation wont actually turn the heating off. Will see, hopefully I can test this today.

[kinimod.b (Dominik)]

Tado X Proxy Thermostat — Screenshots & Project Update

This is a small follow‑up to my original post. I wanted to share a few screenshots showing the Tado X Proxy Thermostat in actual day‑to‑day use.

Project Update

Since v1.0.2, the documentation is now available in English. With v1.0.3, I’m also hoping the integration logo will appear in HACS.

What the Screenshots Show

The screenshots highlight several parts of the integration:

• the configuration flow, including the required inputs: source climate entity, external temperature sensor, and proxy name

• the options dialog, where you can adjust the proportional and integral correction, configure the boost duration, select the remote sensor, window sensor, and presence sensor, and define the various delays

• the device page, where preset temperatures can be adjusted per room and where the Follow physical thermostat switch is available

• an example of using the integration together with Scheduler / Scheduler Card

• a screenshot from my personal heating dashboard

Example Dashboard Setup

In the dashboard screenshot, I use several badges at the top to indicate key states at a glance — for example whether I’m home, whether the living room window is closed, and whether my ventilation recommendation is currently active.

I also use one card to display humidity from the external sensor and another to show the absolute humidity difference between indoor and outdoor air. This makes it easier to judge whether ventilating the room would actually help with dehumidification.

The thermostat card itself shows the current temperature, target temperature, active preset, and heating state.

Example Schedule

I’m also using the proxy thermostat together with Scheduler. For example, the living room follows a simple schedule:

• Eco from 00:00 to 08:00
• Comfort from 08:00 to 22:00
• then back to Eco

This setup works very well with the proxy thermostat.

Feedback Welcome

This post is mainly intended to give a better idea of how the integration looks in practice.

If there’s interest, I can also share the automation I use for the ventilation recommendation.

Feedback, criticism, test reports, and suggestions for improvement are very welcome.

[z1dtwdlc]

This look really nice! So you’re running tado x fully local, everything working, and your proxy on top? Scheduling with scheduler-card and no API limitations?
Wow, I’m really sold!!!

What are your HA tbrs?
I use a slbz-mr3u dual for z2m and otbr, working nicely. I migrated from a dirigera hub, removed all other 3rd party cloud integrations, only tado remained.
I have a wireless receiver x - wired to my viessmann vitodens opentherm combi boiler, a bridge x, 2 wireless temp sensor x and 6 x trv valve thermostats x.
And why do you keep the bridge x? As a repeater for your HA thread mesh?

I’m not too advanced, my only fear for migrating from tado to ha thread mesh is that I might get stuck somehow and freeze. My wife would kill me

So I will wait sunnier days to fully migrate, anyway it seems soo nice, your project. I often get sign out errors with tado x integration, though it shows I have 1000 api calls and would usually get about 2-300 daily.

Thanks for your work, I will watch it closely and report my experience.

[kinimod.b (Dominik)]

Thanks, glad you find it useful! Your approach makes total sense – layering the proxy on top of your existing setup as a temperature accuracy layer first, then deciding later about a full migration.

Window & Presence: Yes, both are fully optional. If you don’t configure a window sensor or presence sensor during setup (or in the integration options), those features simply don’t activate. So you can keep your existing automations for that without any conflict.

Regarding the proxy entities and your automations: You’re right that the proxy creates its own climate.proxy_* entities that sit on top of the real Tado ones. The important thing to understand: set_hvac_mode: off is forwarded to the underlying Tado entity. So if your pause automation calls climate.turn_off or sets HVAC mode to off on the proxy entity, it will pass that through to the real TRV. You have two options:

1. Target the proxy entity – the proxy forwards the command, and when you turn it back on, the PI control picks up where it left off cleanly.
2. Keep targeting the underlying Tado entity directly – this also works, but the proxy might try to send corrected setpoints while you’ve turned the TRV off, which could cause unnecessary writes.

My recommendation: once the proxy is running, point your automations at the proxy entity. That way the proxy “knows” the state and doesn’t fight your automations.

Let me know how your testing goes – happy to help if anything comes up!

[kinimod.b (Dominik)]

Thanks, glad you like it!

TBR: I’m just running a dongle with OTBR (Open Thread Border Router) in HA — nothing fancy, does the job.

Bridge X: Honestly, I just keep it plugged in as a fallback — if something ever goes sideways with my HA setup, I can still control everything through the Tado app. No real function beyond that, just peace of mind.

Wireless Receiver X: I don’t have one myself, so I can’t speak to how that behaves with Matter vs. the Tado cloud. Since it’s wired to your boiler via OpenTherm, I’d test that one carefully before migrating it — the TRVs are straightforward over Matter, but the boiler receiver might be a different story.

Fear of freezing: Totally get that Just migrate one non-critical room first and let it run for a week. Waiting for warmer days is a smart move anyway — less pressure, and if something acts up, nobody’s cold.

Looking forward to hearing how it goes — and feel free to ping me if anything comes up!

[z1dtwdlc]

Yes, I’m not too sure about the wireless receiver x. It is currently on wifi also, and acts as a tbr same as the bridge x. Will wait a bit more until I try to make the switch to local.

So I added the integration via hacs. Is it to my understanding I need to add as many integrations as rooms I need?

I renamed climate.tado_x_proxy to climate.proxy_bucatarie for the first room. So I need to add the next ones, right? To keep things tidy with my automations I will add also for the rooms I have wireless temp x devices next to the trvs, even though the coordinators are the wireless temp x.

Also, for my pause automation’s save logic, does climate.tado_x_proxy expose manual_control_active and temperature attributes the same way the underlying Tado entity does?
Thank you!

[kinimod.b (Dominik)]

Right, you add the integration and then add one entry for each room:

With Matter/Thread the underlying Tado entity exposes almost nothing:

hvac_modes:
  - "off"
  - heat
min_temp: 5
max_temp: 30
current_temperature: 20.1
temperature: 18.7
current_humidity: 46.2
friendly_name: GZ Tado Thermostat
supported_features: 385

At this point the proxy gives you this:

hvac_modes:
  - heat
  - "off"
min_temp: 7
max_temp: 35
preset_modes:
  - comfort
  - eco
  - boost
  - away
  - frost_protection
current_temperature: 17.9
temperature: 17
hvac_action: idle
preset_mode: eco
regulation_reason: already_at_target
tado_internal_temp_c: 20.1
correction_kp: 0.8
correction_ki: 0.003
effective_setpoint_c: 17
window_open_active: false
window_close_delay_active: false
presence_away_active: false
sensor_degraded: false
room_temp_last_valid_c: 17.9
room_temp_last_valid_age_s: 0
feedforward_offset_c: 2.2
p_correction_c: -0.72
i_correction_c: 0.06
error_c: -0.9
target_for_tado_c: 18.5
is_saturated: false
icon: mdi:leaf
friendly_name: GZ Proxy Thermostat
supported_features: 401

It should be no big deal to add certain attributes.

[z1dtwdlc]

Thank you for this.

So I got things working, the main issue I see is maybe a proxy bug where set_hvac_mode: off doesn’t forward a true off to the underlying entity - just the proxy sends 5°C min instead of true off.

The proxy is off with temperature: 5 and is_saturated: true. So when my pause automation called climate.set_hvac_mode: off on the proxy, the proxy turned off BUT also sent temperature: 5 (its minimum) to the underlying Tado entity before shutting down. The underlying climate.dormitor is still heat with temperature: 5, so Tado is technically on but targeting 5°C, not totally off.

So is this a proxy behaviour issue, like when turned off, it sends the minimum temperature instead of actually calling set_hvac_mode: off on the underlying entity? Or you intended like this?

I corrected it with:

- service: climate.set_hvac_mode
      target:
        entity_id: "{{ climate_entity }}"
      data:
        hvac_mode: "off"

    # Also turn off underlying Tado entity directly
    # Needed because proxy sends 5°C min instead of true off
    - service: climate.set_hvac_mode
      target:
        entity_id: "climate.{{ room }}"
      data:
        hvac_mode: "off"

Also there’s the 30 min / TIMER issue: manual_control_type: TIMER with manual_control_remaining_minutes: 30 - this is the restore still calling tado_x.set_climate_timer somewhere, or your proxy’s own climate.set_temperature call on the underlying entity defaults to a 30 min timer in Tado. This is the same root problem as I had - I opened an issue on exabird for the real fix: [FEATURE] Add requested_overlay parameter · Issue #71 · exabird/ha-tado-x · GitHub
It will work, but as I dont have it locally, it will cost just extra API calls every 30 min. But it seems I’m being allowed 1000 apis instead of the said 100, so for now I’m good.
Can’t wait to fully migrate to local though!
Thanks once more, I appreciate your work!

[z1dtwdlc]

Just to update, why I also keep my automations and don’t go fully proxy mode only, cause I thought about switching.
Your proxy’s window detection:

• Waits configurable delay (default 30s) → switches to Frost Protection preset → on close, waits close-delay (default 120s) → restores previous preset

My automations:

• Wait 90s → save full state (hvac mode, preset, temp, manual override) → turn climate off → on close wait 3 min → restore exactly: hvac mode + preset + manual temperature if applicable

Main thing is the proxy restores to a preset, and the automations restore the exact previous state including manual temperature overrides and also cover multi-sensor rooms (birou has two window sensors), handle door sensors, save/restore across HA restarts, and have the manual override guard.

Maybe you can add some of these, to have a fully integrated solution. I ofc did the details with claude, I am no coder :), but in the end all works as expected, and I could paste it here to take a look into it.

Many thanks once more!!!

[z1dtwdlc]

The automations I use, adapted to your proxy and presets:

- id: universal_window_pause_heating
  alias: Heating - Window/Door Pause (Universal)
  mode: parallel
  max: 20

  variables:
    room: "{{ area_name(trigger.entity_id) | lower }}"
    climate_entity: "climate.tado_x_proxy_{{ area_name(trigger.entity_id) | lower }}"
    prev_hvac: "input_text.{{ area_name(trigger.entity_id) | lower }}_prev_hvac"
    prev_preset: "input_text.{{ area_name(trigger.entity_id) | lower }}_prev_preset"
    prev_temp: "input_text.{{ area_name(trigger.entity_id) | lower }}_prev_temp"
    prev_manual: "input_text.{{ area_name(trigger.entity_id) | lower }}_prev_manual"
    pause_reason: "input_text.{{ area_name(trigger.entity_id) | lower }}_pause_reason"

  triggers:
    - trigger: state
      entity_id:
        - binary_sensor.window_sensor_birou_ls
        - binary_sensor.window_sensor_birou_rs
        - binary_sensor.window_sensor_dormitor
        - binary_sensor.window_sensor_living
        - binary_sensor.window_sensor_bucatarie
        - binary_sensor.door_sensor_bucatarie
      from: "off"
      to: "on"
      for:
        seconds: 90

  actions:
    - condition: template
      value_template: "{{ trigger.to_state.state == 'on' }}"

    - condition: template
      value_template: "{{ states(pause_reason) == '' }}"

    - condition: template
      value_template: "{{ states(climate_entity) != 'off' }}"

    - service: input_text.set_value
      target:
        entity_id: "{{ prev_hvac }}"
      data:
        value: "{{ states(climate_entity) }}"

    - service: input_text.set_value
      target:
        entity_id: "{{ prev_preset }}"
      data:
        value: "{{ state_attr(climate_entity, 'preset_mode') or 'eco' }}"

    - service: input_text.set_value
      target:
        entity_id: "{{ prev_temp }}"
      data:
        value: >-
          {% set t = state_attr(climate_entity, 'temperature') %}
          {{ t | string if t != None else '18' }}

    # Save manual state — "true:<temp>" if preset is none (manual drag), "false" otherwise
    - service: input_text.set_value
      target:
        entity_id: "{{ prev_manual }}"
      data:
        value: >-
          {% set preset = state_attr(climate_entity, 'preset_mode') %}
          {% set t = state_attr(climate_entity, 'temperature') %}
          {% if preset == None or preset == 'none' %}true:{{ t | string }}{% else %}false{% endif %}

    - service: climate.set_hvac_mode
      target:
        entity_id: "{{ climate_entity }}"
      data:
        hvac_mode: "off"

    # Also turn off underlying Tado entity directly
    # Needed because proxy sends 5°C min instead of true off
    - service: climate.set_hvac_mode
      target:
        entity_id: "climate.{{ room }}"
      data:
        hvac_mode: "off"

    - service: input_text.set_value
      target:
        entity_id: "{{ pause_reason }}"
      data:
        value: >-
          {% set sensors = area_entities(room)
            | select('match', 'binary_sensor.*(window|door).*')
            | list %}
          {% set window_open = sensors
            | select('search', 'window')
            | select('is_state', 'on')
            | list | count > 0 %}
          {% set door_open = sensors
            | select('search', 'door')
            | select('is_state', 'on')
            | list | count > 0 %}
          {% if window_open and door_open %}Window & Door Open{% elif window_open %}Window Open{% elif door_open %}Door Open{% else %}Opening Detected{% endif %}


- id: universal_heating_restore_sweep
  alias: Heating - Restore Sweep
  mode: parallel

  triggers:
    - trigger: state
      entity_id:
        - binary_sensor.window_sensor_birou_ls
        - binary_sensor.window_sensor_birou_rs
        - binary_sensor.window_sensor_dormitor
        - binary_sensor.window_sensor_living
        - binary_sensor.window_sensor_bucatarie
        - binary_sensor.door_sensor_bucatarie
      to: "off"
      for:
        minutes: 3

    - trigger: homeassistant
      event: start

  actions:
    - variables:
        rooms:
          - birou
          - living
          - dormitor
          - bucatarie

    - repeat:
        for_each: "{{ rooms }}"
        sequence:
          - variables:
              room: "{{ repeat.item }}"
              climate: "climate.tado_x_proxy_{{ repeat.item }}"
              pause: "input_text.{{ repeat.item }}_pause_reason"
              prev_hvac: "input_text.{{ repeat.item }}_prev_hvac"
              prev_preset: "input_text.{{ repeat.item }}_prev_preset"
              prev_temp: "input_text.{{ repeat.item }}_prev_temp"
              prev_manual: "input_text.{{ repeat.item }}_prev_manual"

          - if:
              - condition: template
                value_template: "{{ states(pause) != '' }}"
              - condition: template
                value_template: "{{ states(climate) == 'off' }}"
              - condition: template
                value_template: >
                  {% set ns = namespace(open=false) %}
                  {% for s in area_entities(repeat.item) %}
                    {% if 'binary_sensor' in s and ('window' in s or 'door' in s) %}
                      {% if states(s) == 'on' %}
                        {% set ns.open = true %}
                      {% endif %}
                    {% endif %}
                  {% endfor %}
                  {{ not ns.open }}
            then:
              - service: input_text.set_value
                data:
                  entity_id: "{{ pause }}"
                  value: ""

              - service: climate.set_hvac_mode
                data:
                  entity_id: "climate.tado_x_proxy_{{ repeat.item }}"
                  hvac_mode: "heat"

              - delay:
                  seconds: 2

              # Restore preset if manual was NOT active
              - if:
                  - condition: template
                    value_template: >
                      {{ not states('input_text.' ~ repeat.item ~ '_prev_manual').strip().startswith('true:') }}
                then:
                  - service: climate.set_preset_mode
                    data:
                      entity_id: "climate.tado_x_proxy_{{ repeat.item }}"
                      preset_mode: >
                        {% set prev = states('input_text.' ~ repeat.item ~ '_prev_preset') %}
                        {{ prev if prev in ['comfort', 'eco', 'boost', 'away', 'frost_protection'] else 'eco' }}

                  - delay:
                      seconds: 1

              # Restore manual temperature if it was active before pause
              - if:
                  - condition: template
                    value_template: >
                      {{ states('input_text.' ~ repeat.item ~ '_prev_manual').strip().startswith('true:') }}
                then:
                  - service: climate.set_temperature
                    data:
                      entity_id: "climate.tado_x_proxy_{{ repeat.item }}"
                      temperature: >
                        {{ states('input_text.' ~ repeat.item ~ '_prev_manual').strip().split(':')[1] | float }}


- id: universal_manual_override_clears_pause
  alias: Heating - Manual Override Clears Pause

  triggers:
    - trigger: state
      entity_id:
        - climate.tado_x_proxy_birou
        - climate.tado_x_proxy_living
        - climate.tado_x_proxy_dormitor
        - climate.tado_x_proxy_bucatarie

  conditions:
    - condition: template
      value_template: >
        {{ states('input_text.' ~ area_name(trigger.entity_id) | lower ~ '_pause_reason') != '' }}

    - condition: template
      value_template: "{{ trigger.to_state.state != 'off' }}"

    - condition: template
      value_template: >
        {% set room = area_name(trigger.entity_id) | lower %}
        {% set prev = states('input_text.' ~ room ~ '_prev_hvac') %}
        {{ trigger.to_state.state != prev }}

  actions:
    - service: input_text.set_value
      target:
        entity_id: "input_text.{{ area_name(trigger.entity_id) | lower }}_pause_reason"
      data:
        value: ""


- id: heating_proxy_schedule
  alias: Heating - Proxy Schedule
  triggers:
    - trigger: time
      at: "06:30:00"
      id: morning
    - trigger: time
      at: "22:30:00"
      id: night

  actions:
    - choose:
        - conditions:
            - condition: trigger
              id: morning
          sequence:
            - service: climate.set_preset_mode
              data:
                preset_mode: comfort
              target:
                entity_id:
                  - climate.tado_x_proxy_birou
                  - climate.tado_x_proxy_living
                  - climate.tado_x_proxy_dormitor
                  - climate.tado_x_proxy_bucatarie

        - conditions:
            - condition: trigger
              id: night
          sequence:
            - service: climate.set_preset_mode
              data:
                preset_mode: eco
              target:
                entity_id:
                  - climate.tado_x_proxy_birou
                  - climate.tado_x_proxy_living
                  - climate.tado_x_proxy_dormitor
                  - climate.tado_x_proxy_bucatarie

[kinimod.b (Dominik)]

v1.0.3 – HVAC OFF Forwarding & Overlay Refresh

Thanks for the great feedback so far! Based on your input, here’s what’s new:

HVAC OFF Forwarding
When you turn the proxy thermostat OFF, it now sends set_hvac_mode(off) directly to the underlying Tado TRV. Previously, it would send a low setpoint (5°C) while keeping the TRV in HEAT mode — meaning it could still heat to frost protection level. Now the TRV actually powers down. Switching back to HEAT reactivates everything automatically.

Overlay Refresh (optional, for cloud-API users)
If you’re using a cloud-based Tado integration (like ha-tado-x) that uses timer-based overlays (default: 30 min), your TRV might revert to its Tado schedule after the overlay expires.

A new optional parameter “Overlay refresh interval” (Settings → Configure) lets you set a periodic resend interval (e.g. 1500s = 25 min) to keep the overlay alive.

Matter/Thread users: leave this at 0 (default). Temperature commands sent via Matter persist permanently — no refresh needed. This is actually great for battery life, since the proxy only sends a command when the setpoint actually changes.

[z1dtwdlc]

Woow, such good news! Excellent, both issues I’ve been fighting are fixed in v1.0.3!

And I successfully passed the first night with 1 migrated valve x to local HA matter.

All seems ok, will gradually make the transition for the other valves as well.
Will keep the Wireless Receiver X on tado thread network until I get some feedback from others (if any) that they did this step and are still alive and kicking Will decomission bridge x as well after trvs full migration, since the receiver x is also a TBR, so fallback to app is still doable.

Yesterday API were ballooning hard, I reached 800 almost till the end of day. So I already cut 25% with 1 room on local, others will follow. Your overlay fix will keep me withing good limits though, and it’s so useful for tado/exabird users who otherwise would exceed the free api limit.

Question though, since I read recently on reddit that tado are rolling out fw updates for hardware, including the valves, upping matter to 1.4, will we do a couple of days switch to tado mesh to get the updates? Or don’t mess with it if it ain’t broken?

Many thanks!

[kinimod.b (Dominik)]

@z1dtwdlc

Question though, since I read recently on reddit that tado are rolling out fw updates for hardware, including the valves, upping matter to 1.4, will we do a couple of days switch to tado mesh to get the updates? Or don’t mess with it if it ain’t broken?

I have no information about the update so don‘t know yet. I might just do the update since I have the bridge running and then see what happens

[kinimod.b (Dominik)]

Tado X Proxy v1.0.4 – Smarter Presence Handling

Small but important fix for anyone using both presence detection and schedule automations together.

The problem: If your presence sensor triggered Away mode and a scheduled automation
simultaneously requested a different preset (e.g. Comfort), the schedule was winning,
effectively canceling Away mode without anyone actually being home.

The fix: Away mode now takes priority. When presence-away is active, any incoming
preset change from a schedule or automation is silently saved and restored automatically
when someone returns home. No more schedules overriding your away preset.

I’m happy to hear if you run into anything.

[z1dtwdlc]

Yes, a week or so ago, they posted saying it would slowly roll out.
Will see if I get updated on the remaining valves
https://www.reddit.com/r/tado/comments/1rq6s5z/firmware_release_2931_for_smart_radiator/

Given the pace of your updates, I have a feeling this will become the go-to solution for many tado users. Wait till it gets some traction!
Grats and Im happy I found your thread in the forums!
I’m on my 2nd valve migrated to HA thread today. All seems ok!!

[kinimod.b (Dominik)]

v1.0.5 – Presence Restore Fix & Flicker Protection

Hi everyone,

I just released v1.0.5 of Tado X Proxy and wanted to share a quick update on what changed in this version.

This release is mainly focused on making presence handling more reliable and fixing a few edge cases around AWAY mode, coming home, and temporary sensor flicker.

---

What’s new in v1.0.5

One of the bigger improvements is a new configurable Home Delay.

The idea is simple: sometimes a presence sensor only changes state very briefly, for example when someone is just passing by the house or when the signal flickers for a moment. Before, this could cause all rooms to leave AWAY mode too early.

With the new delay, the integration waits a bit before restoring the “home” state. The default is 30 seconds, and there is now also a new option in the integration settings:

• Return Home Delay (seconds)

This should make presence-based switching feel much more stable in real-world use.

---

Fixes and improvements

I also fixed a more annoying bug related to state restore during AWAY mode.

In some situations, a short sensor flicker while AWAY was active could overwrite the previously saved room state. The result was that after coming home, some rooms stayed in the AWAY preset instead of returning to the preset they had before. That restore logic is now fixed.

Another important fix is related to BOOST restore.
If BOOST was restored after returning home, it previously could continue running without a proper end timer. In v1.0.5, BOOST now gets its expiration timer correctly again, so it behaves as expected.

There is also an additional fix for Home Assistant restarts while you are away.
In that situation, the integration could accidentally save the currently active AWAY temperature as the value to restore later when you came back home. That could lead to the Comfort preset being restored, but still with the lower AWAY temperature. The fallback now always uses the built-in Comfort default of 20 °C, which should make this behavior much more reliable, especially for users who never manually changed the Comfort target temperature in the UI.

I also added a startup fix for Home Assistant restarts in general.
When Home Assistant comes back up and the AWAY preset is restored, the Presence Controller is now initialized correctly from the start. This should prevent inconsistent behavior directly after a restart.

On top of that, there is also a small safety guard now to prevent the presence automation from being activated twice.

---

In short

This release is less about flashy new features and more about making the presence logic safer, cleaner, and more predictable:

• better protection against presence sensor flicker
• more reliable restore after AWAY mode
• proper BOOST timeout restoration
• correct Comfort fallback after Home Assistant restarts while away
• better behavior after Home Assistant restarts
• extra protection against duplicate automation activation

---

I hope this update makes the presence feature feel a bit more solid and trustworthy.

Feedback is very welcome.

[z1dtwdlc]

Awesome job, thank you for your work!

Though I don’t use these features (yet), will definitely invest a bit in the presence sensors soon, there are so many things we can use them for!

Today I added a bosch smoke alarm 2, working nicely with z2m.
Keep it up, always nice to see your updates!