Remove cloud dependency - local API

[chinezbrun]

I open this topic to have here any ideas / findings on how to remove TADO cloud dependency.
as @hiall-fyi posted there is one in early development: TadoLocal

Anybody try it?

[hiall-fyi]

Thanks for opening this @chinezbrun! Great topic.

I'm definitely interested in local API support, but I'd like to gauge how much demand there is before prioritizing it.

What I'm Currently Working On:

1. Tado CE v1.5.0 - Converting to full async architecture (fixes blocking I/O warnings, better performance)
2. Yale Smart Alarm integration - Another project I'm developing to address this community request

About TadoLocal:

I've seen the TadoLocal project - it's an interesting approach but still early stage. Adding local API support would be a significant undertaking.

I'd Love to Hear From the Community:

👍 If you'd find local API support valuable, please react to this post or comment below!

If there's strong interest, I'd be happy to prioritize this over the Yale Smart Alarm project. But if it's just a "nice to have" for most users, I'll keep it on the backlog while focusing on the current roadmap.

Questions for those interested:

• Would you be comfortable running a local server/proxy?
• Is cloud dependency a dealbreaker for you, or just a preference?
• Have you tried TadoLocal? What was your experience?

Looking forward to hearing your thoughts! 🙏

[hapklaar]

My 2 cts: I would be very interested to see local API support, as much as possible. This makes the integration rely less on the cloud and also limit API calls to the cloud and keep them available for stuff that's not supported locally.

HomeKit supports the local API and I haven't tried TadoLocal yet. Local API support is preferred for me, but that's only because I now have a subscription and have 20k API calls each day. When the subscription ends and I only have 100 API calls, I would pretty much need to use the local API to have any functioning setup.

I was already looking into moving away from Tado, and going the DIYless Smart OpenTherm Thermostat 3 + Sonof TRVZB route for complete local control, but the success and development speed of this project made me decide to put that project on the back burner for a while :)

[chinezbrun]

~ 5 eur / month to have 20k calls limit for a premium product ???
LOCAL !
ready for a local server, ready to test.
i will give soon a try to TadoLocal

[thefern69]

I don't use TadoLocal primarily because I already use the native HomeKit integration and have some automations running of the back of that. Further, HomeKit doesn't support hot water so would need something else anyway.

I did some research a while back but couldn't find out if anybody had reverse engineered the protocol between the Internet Bridge and Tado's cloud. I figure if encrypted we wont learn anything ever, but if plain text, it might be possible to spoof the DNS, route to an end point on your own network running a service that emulates their cloud.

I don't have time to do this right now but it is something I'm interested in.

[hiall-fyi]

I don't use TadoLocal primarily because I already use the native HomeKit integration and have some automations running of the back of that. Further, HomeKit doesn't support hot water so would need something else anyway.

I did some research a while back but couldn't find out if anybody had reverse engineered the protocol between the Internet Bridge and Tado's cloud. I figure if encrypted we wont learn anything ever, but if plain text, it might be possible to spoof the DNS, route to an end point on your own network running a service that emulates their cloud.

I don't have time to do this right now but it is something I'm interested in.

@thefern69 Interesting thoughts on the bridge ↔ cloud protocol! I've been doing some independent research on the bridge hardware recently. Found some promising leads that might be simpler than DNS spoofing. Still early days, but will share more when I have something concrete to show.

Your point about HomeKit not supporting hot water is valid - that's definitely a gap that would need addressing for a complete local solution.

[hiall-fyi]

Thanks for the interest everyone! Great to see the community thinking about this.

I'm slowly getting more interested in the local API concept. Now that v1.5.0 just shipped (async rewrite, 235 tests passing, much more stable foundation), I might spend some time this weekend digging into this and exploring what's feasible.

Will report back with findings!

[hiall-fyi]

Current Findings

The Tado V3/V3+ system uses a dual communication architecture:

1. Bridge ↔ Cloud: TCP/IP over Ethernet (HTTPS to AWS)
2. Bridge ↔ TRV/Thermostat: 868MHz proprietary 6LoWPAN protocol

Available Local APIs

Method	Coverage	Limitations
HomeKit (HAP)	~60%	No heating power %, battery status, open window detection
Matter/Thread	~70%	Tado X hardware only (not V3/V3+)

The Gap

HomeKit only exposes basic thermostat functions. Advanced features like heating power percentage, battery status, and open window detection are transmitted via the 868MHz radio link between TRVs and the Bridge — this data never reaches the HomeKit interface.

PATH to 100% LOCAL PROTOCOL

To achieve full feature parity with Tado Cloud, we need to intercept and decode the 868MHz 6LoWPAN communication between the Bridge and TRVs.

This requires specialized RF knowledge and hardware. Looking for experts or community members who can help with:

1. Capturing 868MHz signals during TRV operations
2. Analyzing modulation and decoding IEEE 802.15.4 / 6LoWPAN frames
3. Reverse engineering Tado's application-layer protocol
4. Building a custom decoder/bridge for Home Assistant

If you have experience with SDR or 868MHz protocols, contributions are welcome!

[wrowlands3]

I use various templates and groups to use the homekit integration to control tado locally, but read heating power % and control/read other things from the tado cloud (originally the core integration, now tado CE). The local tado used to report less regularly than the cloud, of course the cloud is now typically less frequent due to the API changes, but one key problem for myself and many other local users is that the local signal would randomly drop, with the entity becoming unavailable for minutes to hours at a time.

However, controlling that same entity through the cloud would still work, and would normally then lead to the local entity becoming available again. I have found the most common time this has happened is when the temperature from that entity has been flat for a while - I think the local integration may stop reporting if there has been no change to report.

But of course cloud (including the auto setting!) can stop working if there are issues with internet connection.
So my way of ensuring reliable tado control is to control locally whenever possible, with each control change an automation that does a follow-up check to make sure the tado has responded, and if the local entity is unavailable then to control via the cloud entity of the same valve/stat.

This would be my recommendation for incorporating local API into this integration, as well as being able to pull cloud only data like heating power and hot water into the same locally controlled entities.

[hiall-fyi]

@wrowlands3's hybrid approach is exactly what I'm thinking for Phase 1. The plan:

Phase 1: HomeKit Hybrid (future)

• Use HomeKit (via aiohomekit) for local control
• Keep Cloud API for data (heating %, battery, etc.)
• Automatic fallback if local unavailable

Requirements:

• HomeKit setup code from Tado app
• Bridge not already paired to Apple Home (or need to unpair first)

Limitations:

• HomeKit only covers ~60% of features
• Still need cloud for heating power %, battery status, open window detection, hot water

Phase 2: Pure Local (long-term research)

• Investigating 868MHz 6LoWPAN protocol between Bridge and TRVs
• Goal: 100% local, zero cloud dependency
• This is a separate research project, much further out

For now, Tado CE will continue improving the cloud integration. Local support is on the roadmap but still some distance away.

If you're interested in helping with the research, let me know! 🙏

[hiall-fyi]

I did some analysis and pilot on whether it actually saves API calls, and wanted to share the findings:

The Reality of "Cloud-Only" Data

The data we need from cloud with the hybrid model:

• Heating power %
• Battery status
• Open window detection
• Hot water

All of this comes from a single zoneStates API call - which returns data for ALL zones at once.

GET /homes/{homeId}/zoneStates  →  1 API call for everything

So even with HomeKit handling local control, you still need to poll zoneStates regularly to get heating power %, which is the same call Tado CE already makes.

Where Hybrid Actually Saves

Operation	Cloud API	HomeKit Local
Read temperature	✅ (via zoneStates)	✅
Read heating power %	✅ (via zoneStates)	❌ Not available
Read battery status	✅ (via zoneStates)	❌ Not available
Read open window	✅ (via zoneStates)	❌ Not available
Set temperature	✅ (1 call per change)	✅
Set mode	✅ (1 call per change)	✅

Savings: Only the write operations (set temp, set mode) - maybe 10-20 calls/day for typical usage.

For 100 calls/day Users

• Read operations (zoneStates polling) = ~90% of API usage
• Write operations = ~10% of API usage

Hybrid approach saves the 10%, but you still hit the wall on reads.

My Two Cents

The hybrid approach is valuable for reliability (@wrowlands3 fallback strategy is smart!), but won't significantly reduce API consumption for users on the 100 calls/day limit.

For true API savings, we'd need to crack the 868MHz local protocol to get heating power % and other "cloud-only" data locally.

[thefern69]

There's a repo called tado_hijack by @banter240 that looks like it is very similar to what you want to do - use HomeKit when necessary, the API when not. I haven't downloaded it yet but what is intriguing for me is that it seems to work with rather than instead of Apple Home integration. That would be a game changer.

I am sceptical of reverse engineering the local wireless protocol and wonder whether intercepting the cloud calls would be easier but I wish you good luck.

[hiall-fyi]

There's a repo called tado_hijack by @banter240 that looks like it is very similar to what you want to do - use HomeKit when necessary, the API when not. I haven't downloaded it yet but what is intriguing for me is that it seems to work with rather than instead of Apple Home integration. That would be a game changer.

I am sceptical of reverse engineering the local wireless protocol and wonder whether intercepting the cloud calls would be easier but I wish you good luck.

@thefern69 On the reverse engineering point - you're right to be sceptical, it's not trivial!

The reason we need to look at the 868MHz protocol is that the Cloud API doesn't actually talk to the TRVs directly. The architecture is:

TRV ←→ Bridge (868MHz 6LoWPAN) ←→ Cloud (HTTPS)

All the "cloud-only" data (heating power %, battery status, open window detection) travels over that local 868MHz wireless link between TRVs and the Bridge. The Cloud API just exposes what the Bridge has already collected.

So intercepting cloud calls wouldn't help - by the time data hits the cloud, it's already been through the Bridge. To get that data locally without cloud, we'd need to either:

1. Decode the 868MHz protocol - capture what TRVs send to Bridge
2. Query the Bridge directly - if it has any local API (HomeKit is one, but limited)

Option 2 is easier (HomeKit hybrid), but only covers ~60% of features. Option 1 is the holy grail but needs RF expertise.

Still exploring both paths!

[hiall-fyi]

Thanks for the pointer @thefern69!

My preference is to build local support natively into Tado CE rather than depend on external projects. A few reasons:

1. Tighter integration - Can share auth, config, and data structures with existing cloud features
2. Single integration - Users don't need to manage multiple components
3. Maintenance - Easier to debug and update when it's all in one codebase
4. Flexibility - Can implement hybrid fallback exactly how we want it

The goal would be seamless local-first with cloud fallback, all within Tado CE. Still early days on the research side, but that's the direction I'm heading.

Appreciate the suggestion though - always good to know what else is out there!

[thefern69]

Totally understand. Might just give you some HomeKit integration ideas.

[hiall-fyi]

I did crack it down last night. 👯

[thefern69]

last

Missed this. If you did that is fantastic. Excited to see this and happy to test.

[chinezbrun]

I'm currently trying tado_hijack It’s a mix of cloud features and local HomeKit‑based control. Similar to Tado CE 2.0, it has automatic quota management. I have a daily quota of 5000 API calls, and, with this program, I end the day, with around 100 left.

For me, the ideal program would offer full speed for manual actions and confirmations, and a configurable polling system for updates. Still searching :)

[hiall-fyi]

@chinezbrun Glad tado_hijack is working for you! 👍

The hybrid local approach is interesting for reliability (fallback when cloud is down), though as I mentioned earlier, it won't dramatically reduce API reads since heating %, battery status etc. still need cloud.

Happy heating!

[wrowlands3]

Could it be used to continue basic use for when API is limited to 100 calls? I've just checked mine, and it seems the local API reports temperature either every 1 minute or 0.1C change. With those level of readings and being able to control the HVAC settings locally too, it may lose many of the cloud features but at least keeps it a good quality functional climate entity. The 100 API calls can then be reserved for the cloud only things like hot water switching, or as a fallback in case of loss of local connection (this seems to happen if the temperature hasn't changed in an hour or so so no temperature gets reported, leading to homekit thinking it's gone offline which also prevents from sending commands/actions locally)

[hiall-fyi]

@wrowlands3 Good thinking!

Before diving into HomeKit hybrid, you could try Tado CE's Test Mode - it simulates the 100 calls/day limit so you can see exactly how the adaptive polling behaves.

Enable it in: Tado CE Options → Tado CE Exclusive → Test Mode (100 API call limit)

Run it for a few days, then check the v2.0.0 monitoring sensors:

• sensor.tado_ce_polling_interval - current interval
• sensor.tado_ce_api_call_breakdown - which endpoints use most calls
• sensor.tado_ce_call_history - usage patterns over time

This will show you where the API budget actually goes. If there are specific pain points after testing, let me know and we can look at optimizations. Data-driven approach! 📊

[chinezbrun]

@chinezbrun Glad tado_hijack is working for you! 👍

The hybrid local approach is interesting for reliability (fallback when cloud is down), though as I mentioned earlier, it won't dramatically reduce API reads since heating %, battery status etc. still need cloud.

Happy heating!

agree. still, to have a local backup is ok until RF will be decoded.

[hiall-fyi]

@chinezbrun Since you mentioned earlier you'd give TadoLocal a try too - did you end up testing it? Would love to hear your comparison if so:

Questions:

1. Setup complexity - Which was easier to get running?
2. Reliability - Any disconnections or issues with either?
3. Feature coverage - What works locally vs still needs cloud?
4. API savings - How do they compare in reducing cloud calls?

Your real-world feedback would be super valuable for the community (and for planning Tado CE's local support roadmap). No pressure if you haven't had time to compare yet!

[chinezbrun]

@hiall-fyi
TadoLocal is definitely not an easy thing to test :). I’m currently trying tado_hijack, which uses HomeKit devices for local communication/backup.

TadoLocal also requires pairing with the Tado coordinator, and it doesn’t work when HomeKit is already paired… so testing it takes a bit more effort :)

In the meantime, I installed it locally on a Raspberry Pi. It’s not super easy, but if you follow the instructions you can get the server running.

When I have the time and the mood, I’ll remove the current HomeKit setup and give TadoLocal a try ;)

[hiall-fyi]

Hey @chinezbrun!

Thanks for sharing your experience with tado_hijack! I'm curious about the HomeKit hybrid approach.

I've done some initial HomeKit research and understand the basics of what's available locally vs cloud-only. But I haven't actually used tado_hijack myself.

What I'd love to understand about your experience:

1. Control flow - How does tado_hijack decide when to use HomeKit vs Cloud? Is it HomeKit-first with cloud fallback, or something else?

2. Quota savings - You mentioned ending the day with ~100 calls left from 5000. What's driving the savings - is it mainly the write operations (set temp/mode) going local?

3. Reliability - Any issues with HomeKit connection dropping? @wrowlands3 mentioned local entities sometimes go unavailable.

4. Hot water - Since HomeKit doesn't expose hot water, how does tado_hijack handle that?

I'm considering adding HomeKit hybrid support to Tado CE eventually, so your real-world feedback would be helpful!

[chinezbrun]

I really don’t understand how the program manages both. What I’ve observed is that I have a quota of 5000 API calls, and each day I end up with around 1000 remaining without any interruptions. I haven’t tested low‑quota or other scenarios yet. I was surprised to see that the program handled the quota so well. I need more time to articulate the pros and cons.

[chinezbrun]

I really don’t understand how the program manages both. What I’ve observed is that I have a quota of 5000 API calls, and each day I end up with around 1000 remaining without any interruptions. I haven’t tested low‑quota or other scenarios yet. I was surprised to see that the program handled the quota so well. I need more time to articulate the pros and cons.

My daily quota decreased from 5,000 API calls per day to 1,000 API calls per day. Below is an example of how the program managed the lower quota:

[hiall-fyi]

HomeKit Local Control - Proof of Concept Working!

Hey everyone! Quick update on the local API research.

TL;DR: Successfully reading live data from Tado Bridge via HomeKit - no cloud API needed!

What I Tested

Used aiohomekit library to connect directly to the Tado Internet Bridge over the local network. Here's a live snapshot from my setup:

🏠 Live HomeKit Data from Tado Bridge
============================================================
[1] tado Internet Bridge IB{bridge_serial}

[2] tado Smart Radiator Thermostat VA{serial_1}
    🌡️  Current: 19°C
    🎯 Target:  18°C
    💧 Humidity: 60%
    🔥 State:   Off

[3] tado Smart Radiator Thermostat VA{serial_2}
    🌡️  Current: 15.2°C
    🎯 Target:  17°C
    💧 Humidity: 67%
    🔥 State:   Off

... (8 TRVs + 1 Smart Thermostat total)

What Works Locally via HomeKit

Feature	Local (HomeKit)	Cloud API
Current Temperature	✅	✅
Target Temperature	✅ Read/Write	✅
Humidity	✅	✅
Heating/Cooling State	✅	✅
HVAC Mode Control	✅	✅
Heating Power %	❌	✅
Battery Status	❌	✅
Open Window Detection	❌	✅
Hot Water	❌	✅
Schedules	❌	✅

Key Findings

1. Pairing works - Bridge accepts HomeKit pairing via aiohomekit
2. All TRVs visible - Each TRV appears as a separate accessory with full thermostat service
3. Real-time data - Temperature updates every ~1 min or on 0.1°C change
4. Write operations work - Can set target temperature and HVAC mode locally

What This Means for Tado CE

As I mentioned earlier, hybrid mode won't dramatically reduce API reads (heating %, battery etc. still need cloud). But it does provide:

• Reliability - Local fallback when cloud is down or rate-limited
• Faster writes - Set temperature/mode without cloud round-trip
• Reduced write API calls - Every local write = 1 less cloud call

Next Steps

I'm considering adding optional HomeKit hybrid support to Tado CE. The architecture would be:

• Local-first for writes (set temp, set mode)
• Cloud for reads (heating %, battery, schedules, hot water)
• Automatic fallback if local unavailable

Still early days - need to think through the config flow, error handling, and edge cases. But proof of concept is solid!

Anyone else interested in testing this? Would love to hear from users who've tried tado_hijack or TadoLocal for comparison.

[wrowlands3]

I'm happy to help test this, I haven't used tado_hijack of TadoLocal custom repositories though, just homekit.

[hiall-fyi]

Here's the plan for integrating HomeKit local control into Tado CE.

Overview

The goal is local-first, cloud-fallback - use HomeKit for fast local operations while keeping cloud API for data that's not available locally.

┌─────────────────────────────────────────────────────────┐
│                    Tado CE Hybrid Mode                  │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   ┌─────────────┐         ┌─────────────┐              │
│   │  HomeKit    │         │  Cloud API  │              │
│   │  (Local)    │         │  (Remote)   │              │
│   └──────┬──────┘         └──────┬──────┘              │
│          │                       │                      │
│          ▼                       ▼                      │
│   ┌─────────────┐         ┌─────────────┐              │
│   │ Temperature │         │ Heating %   │              │
│   │ Humidity    │         │ Battery     │              │
│   │ HVAC State  │         │ Open Window │              │
│   │ Target Temp │         │ Hot Water   │              │
│   │ HVAC Mode   │         │ Schedules   │              │
│   └─────────────┘         └─────────────┘              │
│                                                         │
│          └──────────┬───────────┘                      │
│                     ▼                                   │
│            ┌───────────────┐                           │
│            │  Merged Data  │                           │
│            │  to HA Entity │                           │
│            └───────────────┘                           │
│                                                         │
└─────────────────────────────────────────────────────────┘

Prerequisites

Before you can use HomeKit Hybrid Mode:

1. Tado Internet Bridge - Must be on your local network
2. HomeKit PIN - Found in Tado app → Settings → Rooms & Devices → Internet Bridge
3. Not paired to Apple Home - Bridge can only pair to ONE HomeKit controller at a time
   • If already paired to Apple Home, you'll need to unpair first
   • Or use a secondary Bridge if you have one

What Works Locally (HomeKit)

Feature	Read	Write
Current Temperature	✅	-
Target Temperature	✅	✅
Humidity	✅	-
Heating/Cooling State	✅	-
HVAC Mode (Heat/Off/Auto)	✅	✅

What Still Needs Cloud API

Feature	Reason
Heating Power %	Not exposed via HomeKit
Battery Status	Not exposed via HomeKit
Open Window Detection	Cloud-side algorithm
Hot Water Control	Not a HomeKit accessory
Schedules/Timetables	Cloud-only feature
Geofencing	Cloud-only feature

Implementation Flow

Phase 1: Setup

1. User enables "Local Control (HomeKit)" in Tado CE options
2. User enters HomeKit PIN from Tado app
3. Tado CE pairs with Bridge using aiohomekit
4. Pairing credentials stored securely in .storage/tado_ce/

Phase 2: Runtime

1. On startup, Tado CE connects to Bridge via HomeKit
2. For reads: Try local first → fallback to cloud if unavailable
3. For writes: Try local first → fallback to cloud if unavailable
4. Cloud API still polled for heating %, battery, etc.

Phase 3: Monitoring

• New sensor: sensor.tado_ce_local_status (connected/disconnected/unavailable)
• Existing sensors continue to work with merged data

Known Challenges

1. Serial Number Mapping

   • HomeKit identifies devices by serial (e.g., VA1234567890)
   • Cloud API uses zone IDs
   • Need to match serials to zones on first setup

2. Connection Stability

   • HomeKit connections can timeout after periods of inactivity
   • Need robust reconnection logic

3. Single Pairing Limitation

   • Bridge only accepts one HomeKit controller
   • Users with Apple Home integration need to choose

4. Network Requirements

   • HA must be on same network as Bridge (or have route to it)
   • Some users have IoT VLANs that may complicate this

Benefits

• Faster response - Local writes don't need cloud round-trip
• Reliability - Works even if Tado cloud is down
• Reduced API calls - Local reads don't count against quota
• Privacy - Temperature data stays local

Questions for Testers

If you're interested in testing this when it's ready:

1. Do you have your HomeKit PIN? (Check Tado app)
2. Is your Bridge paired to Apple Home? (Would need to unpair)
3. Is HA on the same network as your Bridge?
4. How many TRVs/thermostats do you have? (For testing scale)

Let me know in the comments if you'd like to be a beta tester!

[wrowlands3]

I'd like to be a beta tester! Let me know what to do.

1. I have the PIN
2. It's currently paired so I will unpair it
3. It's on the same network
4. I have 11 TRVS and 3 thermostats across 9 zones

[hiall-fyi]

Hey everyone! Quick update on the HomeKit local control roadmap.

Multi-Home First, Then HomeKit

After deep-diving into the codebase to plan the HomeKit integration, I realized there's a prerequisite that needs to happen first: proper multi-home support (Issue #110).

Here's why:

The HomeKit integration requires a Data Source Abstraction Layer — a router that sits between entities and data sources (Cloud API, HomeKit, and potentially Local API/Matter in the future). When I started designing this, I found that the same code that needs refactoring for HomeKit (data_loader.py, the coordinator, per-entry context) is exactly the same code that blocks multi-home support.

Right now, data_loader.py uses a global variable for the home ID — which means if you add a second Tado account, the second one overwrites the first. Fixing this is a prerequisite for the Data Source Router anyway, so it makes sense to do it first rather than build HomeKit on top of a known architectural limitation.

The Plan

1. Multi-Home Support (next) — Refactor global state to per-entry context, enable multiple Tado accounts
2. Data Source Router — Build the abstraction layer on top of the clean per-entry architecture
3. Entity Migration — Migrate entities to use the router (pure refactor, no new features)
4. HomeKit Integration — Add HomeKit as a data source, with local-first + cloud-fallback

Timeline

Multi-home should land in the next couple of weeks. HomeKit integration is targeting April. The proof of concept is already working (as shared earlier), so the remaining work is mainly architecture and testing.

For those waiting on multi-home (#110, #145) — this is coming soon! And it directly enables the HomeKit work.

@wrowlands3 I haven't forgotten about your beta testing offer! Will ping you when there's something to test. 🙏

@chinezbrun Thanks for the ongoing feedback on tado_hijack — your real-world experience has been valuable for planning the hybrid approach.

[chinezbrun]

Hi! Thanks for the technical explanations above.

Independence and communication speed are important to me, so moving from cloud-based control to a local setup seems like the right direction. A limit of 100 API calls per day is not sufficient in practice—receiving updates only after 2, 5, or 10 minutes (e.g. Heating % or Open Window detection) just to save API calls is not viable.

That said, I’m still looking for a more practical understanding of the available alternatives. Below is my current situation:

• Tado_CE: current status: on hold (waiting for further development).

• Tado_hijack: Uses HomeKit (local commands) plus the API for the remaining functionality, with automatic quota management.
  Current status: this is my main integration for automation. Overall, it has been a good experience, even after the reduction from 5000 to 1000 API calls per day. We’ll see what happens in March, when the limit drops to 100.

• TadoLocal: A local server that mimics the Tado cloud and exposes a local API. To make it work, Apple Home needs to be unpaired.
  Current status: the server is installed and running, but I haven’t decided yet whether to unpair Apple Home (HomeKit).

[chinezbrun]

Hi, I’ve started using the TadoLocal server together with the Tado_Local Home Assistant integration.

Quick update so far:

• Installation: medium difficulty (installed on a Raspberry Pi in a virtual env). Following the commands worked fine. After removing Apple Home / HomeKit pairing, the server starts and the logs are clear/transparent (commands + echo).
• Runtime: still early, but initial impression is that it’s slower than I expected -> update: is a HomeKit protocol limitation not a TadoLocal issue
• Features: Nice Web interface - similar with Tado app, heating [on/off] as a local feature

From what I can see, TadoLocal still appears to interact with the Tado cloud:

• During installation there is an authentication step against Tado cloud.
• During runtime I see periodic “Sync with Tado Cloud” messages in the logs.

I’m trying to understand:

1. What data is synced from the cloud, and at what interval? update: Metadata sync: Cloud API refreshed every 4 hours for battery status and zone names
2. Are these syncs optional or configurable (disable/reduce frequency)? update: not yet
3. Do these syncs use the official Tado cloud API endpoints (and therefore potentially count toward rate limits)? update: YES, ~ 7API /day

[hiall-fyi]

Thanks for the detailed TadoLocal update @chinezbrun! Really useful real-world data.

The cloud sync every 4 hours for battery/zone names is interesting — confirms that even TadoLocal isn't fully "local" yet. And the fact that those syncs count toward rate limits is worth knowing.

This aligns with our planned hybrid approach for Tado CE: use HomeKit for local control (reads + writes) while keeping cloud API for the data that HomeKit can't provide (heating %, battery, open window, hot water). The goal is to minimise cloud dependency without pretending we can eliminate it entirely.

Appreciate you being the guinea pig on these different approaches — your comparisons between tado_hijack and TadoLocal have been really valuable for planning! 🙏

[ChrisMarriott38]

Few thoughts.

Connection Stability

HomeKit connections can timeout after periods of inactivity
Need robust reconnection logic
I have on the odd occasion seen a device go unavailable but they self reconnect after a short time.

Privacy - Temperature data stays local

Tados app if linked still spams back to them your data at 1min rate. The public api is alongside their official link. So i guess you'd have to fully delink their devices and only use homekit for privacy reasons.

[hiall-fyi]

@ChrisMarriott38 Thanks for sharing your thoughts!

On connection stability — noted, we've got reconnection logic planned for the HomeKit integration.

On privacy — good point. Tado app actually uses FCM push notifications (server pushes to app) rather than constant polling, so it's probably not reporting at a 1-min rate. The 1-min updates are more likely the HomeKit local protocol between the bridge and HA. But you're right that data still flows to Tado's servers as long as the app is linked — worth documenting clearly.

[ChrisMarriott38]

@hiall-fyi Hoenstly i've not seen unstable nature for a long time. I'll check the sensors but they feel like they have been very reliable for me in the HomeKit.

Back on privacy - So i think the only way to go fully local (ie keep your data), is still to remove tado app, and also block any outbound tado.

This over 24h is about 1 per minute to hit 1311

I know it's 1 minutes because i run Ad Guard and i can see thousands of tado calls per day. Not from the HA tado-ce

I should probablly set up an automation, for the HomeKit ones, and a Count helper that detects and counts if they go unavailable to see if its any kind of problem.,

[hiall-fyi]

@ChrisMarriott38 Great observations on the AdGuard data! I did some independent analysis to dig deeper into what the Bridge is actually doing on the network.

Bridge Traffic Capture (86 minutes via MikroTik packet sniffer)

I used a MikroTik router's built-in packet sniffer to capture all traffic from the Tado Internet Bridge for ~86 minutes. Here's what I found:

Single persistent connection to Tado Cloud:

Metric	Value
Cloud Server	34.254.135.143 (AWS eu-west-1, Ireland)
Protocol	TLS/HTTPS (port 443)
Connection Type	Single persistent TCP connection
Bridge data packets (with payload)	848 in 86 min
Avg interval between sends	~6 seconds
Estimated exchanges per hour	~589
Estimated exchanges per day	~14,000
Data sent (Bridge to Cloud)	~67 KB / 86 min
Data received (Cloud to Bridge)	~56 KB / 86 min

Other traffic observed:

• DHCP lease renewals (12 packets) - normal network housekeeping
• mDNS broadcasts (6 packets) - HomeKit accessory advertisement (_hap._tcp.local)

Key Findings

1. The Bridge maintains a single long-lived TLS connection to AWS eu-west-1. It doesn't open new connections for each exchange - it keeps one persistent TCP session open.

2. Communication pattern appears to be:

   • ~30s keepalive heartbeats (small 35-byte packets)
   • Periodic data exchanges every few seconds (100-133 byte payloads, likely sensor readings)
   • Occasional larger exchanges (~115 bytes, possibly state change reports)

3. All traffic is TLS encrypted - so we can see the timing and volume but not the actual content being sent.

4. Your AdGuard count of ~1,311/day is likely counting DNS queries rather than TCP data exchanges. The actual TCP-level communication is much more frequent (~14,000 exchanges/day). The DNS queries would be less frequent since the Bridge reuses the same TCP connection.

5. Total data volume is tiny - roughly 67 KB up + 56 KB down per 86 minutes, which extrapolates to about ~1.3 MB up + ~1.1 MB down per day. Not a bandwidth concern, but it is constant phone-home behaviour.

Privacy Implications

You're absolutely right that removing the Tado app alone isn't enough for privacy. The Bridge itself is the primary data sender - it reports sensor data to Tado's cloud roughly every 6 seconds regardless of whether the app is installed.

To truly go local-only, you'd need to:

1. Block the Bridge's outbound traffic at the router/firewall level (block 34.254.135.143 or all outbound from the Bridge)
2. Accept that cloud features (heating %, schedules, geofencing) will stop working
3. Rely entirely on HomeKit local protocol for control

How to Reproduce

If anyone wants to capture their own Bridge traffic, here's how on a MikroTik router:

# Set up packet sniffer (replace [BRIDGE_IP] with your Bridge's IP)
/tool/sniffer/set filter-ip-address=[BRIDGE_IP]/32 file-name=tado_bridge streaming-enabled=no memory-limit=100000KiB

# Start capture
/tool/sniffer/start

# Wait 60+ minutes, then stop
/tool/sniffer/stop

# Download tado_bridge.pcap from Files in WinBox
# Analyze with Wireshark or tcpdump

Note: The sniffer must run on the router that is the Bridge's default gateway (the one it routes internet traffic through).

[hiall-fyi]

Hiya everyone, wanted to circle back on this one since it's been open for a few months now.

When @chinezbrun opened this discussion back in January, we were exploring whether local control was even feasible. That kicked off a bunch of research — HomeKit protocol analysis, bridge traffic captures, comparisons with tado_hijack and TadoLocal — and a lot of great input from @hapklaar, @wrowlands3, @thefern69, @ChrisMarriott38, and @chinezbrun.

The good news: HomeKit local control shipped in v4.0.0-beta.1 (April 12) and has been refined through to v4.0.0-beta.7 (shipping now). Here's where we landed vs the original plan from this thread:

What we said we'd build (Comment #16):

• ✅ Local-first for writes (set temp, set mode) — done, with automatic cloud fallback
• ✅ Cloud for reads (heating %, battery, schedules, hot water) — done, with reduced polling when HomeKit is connected
• ✅ Automatic fallback if local unavailable — done, including reconnect with backoff
• ✅ HomeKit PIN setup via config flow — done
• ✅ Connection monitoring sensor — done, with write stats, fallback counts, and response times
• ✅ Pairing credentials stored securely — done, in HA's built-in storage

What we didn't expect but ended up building:

• Real-time temperature push from the bridge (not just writes — reads too)
• HomeKit saves tracking (how many API calls avoided)
• Cloud verification of HomeKit writes (catches silent failures)
• Humidity source prioritisation (cloud preferred over bridge due to stale caching)
• Smarter polling that stretches intervals when HomeKit is providing live data

In real-world testing with 9 zones on the 4.0.0-beta.5 and 4.0.0-beta.6, daily API usage sits comfortably under 68 calls with HomeKit connected — down from ~394 on cloud-only. Even with multiple HA restarts and debug logging enabled during the same day, it stayed well under the 100/day limit. For users worried about the API quota, this is the answer we were looking for.

What's still cloud-only (as expected from the start): heating power %, battery status, open window detection, hot water, schedules, geofencing. These need the 868MHz protocol work (Phase 2 from Comment #7), which is a much bigger research project and not on the immediate roadmap.

I'm going to close this discussion since the Phase 1 hybrid approach is shipped and stable. If anyone wants to pick up the 868MHz research for Phase 2 (full local, zero cloud), that deserves its own discussion.

Thanks to everyone who contributed to this thread — the real-world feedback from tado_hijack and TadoLocal testing, the beta testing offers, and the bridge traffic analysis all helped shape what we ended up building. 🙌