Feature Proposal: TadoLocal Open Window Detection

[Bekkie]

Summary

Add local open window detection to TadoLocal-server (and the HA integration) as a replacement for Tado’s HA original integration.

This would detect open windows based on temperature drop behavior and system mode, without relying on cloud services or paid subscriptions.

---

Motivation

I really like the TadoLocal-server solution (both as a Home Assistant add-on and via this integration). It already replaces the native HA Tado integration very well and even adds useful extras (e.g. target temperature as a sensor).

One feature I miss, however, is Tado’s open window detection. I don’t miss it enough to pay for Auto Assist, but I do miss it enough to want a local implementation.

---

Concept

Basic detection principle:

If the climate system is not actively cooling and the room temperature drops unusually fast, a window is likely open.

The detection should be:

• fully local
• configurable per zone
• resistant to false positives

---

Algorithm Inputs

System parameters

• System mode: off | heating | cooling
• Temperature delta between measurements events
• Timeframe between temperature events

User-configurable parameters

• Window open duration
  How long a window remains marked as open
  (Tado app default: 30 minutes)

• Rest period after closing
  Minimum time before another open-window detection is allowed
  (Tado default: 15 minutes)

---

Open Questions

Help is needed to define sensible default thresholds:

• How much temperature drop (ΔT) within what timeframe should trigger detection?

  • e.g. 2 °C in 5 minutes?
  • 1 °C in 20 minutes?

• Should thresholds differ when heating is ON?

  • e.g. 1 °C drop in 5 minutes while heating is active?

• When Cooling mode is ON check for temperature rise

The goal is to detect real open-window events while avoiding false positives.

---

Proposed Data Model Changes

Extend the existing device_state_history data table with:

Field	Type	Description
window	int	0 = closed, 1 = open, 2 = rest
window_lastupdate	timestamp	Time of last state change

Extend the existing zone data table with:

Field	Type	Description
window_open_time	int (min)	Duration window stays open (0–999)
window_rest_time	int (min)	Minimum closed time before re-detection (0–999)

---

Functional Behavior

On temperature update events

• Evaluate new temperature against recent entries in device_state_history
• Decide whether to transition window state to OPEN
  When open window is detected, start timer (window-open duration min.), when the timer expires:
  • If window still is OPEN → switch to REST
• On new temperature updates check if window is still in REST and rest-time expired → switch to CLOSED

---

Proposed API Extensions

Read

• GET /zones

• GET /zones/{id}

  • Add window boolean to state

    • true = window open
    • false = closed or rest

  • Add 2 fields to zone info:

    • window-open int: duration (0-480 minutes)
    • window-rest int: duration (0-480 minutes)

Write

• POST /zones/{id}/windowtimeouts?window_open_time={int}&window_rest_time={int}
  Set for zone {id}:
  • window-open duration
  • window-rest duration

---

Notes

I’m happy to:

• implementation the code,
• i need help define reasonable default thresholds,
• or adjust the proposal to better fit the project architecture.

Feedback on feasibility, algorithm design, and API shape is very welcome.

[Glenbeulah]

Hey @Bekkie,
I'm also looking for reasonable thresholds for open window detection and came across your proposal – great work on the algorithm design! Have you made any progress on the reasonable threshold issue?
I haven't been able to test it myself yet, but here's an idea for finding the right thresholds empirically:
Calibration approach:

• Log temperature and humidity via TadoLocal's SSE stream (which updates every ~10 seconds – much faster than HomeKit)
• Open a window
• Simultaneously monitor Tado's openWindowDetected via the cloud API (using tado_ce with temporarily shorter polling intervals – yes, this costs API calls, but only during a limited calibration phase)
• Record the temperature and humidity delta between the actual window opening and Tado's detection trigger

This way we can effectively reverse-engineer Tado's detection algorithm and derive solid default thresholds from real-world data.
Let me know what you think and share your results for further discussion if you can!
Cheers, Glen

[rhuijben]

In my setup I don't get these notifications from homekit fast enough to do this detection. Happy to see it does work for others...

[Bekkie]

For now i implemented 1 degree temperature drop within 20 minutes with PR #37