🏠 HomeKit Local Control — Looking for Early Testers #219
Replies: 57 comments 103 replies
-
|
Absolutely, I'm on it! |
Beta Was this translation helpful? Give feedback.
-
|
Seems very promising! My Tado bridge and AC controller are already paired using the HomeKit device integration. Since repairing the AC controller was quite a pain, is it possible to use the existing HomeKit integration directly? Thanks for the great work! |
Beta Was this translation helpful? Give feedback.
-
|
Hey @tonicb78, cheers for the kind words! Unfortunately no — Tado CE manages its own HomeKit connection and can't piggyback on the existing HomeKit Device integration pairing. They're completely separate under the hood. The reason I built it this way is that there's a lot of Tado-specific optimisation baked into the connection. Tado CE automatically maps HomeKit accessories to your Tado zones by matching serial numbers against the cloud API, maintains an in-memory cache with timestamps so it knows exactly how fresh each reading is, subscribes to real-time events from the bridge so temperature changes arrive instantly, and runs a periodic cache refresh in the background to catch values the bridge doesn't push. On top of that, the coordinator merges local and cloud data with a priority system (external sensor > HomeKit > cloud), routes writes through the local path first with automatic cloud fallback, and tracks how many API calls HomeKit saved you throughout the day. If you went through a generic HomeKit integration, none of that would be possible — you'd just get raw HomeKit entities with no awareness of Tado zones, schedules, overlays, or the cloud API. You'd need to unpair the bridge from the HomeKit Device integration first, then pair it through Tado CE. The bridge only accepts a new pairing when it has no existing controller, so there's no way around that step. The AC controller is a different story though. Tado CE's HomeKit support only talks to the bridge (the IB device), not individual TRVs or AC controllers directly. So if your AC controller is paired separately to the HomeKit Device integration, that pairing can stay — Tado CE won't touch it. You'd only need to unpair and re-pair the bridge itself. That said, once Tado CE is paired with the bridge, it handles AC zones too (local temperature reads, and simple temperature writes for AC). Fan speed, swing mode, and HVAC mode changes still go through the cloud for AC — HomeKit doesn't expose those controls on the Tado bridge. So the steps would be:
Let me know if you need help figuring out which device is which in your HomeKit Device integration setup! |
Beta Was this translation helpful? Give feedback.
-
|
Actually, to give you a better idea of what the integration is doing under the hood — here's what a typical 7-minute window looks like on the live setup this morning: Zone 1 went from 16.5°C to 17.5°C over those 7 minutes and you can see every 0.1°C step as it happens — the bridge pushes each change within seconds. With cloud-only polling you'd get one reading every 5 minutes and miss all of that detail. Three things happening here that a generic HomeKit integration wouldn't give you:
All of this needs tight coupling between the HomeKit layer and the Tado coordinator, which is why I can't just hand it off to a separate integration. The tradeoff is one re-pair, but after that it's fully automatic. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the detailed explanation! That clarifies things a lot, sounds like the right way to go. I will have to gather some courage and try the AC controller pairing again 😅 Last time it was not exactly smooth, but now at least I know what to expect. I will report back once I give it another shot! Just to clarify on this point, the AC controller and the Tado bridge are two separate HomeKit accessories, each requiring its own individual pairing. So re-pairing the bridge alone won't be enough if you also want the AC controller integrated; that one needs to be paired separately as well. That's exactly what made it tricky last time! |
Beta Was this translation helpful? Give feedback.
-
|
@tonicb78 you actually don't need to re-pair the AC controller at all! Tado CE only pairs with the bridge (the IB device). Your AC controller can stay exactly where it is in the HomeKit Device integration, completely untouched. So the only step is unpairing the bridge from Apple Home / HomeKit Device integration, then pairing it through Tado CE. The AC controller pairing you struggled with last time? You can leave that alone entirely. Once the bridge is paired, Tado CE handles your AC zones too — local temperature reads come through the bridge, and simple temperature writes go local as well. Fan speed, swing, and mode changes still route through the cloud, but that's a HomeKit limitation on the Tado side, not something we can work around. The short version: one re-pair (bridge only), zero touching the AC controller. Should be much less painful than last time! 😄 Let me know how it goes. |
Beta Was this translation helpful? Give feedback.
-
HomeKit Polling Optimization — Live LogsBefore Deploy (old code — no skip logic)Every poll cycle fetches zoneStates from Tado cloud, even though HomeKit is providing live local data: Deploy + Restart (11:56)After Deploy (new code — skip logic active)Cloud data only fetched once every 30 minutes. Between fetches, HomeKit provides live local data: HomeKit Local Activity (running throughout)Cache refresh every 2 minutes keeps local data fresh, bridge pushes temperature changes in real-time: Summary
|
Beta Was this translation helpful? Give feedback.
-
|
Quick update on how things are looking after ~28 hours of HomeKit running on the live setup. I pulled the actual API call history and the numbers are pretty telling. Here's the last week side by side:
April 10 is a split day — the skip logic was deployed around 11:00 UTC. You can literally see it in the call history: every 5 minutes before deploy, then immediately drops to every 30 minutes after. April 11 is the first full day with HomeKit active and it's sitting at 29 calls so far. The HomeKit sensor is reporting 171 reads and 22 writes handled locally today alone. That's 193 API calls that never left the local network. And the writes are the interesting part — every single overlay change (temperature adjustments, mode switches) went through HomeKit locally. Zero write calls to the Tado API. For context, the March daily average was ~394 calls. We're now looking at maybe 50–80 calls for a full day once things settle. That's roughly an 80–85% reduction in API usage, and the data is actually fresher — HomeKit pushes temperature changes in real-time instead of waiting for the next 5-minute poll. Still early days, but the gut feeling is solid. HomeKit local control is doing exactly what we hoped — keeping the Tado bridge conversation local and only touching the cloud for things that genuinely need it (schedules, geofencing, hot water, etc.). What if Tado drops the API limit to 100 calls/day?Here's what the two worlds look like. Without HomeKit — it gets tight. The integration's adaptive polling would kick into Smart Day/Night mode to stretch the quota across 24 hours. Realistically you'd be looking at polling every 13–18 minutes during the day and every 2 hours at night. That's your temperature data being up to 18 minutes stale during the day. And every manual adjustment (changing temperature, switching modes) eats into that same 100-call budget — 10 adjustments across the day means 10 fewer temperature polls. If you have weather or mobile device tracking enabled, each poll costs 2–3 API calls instead of 1, which pushes the interval to 36–55 minutes between updates. At that point you're basically flying blind for long stretches. Automations that react to temperature changes would be working with data that's potentially 15–20 minutes old. Not great if you're doing anything time-sensitive. With HomeKit — you barely notice. Temperature and humidity still arrive in real-time via the local bridge connection. The cloud sync (for schedules, overlay status, geofencing) drops to once every 30–120 minutes depending on your setting, using maybe 12–48 of those 100 calls. The rest is headroom for writes and other operations. The key difference: writes go local. Setting temperature, switching heat on/off — those don't touch the API at all for heating zones. So your 100 daily calls are purely for cloud-only data, not for basic climate control. Here's the rough comparison:
The short version: without HomeKit, 100 calls/day means your HA dashboard is showing temperatures that could be 15–20 minutes old and every thermostat adjustment makes it worse. With HomeKit, your temperatures are still real-time and you've got plenty of API budget left over for the cloud-only stuff. It's the difference between "barely functional" and "you wouldn't even know there's a limit." I'm still doing final code revisions — cleaning up logging, cache handling, persistent storage, and the timeline target is still Monday 13 April or Tuesday 14 April for the dev build. Hang tight! |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
The dev build is up — v4.0.0-beta.1 is available now as a pre-release on GitHub. What's in itEverything from the earlier posts plus a few extras that came together this week:
One heads-up: connection sensors and the hot water power sensor have moved from How to install
If you're already paired with Apple Home, you'll need to unpair from there first — HomeKit only allows one controller at a time. You can re-expose climate entities to Apple Home via the HA HomeKit Bridge integration afterwards. Debug logginglogger:
default: warning
logs:
custom_components.tado_ce: debugWhat I'm looking forSame as before — different zone counts, bridge restarts, long-term stability, AC zones. Any feedback is gold. I'll be away tomorrow (birthday 🎂) so won't be responding until Tuesday. But don't let that stop you from posting — I'll catch up on everything when I'm back. cc @donnie-darko @hapklaar @ChrisMarriott38 @tonicb78 — the build you've been waiting for! |
Beta Was this translation helpful? Give feedback.
-
|
@hiall-fyi in doing testing of the beta with my window mode blueprint I think I may have found an issue in updating the climate entity state: These are the logs I get when calling the I can see that the device updates correctly in the tado app to show the 5.0°C overlay, however the Tado CE home assistant entity states don't change to reflect this - is it expected that they would reflect an overlay is active? state: attributes: When calling I have HomeKit paired successfully and I can see it is using it as the source for the temperature and humidity values. |
Beta Was this translation helpful? Give feedback.
-
|
Nice catch @jeverley, and thanks for the detailed logs — made it easy to track down. You're right, the entity state should update immediately after The other overlay services ( Good to hear the blueprint is working well otherwise — the pairing and temperature/humidity sourcing all looks solid from your logs. |
Beta Was this translation helpful? Give feedback.
-
|
Quick update on this @jeverley — I did a sweep of all the service handlers and it turns out All fixed now — they'll all trigger an immediate refresh in the next beta. Thanks again for catching it, would've been a lot harder to track down without your logs. |
Beta Was this translation helpful? Give feedback.
-
|
Happy to help! Glad we pinned down those other missing calls. |
Beta Was this translation helpful? Give feedback.
-
|
@hiall-fyi Happy birthday! Hope you have a great day celebrating! So just to confirm in HA i have the Tado bridge added to the HomeKit integration. 
So do i need to Delete it like this? 
Then Add it via Tado CE? Does it have the option and create the same naming conventions? My thinking is the existing heating controller system i setup is based on the names. So i'm wondering if TADO CE lets you change the names in again so i can match them up so it all works as it does now? Going from 5 minute updates to 1s updates will be incredible. I think the Biggest of all bonus's here. Will be FAR FAR FAR superior open window detection. Actually far better than Tado's own implementation. And if there was a sensitivity option given the update speed is faster it would be a really responsive system. I noticed the Temp is faster updates. By any chance is Humidity faster also? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the birthday wishes! 😄 Yep, that's exactly right — delete the Tado bridge from the HomeKit Device integration (the "Remove" button you've got there), then pair it through Tado CE instead. The bridge needs to have no active controller before Tado CE can pair with it. On the naming — Tado CE names climate entities based on your Tado zone names (the ones you set in the Tado app), not the HomeKit accessory names. So And yes — humidity comes through at the same speed as temperature. To give you the full picture of how the data layers work together, there are three things running:
So the 5-minute number you're used to is the cloud polling interval — that's the slowest layer and only handles cloud-only data now. The actual temperature and humidity data arrives in real-time via the bridge push, with the 2-minute cache refresh as backup. You're spot on about window detection — with the bridge pushing changes in real-time instead of waiting for a 5-minute poll, the temperature drop from an open window shows up almost immediately. Your patio door scenario from Discussion #184 would be a completely different story with this feeding the data. |
Beta Was this translation helpful? Give feedback.
-
|
So i just removed the HomeKit part. I upgraded Tado CE to beta 4.0.0-beta1 It remmebered i had already entered the Tado Bridge. And had "Internet Bridge toggled ON" I just toggled onHomeKit Entered PIN So far so good. How do you fully know if it's linked and paired and working? Do you see any extra entities of confirmations? Or is it all behind the scenes? Or is it more i'll see the data being more responsive? It says HomeKit connected under the Tado screen 
|
Beta Was this translation helpful? Give feedback.
-
|
Also in terms of heating. I'm trying to work out how my automation can now link with Tado CE. 
before those 5 conditions would check if the HVAC mode was off. Then it would apply the base temp to the thermostat as needed. action: climate.set_temperature Wondering how best to apply this now. Do i just link it to the entities in Tado CE? And that will action it locally? |
Beta Was this translation helpful? Give feedback.
-
|
Looks like you're all set! That "HomeKit connected" status on the Tado CE device page is the main confirmation — the bridge is paired and the local connection is active. A few things you can check to see it working: Your climate entities should now show The HomeKit Connected sensor has some useful attributes too — write attempts, successes, cloud fallbacks, and average response time. Worth keeping an eye on those over the first day or two. For the real-time responsiveness, watch a climate entity's temperature while you're in the room. With cloud-only polling you'd see it jump in steps every 5 minutes. With HomeKit you should see smaller increments as the bridge pushes changes — have a look at the logs I posted earlier (Reply 1.4) to see what that looks like in practice. On your automation question — yes, just point your existing automation at the Tado CE climate entities directly. So your action block: action: climate.set_temperature
data:
temperature: "{{ states('sensor.dynamic_base_temperature') | float }}"
target:
entity_id: climate.lounge # ← Tado CE entityThat'll work. The integration handles the routing — if HomeKit is connected and healthy, the write goes local. If not, it falls back to the cloud automatically. Your automation doesn't need to know or care which path it takes. For the HVAC mode conditions, Tado CE uses the same One thing to flag — I found and fixed a bug today where HomeKit writes could silently fail. The bridge would report success locally but the command never actually reached the Tado server, so HA would show "heating" while the Tado app showed OFF. The fix is in beta.2 which I'll push later this week — it detects the mismatch automatically and falls back to the cloud API. If you notice any discrepancy between HA and the Tado app in the meantime, that's likely the cause. Let me know how the responsiveness feels once you've had it running for a bit! |
Beta Was this translation helpful? Give feedback.
-
|
Ah good to know, I was wondering why my HA entities were not following the 'real' tado status in the app and web. I'll pause testing until beta2 arrives! |
Beta Was this translation helpful? Give feedback.
-
|
24 hours in, it looks like overnight the integration wasn't making use of the more timely HomeKit updates for sensor data:
I'll see if I an pull some logs for the next overnight period/bring it forward with config. Current state ( |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for flagging this — that graph definitely looks like polling steps rather than real-time data. I've traced through the code and I think I know what's happening. Right now, HomeKit events update an internal cache but don't trigger an entity state update on their own — the entity only picks up the new value on the next coordinator poll. So even though the bridge is pushing temperature changes in real-time, the entity in HA only reflects them at whatever your polling interval is. That would produce exactly the step pattern you're seeing. Your attributes show This is something I need to fix — HomeKit events should push state updates to entities immediately rather than waiting for the next poll cycle. I'll get that into beta.2. If you do grab the overnight logs at some point, the |
Beta Was this translation helpful? Give feedback.
-
|
Interesting.... I'm noticing the Humidity updating far less than before actually. 
I've noticed API calls reduce also. 
|
Beta Was this translation helpful? Give feedback.
-
|
This is the same thing @jeverley spotted with temperature — and it confirms the root cause. Right now HomeKit events update an internal cache but don't push the new values to your entities until the next coordinator poll. So even though the bridge is sending humidity changes in real-time on your local network, the entity in HA only picks them up at the polling interval. With HomeKit connected, the cloud polling stretches out (which is why you're seeing fewer API calls — that part is working as intended), but the entity updates got slower as a side effect. The API call reduction is good news — that's HomeKit doing its job. The entity update frequency just needs to be decoupled from the polling interval so you get the best of both: fewer API calls and real-time data on your dashboard. I'm working on a fix to make HomeKit events trigger entity updates immediately. That'll be in beta.2. |
Beta Was this translation helpful? Give feedback.
-
|
Glad to hear its not a different issue and it sounds like you know exactly what it is :) Super stoked by this! Rapid temp and humidity is one the biggest things i've been excited about. I felt silly to go and buy a ton more sensors when the Tado stats had this data! :) |
Beta Was this translation helpful? Give feedback.
-
|
@hiall-fyi Assume it's a fully built in code aspect of CE? Not something i could mock up a quick automation and cause it to fire frequently to test it out for you? |
Beta Was this translation helpful? Give feedback.
-
|
An interesting one i've noticed is 1 Stat has updated. The other 5 didnt. 
|
Beta Was this translation helpful? Give feedback.
-
|
@ChrisMarriott38 on 8.3 — yeah it's fully internal to the integration, no way to trigger it from an automation unfortunately. The event subscription and entity update pipeline are all handled inside the coordinator code. The fix is making the event callback push state updates to entities immediately rather than just writing to an internal cache — straightforward change on my end. On 8.4 — that lines up with what @jeverley spotted. The one stat that updated probably had its temperature change land right on a cloud poll cycle, so the coordinator picked it up. The other 5 had their HomeKit events arrive between polls — data hit the cache but never made it to the entities. Once beta.2 is out with the immediate push fix, all 6 should update in real-time. You'll see the difference straight away. |
Beta Was this translation helpful? Give feedback.
-
|
v4.0.0-beta.2 is up — this one fixes the real-time update issue that @jeverley and @ChrisMarriott38 spotted. What changedThe core problem was that HomeKit events were updating an internal cache but not pushing those values to your entities until the next coordinator poll. So even though the bridge was sending temperature changes in real-time, your dashboard only picked them up every 5–30 minutes. That step pattern you were both seeing? Gone. Entities now get their own direct line to the HomeKit cache. When the bridge pushes a temperature or humidity change, the entity updates within a couple of seconds — no coordinator poll needed. Environment sensors (mold risk, dew point, comfort level, condensation, surface temp) all benefit from this too. I also fixed the service refresh gap @jeverley found — And the silent HomeKit write failure I mentioned to @ChrisMarriott38 — the integration now detects when a local write doesn't reach Tado's servers, clears the stale state, and falls back to the cloud API automatically. How to updateHACS → Tado CE → overflow menu (⋮) → Redownload → tick "Need a different version?" → select v4.0.0-beta.2 → download → restart HA. If you're already on beta.1, just update and restart — no config changes needed. What to look forThe big one is the temperature and humidity graphs. Where beta.1 showed steps every 5–30 minutes, you should now see smooth curves that track real-time changes from the bridge. Check your climate entity attributes — @hapklaar you mentioned pausing testing until beta.2 — this is the one. Your entities should now follow the real Tado status properly. Full changelog: https://github.com/hiall-fyi/tado_ce/releases/tag/v4.0.0-beta.2 cc @jeverley @ChrisMarriott38 @hapklaar @donnie-darko @tonicb78 |
Beta Was this translation helpful? Give feedback.
-
|
Hey @hapklaar, thanks for jumping back in! Just want to make sure I'm understanding the two scenarios correctly before I dig in. Scenario 1 — "changing a room in the app": When you say "the app", do you mean the Tado mobile app (the official one from Tado), or are you changing things through Home Assistant (the Tado CE climate card)? If it's the Tado mobile app — that's actually expected with HomeKit enabled. Changes you make in the Tado app go through Tado's cloud servers, and with HomeKit connected, Tado CE only checks the cloud every ~30 minutes (instead of every 5 minutes) because it's getting live temperature data from your bridge directly. So a change in the Tado app can take up to 30 minutes to show up in HA. The tradeoff is real-time temperature data vs slightly delayed cloud sync. If you're mainly controlling your heating through HA (which is the intended setup with HomeKit), those changes go through the local bridge and update immediately. Scenario 2 — "turned off from HASS but Tado app still on": This one's a bit different. When you turn off a climate entity in HA, the command goes to your bridge locally. The Tado app reads from Tado's cloud, and there's a delay before the bridge syncs that change back to the cloud. That delay is on Tado's side — typically 1–3 minutes. So seeing a 2-minute gap between HA and the Tado app is normal. The key question is: did the zone actually turn off? If you check the Tado app after 3–5 minutes and it shows off, then everything worked — it was just the cloud catching up. If it never updates, that would be a real issue. Could you let me know:
That'll help me figure out if there's something to fix or if it's just the expected cloud sync delay. |
Beta Was this translation helpful? Give feedback.
-
|
Hey :).
I do see some other odd behavior. After I set one room to 22C and then turned it off, it showed like this: In the tado app I see this: (set to 18, which is the scheduled temp) Hope I make any sense :) |
Beta Was this translation helpful? Give feedback.
-
|
Hey @hapklaar, thanks for the detailed follow-up — the screenshots really help. On the Tado app lag (scenario 1): Makes sense now that you've confirmed it's the Tado mobile app. With HomeKit connected, Tado CE checks the cloud less often (every ~30 minutes instead of every 5) because it's getting live data from your bridge directly. Changes you make in the Tado app go through the cloud, so they can take up to 30 minutes to show up in HA. The intended workflow is to control heating through HA — those changes go through the local bridge and update instantly. On the flip-back (scenario 2): The "set to 22C then it flipped back to off" is something I'm looking into. It's likely a timing issue where the cloud data (which still shows OFF) overwrites the local change before Tado's servers catch up. The fact that it worked fine on the second try suggests it's intermittent and timing-dependent. If you see it again, debug logs would be really helpful. On the Auto mode target temperature: I found the bug. When you set 22°C → Off → Auto, the climate card was keeping the 22°C target instead of switching to the scheduled temperature (18°C in your case). The Tado app showed the correct 18°C because it reads directly from the schedule. I've fixed this — the climate card now reads the current schedule target when in Auto mode, so it'll match what Tado is actually doing. This fix will be in beta.3 along with some other improvements. I'll tag you when it's up. If you spot the flip-back issue again, could you grab the debug logs? That would help me nail down the exact timing. |
Beta Was this translation helpful? Give feedback.
-
|
I think I caught a 'bounceback' in the act. Here I set the huiskamer (living room) entity to OFF in HASS, but it remained enabled in the tado app. After about a minute I refreshed the dashboard and saw the entity move back to auto. The tado app was eventually updated to OFF, but the HASS entity kept showing auto 
Not sure how much of the log is usefull, so I included it from the moment I set it to OFF until the end. Hope this is useful :) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the logs @hapklaar, really helpful. First, your HomeKit connection is solid. Events are coming through, cache refreshes are working, bridge is responding in ~300ms. No disconnects or failures on the HomeKit side. On the Auto mode target temperature — I found and fixed the bug. When you set 22°C → Off → Auto, the climate card was keeping the 22°C instead of switching to the scheduled temperature (18°C). That's in the next build. On the "flip back to off" issue — the logs you sent don't cover the moment it happened, so I couldn't see the exact sequence. If it happens again, could you grab the logs right after? The key lines I'm looking for would mention One thing I noticed — you've got your polling interval set to 1 minute. That's fine with your 20,000 daily limit, but even with HomeKit skipping zone data, each poll still fetches home state and mobile devices (2 API calls per minute = ~2,880/day). If you don't need mobile device tracking that frequently, you could bump the interval to 5 minutes and save a good chunk of calls. Totally optional though — you've got plenty of headroom. Also spotted — weather compensation is failing on every poll cycle ( Beta.3 is coming soon with the Auto mode fix and several other improvements. I'll tag you when it's up. |
Beta Was this translation helpful? Give feedback.
-
|
Already updated big grin. About to do some testing!! |
Beta Was this translation helpful? Give feedback.
-
|
v4.0.0-beta.3 is up — this one addresses the issues @hapklaar and @ChrisMarriott38 reported. What changed
How to updateHACS → Tado CE → overflow menu (⋮) → Redownload → tick "Need a different version?" → select v4.0.0-beta.3 → download → restart HA. What to look for
Full changelog: https://github.com/hiall-fyi/tado_ce/releases/tag/v4.0.0-beta.3 cc @ChrisMarriott38 @jeverley @hapklaar @donnie-darko @tonicb78 @jeromewir |
Beta Was this translation helpful? Give feedback.
-
|
I already have the HA HomeKit integration configured, prior to Tado CE, and I have a lot of entities from it on dashboards already displaying homekit values. Do I really have to remove the homekit integration to reconnect to it in CE, or could CE not use those already existing HomeKit entities? |
Beta Was this translation helpful? Give feedback.
-
|
Yes you do. I had to do the same, you can't have multiple connections at the same time. Tado_CE makes it's own conenction i believe so they cant work as 2. Also the HomeKit default ones are significantly slower to update. The Tado-CE ones are significantly more rapid. |
Beta Was this translation helpful? Give feedback.
-
|
Ok thanks for the update. I have so many things using the homekit entities, graphs, guages etc already, I'll need to find a decent amount of time to sit down and change everything if I'm going to switch the homekit over to Tado CE then. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @Si-Hill, good question. Short answer — yes, you'd need to remove the HA HomeKit integration to let Tado CE connect directly. The bridge only accepts one controller connection at a time, so they can't run side by side. @ChrisMarriott38 went through the same thing. That said, there is a middle ground if you'd rather keep your existing HomeKit setup. Tado CE has a per-zone external sensor feature — you can point each zone's temperature and humidity to any HA entity, including the ones from your existing HomeKit integration. To set it up: Settings → Devices & Services → Tado CE → Configure → General Settings → enable Per-Zone Configuration → back to menu → Zone Configuration → pick your zone → expand the External Sensors section. The tradeoffs vs the built-in HomeKit connection:
So it depends on what matters more to you — keeping your existing HomeKit dashboard setup intact, or getting the full benefit of the direct connection. Either way works, just different tradeoffs. |
Beta Was this translation helpful? Give feedback.
-
|
Quick heads-up folks! I've found a cosmetic issue with the thermal analytics sensors (heating acceleration and approach factor) when HomeKit is connected. What's happening: with HomeKit enabled, the bridge and cloud can both push temperature readings within the same second. The thermal analyzer doesn't deduplicate these, so it occasionally calculates nonsensical values — like a heating acceleration of -20°C/h² when it should be around +5. You might see this on the Heating Acceleration or Approach Factor sensors if you've enabled them (they're off by default). 
What's NOT affected: your actual heating behaviour is fine. Preheat time estimates, heating rate, and all the sensors that drive scheduling decisions use cycle-level timing (start to end), not individual readings. I'll have the fix in beta.4 — it's a straightforward deduplication pass on the temperature readings before they hit the analyzer. If you spot weird values on those two sensors in the meantime, that's why. |
Beta Was this translation helpful? Give feedback.
-
|
Looks good with beta.4, will keep it running for a night and we'll see... 
|
Beta Was this translation helpful? Give feedback.
-
|
v4.0.0-beta.4 is up — mostly HomeKit data quality improvements and better diagnostics. What changedThe thermal analytics sensors (Heating Acceleration and Approach Factor) were showing wild values when HomeKit was connected — things like -20°C/h² when it should be around 5. Turned out HomeKit and cloud data arriving within the same second created duplicate temperature readings that threw off the math. Fixed with deduplication and sane-value bounds. Your actual heating behaviour was never affected — just those two diagnostic display sensors. On the improvements side:
How to updateHACS → Tado CE → overflow menu (⋮) → Redownload → tick "Need a different version?" → select v4.0.0-beta.4 → download → restart HA. No config changes needed if you're already on beta.3. As a reminder, v4.x requires Home Assistant 2025.11 or later (needed for the What to look for
Full changelog: https://github.com/hiall-fyi/tado_ce/releases/tag/v4.0.0-beta.4 cc @ChrisMarriott38 @jeverley @hapklaar @donnie-darko @tonicb78 @jeromewir @Si-Hill |
Beta Was this translation helpful? Give feedback.
-
|
Just updated. I instantly put Live detailed logs on and filtered by Tado_CE to try capture anything. Most looks like Green and Blue info. Not sure fully on the colour coding meaning for the logs. Mostly notice Yellowand orange as warnings and RED as critical usually i think? I did clock a Orange/Yellow one
|
Beta Was this translation helpful? Give feedback.
-
|
Nice catch @ChrisMarriott38, and thanks for jumping on beta.4 so quickly. That warning is a real one — there's a code path where the schedule data cache is empty (typically right after a fresh install or restart before the first schedule fetch completes), and when the smart comfort sensor tries to read it, it falls through to a synchronous file read on the main thread instead of going through the async executor. HA's blocking call detector is doing its job flagging it. It only happens once per restart (after the first read it's cached and subsequent calls are fine), and it won't cause any functional issues — but it shouldn't be doing blocking I/O on the event loop at all. I'll have it fixed in the next build. The green/blue lines are debug and info level — normal operation. Yellow/orange is warnings (like this one), and red would be errors or critical. You've got the right mental model there. |
Beta Was this translation helpful? Give feedback.
-
|
Folks, quick heads-up on what's coming in beta.5 — it's mostly behind-the-scenes work, but it should make things noticeably more reliable. What's changing: 🗄️ Cleaner data storage — Tado CE used to save your data in three different ways depending on what it was (zone temperatures, rate limits, settings, etc.). Beta.5 moves everything into one consistent system — Home Assistant's built-in storage. This means:
🔄 Smooth upgrade from any version — Whether you're on v3.5.3 or any of the v4 betas, your data migrates automatically the first time you start beta.5. Old files are kept as backups just in case. 🏠 HomeKit mapping is more resilient — If your bridge connects before the cloud has synced (common on first install or after a restart), Tado CE now retries the zone mapping automatically instead of giving up. One less thing to worry about. 🐛 Bug fix — Fixed a startup warning about blocking I/O when schedule data hasn't been fetched yet (thanks @ChrisMarriott38 for flagging this in the discussion). Still investigating one thing before releasing — @ChrisMarriott38 spotted some humidity sensors that might not be updating as expected through HomeKit (#224). Want to make sure that's sorted (or confirmed as a known limitation) before pushing beta.5 out. Stay tuned! |
Beta Was this translation helpful? Give feedback.
-
|
I found a problem always related to the presence mode. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @dragorex71, thanks for flagging this — I can see what's happening. When you change presence via the Tado CE Hub select entity, the API call goes through fine (Tado's servers update, the app reflects it), but the climate entities don't pick up the change because they rely on a separate home state fetch that only runs when Home State Sync is enabled. Without it, the climate entities have no way to know the presence changed, so Enabling Home State Sync would fix it today, but honestly the integration should handle this without needing that toggle — if you just told it to go Away, it already knows the answer without asking the cloud again. I'll get this sorted in beta.11. Beta.10 just shipped so I don't want to rush another one out the door, but it's on the list for the next build. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry if I've missed it, has select.tado_ce_hub_ce_overlay_mode gone in v4? EDIT - I see zone control is moved to centralised Options Flow, but still not sure how to achieve the below I'm trying to set the HVAC mode of my home office to 'OFF' when I'm in the (work) office, but leave the rest of the house on normal schedule as others are home. The issue I run into is that if I have previously made a change in the Tado app e.g. temp change for 20 mins, then "climate.set_hvac_mode" uses 20mins, rather than until I revert the settings. I was hoping to use this overlay command to overcome this. Other options I considered is to use the "tado_ce.set_climate_timer" and set the overlay or tado_ce.set_open_window_mode set to indefinite, however if the others go out and AWAY mode is set, this sets an annoying notification from the Tado app that some rooms are being manually controlled. Is there another option I'm missing? |
Beta Was this translation helpful? Give feedback.
-
Thanks for the suggestions. I've tried all 3
Is it worth me raising a feature request to add a new service that controls HVAC mode with overlay selection at a per zone level? 
|
Beta Was this translation helpful? Give feedback.
-
|
Hey @mpartington, thanks for testing all three — this is really useful feedback. I've traced through the flow and found the root cause of option 1 not working. When HomeKit is connected and healthy, That's why changing the overlay mode to Manual had no effect — the overlay mode setting only gets consulted on the cloud API fallback path, and HomeKit was succeeding before it ever got there. I'll fix this for the next build. The plan is: when the configured overlay mode is anything other than "Tado Default", On option 3 — On the feature request for a new service with per-zone HVAC + overlay control — I don't think a new service is needed once the HomeKit bypass bug is fixed. With the fix, If after the fix you still find cases where the per-zone overlay isn't being respected, definitely flag it and I'll look into a dedicated service. |
Beta Was this translation helpful? Give feedback.
-
|
Is there a way of setting the perzone overlay within an automation? Without confirming it is set as expected may lead to the wrong behaviour if someone has set say a 30.min change directly in the app. |
Beta Was this translation helpful? Give feedback.
-
|
Good question. Right now the per-zone overlay mode is only configurable through the UI (Settings → Tado CE → Configure → zone → Overlay section) — there's no select entity you can change from an automation. The For your use case though, you don't actually need to change the overlay mode dynamically. The # Turn off office heating with indefinite (manual) overlay
service: tado_ce.set_climate_timer
target:
entity_id: climate.home_office
data:
temperature: 5
overlay: manual# Bring it back when you get home
service: tado_ce.resume_schedule
target:
entity_id: climate.home_officeThe The fix I mentioned for |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, the issue with using set_climate_timer remains the tado app notifications. Setting HVAC to off (indefinitely) seems the only way to suppress them. Probably more a me issue, as I don't use Tado_CE for full control, just to significantly enhance the native functionality. Hopefully as you point out the fix will sort this for me, but I wonder how that then interacts with using the climate timer set to a different overlay. 
|
Beta Was this translation helpful? Give feedback.
-
|
v4.0.0-beta.11 is out 🔧
|
Beta Was this translation helpful? Give feedback.
-
|
I'm loving local control with HomeKit, however, this weekend was warmer than usual and the heating was still on in some rooms. My wife turned off the heating in all rooms via the Tado App but the heating continued running. Do I need to change something so that Tado CE responds to the manual change in the Tado app quicker? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @Si-Hill, a few things could be going on here — need to narrow it down. When your wife turned off heating in the Tado app, did she set each zone to OFF manually (which creates an overlay), or did she lower the target temperature? And by "heating continued running" — do you mean the boiler kept firing, or that the climate entities in HA still showed "heating"? The most likely explanation depends on whether you have Smart Valve Control enabled on those zones: If SVC is enabled: When your wife turns off a zone in the Tado app, that deletes the overlay SVC wrote. SVC detects this as a manual override and backs off. But if the external sensor still reads below the schedule target, the controller will eventually resume and write a new overlay — which turns the heating back on. This is by design (the controller's job is to keep the room at the target), but it means "turning off in the app" doesn't stick if the room is still cold. To properly override SVC: either disable the Smart Valve Control toggle for those zones, or set the schedule target to a low value (e.g. 5°C) so SVC has nothing to chase. If SVC is not enabled: The delay is probably the cloud polling interval. With HomeKit connected, Tado CE only checks the cloud every 30 minutes (configurable). Changes made in the Tado app go through Tado's cloud, so HA won't see them until the next cloud poll. The TRV itself responds immediately (the app talks directly to Tado's servers which push to the TRV), but HA's view of the zone state lags behind. Could you check:
|
Beta Was this translation helpful? Give feedback.
-
|
v4.0.0-beta.12 is out 🔧 This one fixes three bugs reported by you lot during beta.11 testing, plus better logging for Smart Valve Control troubleshooting. Bug fixes: 🔧 Overlay mode now respected when changing HVAC mode — @mpartington reported that setting overlay mode to "Manual" had no effect when using 🔧 Climate entities no longer stuck at null after HA restart — @Newreader found that some climate entities would show blank temperature and controls for up to 3 hours after a restart. An automation firing during startup was marking entities as "fresh" before they had any data, which blocked the first update from populating them. The freshness check now lets updates through when an entity has no data yet. 🔧 "Invalid repairs platform" error gone — @simonotter spotted this in the startup logs. HA was trying to register an internal module as a repairs platform. Renamed so HA no longer picks it up. Improvements: 📊 Smart Valve Control now logs at info level — @simonotter was having trouble seeing SVC logs because debug output from 16 zones filled the log buffer too fast. All SVC state changes, write decisions, and startup status now appear at info level. You no longer need debug logging enabled to see what the controller is doing. After updating, you can remove any Upgrade notes:
To update: HACS → Tado CE → ⋮ → Redownload → tick "Need a different version?" → select v4.0.0-beta.12 → Restart HA cc @ChrisMarriott38 @jeverley @hapklaar @dragorex71 @Si-Hill @wrowlands3 @donnie-darko @tonicb78 @jeromewir @simonotter @driagi @mpartington @Newreader |
Beta Was this translation helpful? Give feedback.
-
|
Hi @hiall-fyi , there is still a problem with presence mode but i think it is related to a localization issue. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @dragorex71, thanks for flagging this. What you're seeing is two different translation sources showing different Italian labels for the same underlying values. The Tado CE Hub presence select uses our own translations ("Casa" / "Via"), while the climate entity's preset_mode uses HA core's built-in translations ("In casa" / "Fuori casa"). Under the hood, both use the same internal values ( That said, the visual inconsistency is confusing. I'll align our Italian translations to match HA core's preset labels so they look the same in the UI. I'll also check the other 5 languages for the same mismatch. Could you confirm: is this purely a display issue for you, or are you seeing actual automation failures where presence changes don't propagate to the climate entities? |
Beta Was this translation helpful? Give feedback.
-
Unfortunately I can't. For now my automations don't rely on tado presence detection |
Beta Was this translation helpful? Give feedback.
-
|
Hey @dragorex71, good catch on the Italian labels. I've already aligned them to match HA core ("In casa" / "Fuori casa") across all 6 languages — that fix will be in beta.13, coming in the next day or two. Before I dig deeper though, I want to make sure the translation fix actually covers what you're hitting. When you say the climate entity "doesn't recognize the correct states" — can you walk me through what's happening?
Under the hood, both the select entity and climate preset use the same internal values ( A screenshot of Developer Tools → States showing both the select entity and a climate entity's |
Beta Was this translation helpful? Give feedback.
-
|
Hei @hiall-fyi
Here from developer tools: 
|
Beta Was this translation helpful? Give feedback.
-
|
Ok I have found the problem. But every attempt to change manually the PRESET in a climate card fails. It accepts only Home |
Beta Was this translation helpful? Give feedback.
-
|
Hey @dragorex71, you nailed it and the screenshots confirmed exactly what I needed to see. I traced through the full data flow and found the bug. When you change presence via the Hub select (or the climate card preset), the API call goes through fine and the integration injects the new state locally. But then the automatic refresh that fires right after rebuilds the data from an internal cache — and that cache still had the old "HOME" value because the injection wasn't updating it. So the climate entities would briefly flash "Away" then snap back to "Home" on the next update cycle. The same thing explains why changing preset directly on the climate card "fails" — the API call succeeds, the card shows "Away" for a moment, then the refresh overwrites it back to "Home". Fixed for beta.13. Both the Hub select and climate card preset paths now update the internal cache alongside the live data, so the refresh cycle reads the correct value instead of the stale one. Thanks for the Developer Tools screenshots — seeing the actual state values made it straightforward to trace. And sorry for initially thinking this was just a translation issue — the label mismatch was real too (also fixed), but you were right that something deeper was going on. |
Beta Was this translation helpful? Give feedback.
-
|
v4.0.0-beta.13 is out 🔧 Three fixes from your reports in this thread, plus a new startup event for automations. Bug fixes: 🔧 Presence changes now stick — @dragorex71 reported that switching to Away via the Hub select or climate card preset would flash briefly then snap back to "Home". The API call was going through fine, but the automatic refresh that fires right after was reading stale cached data and overwriting the change. Both the Hub select and climate card preset paths now update the internal cache so the refresh picks up the correct value. 🔧 Presence labels now match across the UI — @dragorex71 also spotted that the Hub select showed "Casa"/"Via" in Italian while the climate card showed "In casa"/"Fuori casa". Labels are now aligned to match HA core's climate preset translations across all 6 languages. 🔧 Smart Valve Control cloud writes fixed — @simonotter's "cloud write failed" warnings in #221 turned out to be a missing field in the API request. The controller was running and evaluating but every cloud write was silently rejected by Tado's servers. If you're using SVC without HomeKit, it should actually work now. New: 🆕 Upgrade notes:
To update: HACS → Tado CE → ⋮ → Redownload → tick "Need a different version?" → select v4.0.0-beta.13 → Restart HA cc @ChrisMarriott38 @jeverley @hapklaar @dragorex71 @Si-Hill @wrowlands3 @donnie-darko @tonicb78 @jeromewir @simonotter @driagi @mpartington @Newreader |
Beta Was this translation helpful? Give feedback.
-
|
Just released v4.0.0-beta.14. Here's what's in it: New: Offset Sync — a second Smart Valve Control mode. Instead of adjusting the TRV's target temperature (Valve Target mode), it writes a device offset so the Tado app shows your external sensor's reading directly. Tado's own modulation then works with accurate data. Pick between Off / Valve Target / Offset Sync per zone in your External Sensors settings. Fixed: SVC now watches the schedule while active — if your schedule goes to OFF or changes target, the controller responds immediately instead of continuing with the old value (#251). Also fixed SVC crashing on startup when a zone's schedule is OFF (#252), HomeKit not pushing target temp / mode changes from the Tado app to HA (#253), Weather Compensation going "Unknown" during brief outdoor sensor gaps (#249), and the floating point decimals in valve_target (pulse-card#45). Improved: SVC reports its state even when idle (so Pulse Card can show it), logging is visible without debug mode, and bridge serial is now redacted from diagnostics. This should be the last beta before GA. The plan is to release 4.0.0 on 22 May if no blockers come up in the next two weeks. After that I'll be away for a couple of weeks on holiday, so if you spot anything weird on beta.14 please shout sooner rather than later. Massive thanks to everyone who's been testing and reporting through the beta cycle. Fourteen releases, dozens of bug reports, countless logs and screenshots — this integration is genuinely better because of your feedback. Full credits in CREDITS.md. |
Beta Was this translation helpful? Give feedback.
-
|
I was quite excited by the new Offset Sync, personally I think that will be better than Valve Target. However, for some reason when an offset is changed (even in the Tado app) the TRV adjusts itself. I changed my mode to Offset Sync and my TRV's were making noises all night! (when the heating is off). Perhaps Offset Sync should only work when a schedule or heating is active? I switched back to Valve Target around 5am. 
|
Beta Was this translation helpful? Give feedback.
-
|
Hey @Si-Hill, good feedback on the frequency. Right now the built-in guards are:
So what you're seeing in the screenshots is the offset changing by ≥ 0.5°C each time, spaced at least 5 minutes apart. With a sensor that fluctuates a lot (or a room that's actively heating up), that can still mean quite a few writes in a morning. Your suggestion of making the minimum threshold configurable (e.g. letting you set it to 1°C instead of 0.5°C) is a good one — it'd cut the number of writes roughly in half for most setups, at the cost of slightly less precise temperature display in the Tado app. I'll look at adding that as a per-zone option for the GA release. Cheers. |
Beta Was this translation helpful? Give feedback.
-
|
I've had to turn off the Offset Sync and go back to Valve Target, the changes are almost constant (every 5mins) and I'm going to have no batteries left! It feels like the offset is chasing a target, rasies a little, goes too high, so it drops a little, and goes to low, so it raises a little, and so on in a loop. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @Si-Hill, I found the root cause of the oscillation — and it's a proper bug, not just a tuning issue. After writing an offset to the TRV, the integration wasn't updating its internal cache of what offset it just wrote. So the next evaluation (5 minutes later) would calculate the offset using the old cached value, get a slightly different answer, write that, and repeat. Each cycle the offset would bounce back and forth because the calculation was always working from stale data. Fixed in beta.15 — the cache now updates immediately after a successful write, so the next evaluation uses the correct baseline and doesn't produce a different result unless the external sensor has genuinely moved. I've also added the configurable sensitivity you suggested. After updating, go to Settings → Tado CE → Configure → Zone Configuration → [your zone] → External Sensors → Offset Sync Sensitivity. You can set it anywhere from 0.5°C (current default, most responsive) to 3.0°C (fewest writes, best for battery). Try 1.0 or 1.5 and see how it feels — with the oscillation bug fixed, you should see far fewer writes even at 0.5°C. To update: HACS → Tado CE → ⋮ → Redownload → tick "Need a different version?" → select v4.0.0-beta.15 → Restart HA |
Beta Was this translation helpful? Give feedback.
-
I was using valve target as my external sensor offset control mode and my target temperature oscillated too, I assume it's the same bug?
|
Beta Was this translation helpful? Give feedback.
-
|
Hey @wrowlands3, thanks for the screenshot — I can see the target bouncing between ~19 and ~21°C every few minutes while the room is near the target temperature. That's not normal proportional tracking. Looking at the timing, this is most likely the same HomeKit write protection issue that @apilone hit on #253 — after the controller writes a valve target via HomeKit, the bridge pushes back a stale cached value a few seconds later, the integration accepts it as "newer", and the controller sees the target changed and writes again. Rinse and repeat. Beta.15 fixes this — after any HomeKit write, there's now a 3-minute protection window where the bridge's stale target temperature is ignored. The controller's value stays put until the cloud confirms the actual state. Are you on beta.14? If so, beta.15 should sort this. I'm shipping it shortly — working through a few other fixes that came in today from the same root cause. To update when it's out: HACS → Tado CE → ⋮ → Redownload → tick "Need a different version?" → select v4.0.0-beta.15 → Restart HA |
Beta Was this translation helpful? Give feedback.
-
|
Just released v4.0.0-beta.15. Two things in this one: a Settings UX reorganisation, and a big reliability pass from a full pre-GA audit — 40+ latent issues fixed across Smart Valve Control, Offset Sync, HomeKit interactions, auth, and storage. Settings UX revamp
New: Offset Sync sensitivity is now configurable per zone (0.5–3.0°C). Higher values = fewer TRV writes = better battery life, at the cost of slightly less precise temperature display in the Tado app. Find it in Zone Configuration → External Sensors → Offset Sync Sensitivity (only shows when Offset Sync is selected). Offset Sync fixes (all from this thread)
Smart Valve Control fixes
HomeKit fixes
Climate control
Weather Compensation
Auth & storage resilience
Data integrity & privacy
Performance & storage
Log output
Still targeting GA for late May. If you spot anything off on beta.15, let me know — this is the "soak test" release before the final cut. |
Beta Was this translation helpful? Give feedback.
-
|
This is absolutely amazing work. I updated about 4hrs ago and so far, just from a SVC and Offset Sync point of view, it's working much better. I'll let a few days and heat cycles pass for more testing. |
Beta Was this translation helpful? Give feedback.
-
|
v4.0.0-beta.16 is out 🐛 Small follow-up release after beta.15. Two issues surfaced this week: #261 (@apilone) — A zone state desync (turning a zone OFF/HEAT from the Tado app didn't reflect in HA) turned out to be hiding a second, bigger problem: when the HomeKit bridge went unreachable, the integration's setup-retry loop re-fetched every zone's schedule from the cloud each time, draining ~500 calls in two idle hours. Both fixed — the merge gate now distinguishes legitimate user actions from stale bridge echoes (using the bridge's last-changed timestamp, not just last-observed), and schedule fetch reuses the local cache on retry plus skips entirely under low API quota. #262 (@simonotter) — A chart showing Offset Sync pegged at +10°C kicked off a cache-poisoning audit. Three related bugs in the offset write path:
While auditing the rest of the cache write paths for similar shapes, I caught one more — picking Presence Mode "Auto" used to force the cached home presence to "Home" regardless of what geofencing actually had it set to, so the climate card's Home/Away chip read wrong for one poll cycle when you flipped to Auto from outside. Fixed; the cache now waits for the next poll to fill in the real value. Also fixed: Early Start and Child Lock switches not rolling back the dashboard state when an API write failed during a rate-limit window. And the HomeKit bridge's 2-minute keepalive poll no longer masquerades as a real value change — target temperature and HVAC mode now correctly fall back to cloud when the bridge hasn't actually seen an event in the last 5 minutes. GA target is still late May. If you spot anything off on beta.16, please shout — comment on this thread or open an issue. Thanks again to @apilone and @simonotter for the detailed reports and follow-up logs that made this round of fixes possible. |
Beta Was this translation helpful? Give feedback.
-
v4.0.0 — GA cut 🎯That's the 4.0 cycle done. Sixteen betas of work landing as one stable tag — thanks to everyone in this thread who reported bugs, posted screenshots, ran debug logs across multiple rounds, and tolerated the back-and-forth. The release exists in shippable form because of the data and patience you brought. Headline changes since v3.5.3: 🎯 HomeKit Local Control — Pair your Tado Internet Bridge over HomeKit and temperature / mode changes go through your local network, with sensor pushes arriving within ~2 seconds. Cloud-only mode is bound by your polling interval (typically 5–30 min), so this is a meaningful shift in responsiveness for anything that reacts to room temperature. Cloud fallback runs automatically if HomeKit drops, and the integration tracks how many API calls HomeKit saves you per day. 🌡️ Smart Valve Control — Two modes for compensating inaccurate TRV readings, picked per zone:
Adjustments go via HomeKit when available (no API cost), with cloud as fallback. The controller backs off on manual changes and resumes on the next schedule block. 🌤️ A quieter integration — Token refreshes ~50% less often, weather and zone polling stretch when HomeKit has live data, insight history writes drop ~50%, boiler flow temperature polls the bridge directly (no Tado quota), and the API call history attribute caps at 10 entries instead of 100. Daily API usage on a home with HomeKit connected and a 60-min Cloud Refresh should sit comfortably below the Tado limit. Plus a Last-mile polish since beta.16A few things landed between beta.16 and the GA cut:
To update: HACS → Tado CE → ⋮ → Redownload → tick "Need a different version?" → select v4.0.0 → Restart HA. If you spot anything off after upgrading — please open a fresh issue or comment on this thread. The thread will stay open as a 4.x soak-test channel for a while; standalone reports get tracked better as separate issues. Thanks to everyone who supported the project through Buy Me a Coffee — it genuinely helps. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
HomeKit local control for Tado CE is in solid working condition. We've verified it on a live setup with 9 heating zones — reads, writes, and cloud outage resilience all working. We're looking for a few more people to test it over the next week or two before releasing v4.0.0.
Related: Discussion #200, Discussion #29, Discussion #151, Issue #201, Issue #124, Issue #4
Our approach
Everything is built into one integration — no extra servers, no second integration to manage, no manual entity matching. You enable HomeKit in the settings, enter your PIN, and you're done. Cloud and local data are merged automatically, and fallback between the two is seamless.
How it works
Reads
Temperature and humidity come from your bridge over the local network. Each climate entity shows where its data is coming from via the
temperature_sourceattribute:homekit,cloud, orexternal(if you've configured an external HA sensor in Zone Configuration). Priority: external > HomeKit > cloud.Writes
The integration tries the local path first for temperature and HVAC mode changes. If that fails, it falls back to the cloud. The
last_write_sourceattribute shows which path was used.AC fan and swing controls aren't available via HomeKit, so those always go through the cloud. Heating power, battery, schedules, hot water, geofencing, and open window detection also remain cloud-only.
Live test results
Tested on HA 2026.4.1 with 9 heating zones:
Cloud outage test
We blocked all Tado cloud traffic at the firewall and reloaded the integration. 0 out of 9 zones became unavailable — all continued reporting live temperature and humidity via the local HomeKit connection.
What's still in progress
We're fine-tuning the config flow UI and implementing adaptive polling optimisation to save even more API calls when HomeKit is connected. Target: dev build ready by Monday 13 April or Tuesday 14 April.
How to try it
Requirements
IB)Setup
123-45-678). Digits only without dashes won't work.Debug logging
Add this to your
configuration.yamlso we can diagnose any issues:You can remove it once the stable release is out.
What we'd like feedback on
Drop a comment if you're interested.
cc @ChrisMarriott38 @chinezbrun @wrowlands3 @hapklaar @thefern69 @StreborStrebor @donnie-darko — you've all shown interest in local control or HomeKit in past discussions. Would love to have you try this out!
Beta Was this translation helpful? Give feedback.
All reactions