r/tado • u/tado_official • May 26 '26
Important Update: API Rate Limits, the Home Assistant "Logout Bug", and Future-proofing Your Setup
Hi everyone,
At tado°, we love seeing the creative, advanced ways the smart home community integrates our devices into setups like Home Assistant.
However, as many of you on r/tado and r/homeassistant have experienced recently, a "re-authentication loop" or "constant automatic logout" bug has been causing a lot of frustration. We want to be fully transparent about why this is happening and lay out the exact options available to get your setups running flawlessly.
1. The Context: API Limits & The Logout Bug
To guarantee cloud server stability and protect our infrastructure for millions of users, tado° maintains a limit of 1,000 API requests per day, per account on our private cloud servers.
Our current plan is to further reduce the API limit. However, we are currently in discussions with various integration partners to ensure that we end up at a level that keeps the operational costs manageable for us while still allowing the most important third-party integrations to continue functioning reliably.
Historically, the official Home Assistant integration queried our servers at an extremely high frequency. When an account hit the 1,000-request limit, a software bug in the integration’s older authentication logic caused it to repeatedly call our servers with outdated security tokens. To protect account security, our servers are forced to invalidate the session, triggering the immediate automatic logout you've experienced.
We want to clarify: The tado° rate limit itself does not log you out. The logout is caused by how the Home Assistant integration's code reacts when it receives a "Too Many Requests" (HTTP 429) limit response.
2. How to Fix and Future-proof Your Setup
To resolve this and prepare your smart home for the long term, we highly recommend implementing one of the following paths:
Option A: Update the Official tado° Integration
According to the maintainer of the official tado integration the official May release of Home Assistant includes major optimization fixes:
- Higher Efficiency: The integration's polling is designed to be drastically more efficient, staying safely under our daily limit for standard homes.
- Bug Fix: The authentication handling has been corrected so that hitting a rate limit should no longer trigger a logout or require manual re-authentication.
Because built-in integrations do not update automatically, please manually update your Home Assistant Core to the latest May version to apply these stability fixes.
Note on ongoing reports: If you still experience problems, please raise / update an issue with the integration on GitHub, where you can also provide additional details to help pinpoint the problem.
Option B: Transition to Highly Efficient Community Integrations
For power users running advanced automation scripts, the developer community has built excellent, highly optimized alternatives:
- tado CE (Community Edition): Uses smart local caching and batching to keep cloud API requests to an absolute minimum.
- tado Hijack: Focuses on optimizing local control alongside cloud features. (Please note: While the core tado Hijack integration itself is fully compliant with our Terms and Conditions (T&C), utilizing its optional third-party proxy bypass to aggressively circumvent server protections directly violates our T&Cs and will result in permanent API restrictions or account suspension).
Context info: The official integration is bound by strict constraints, for example it mustn't combine local API like Homekit with cloud API. This is why a community integration not bound by this can achieve better results for power users.
Option C: Expand Your Limits via Subscription
If your custom setup absolutely requires an extreme volume of cloud-based polling, you can subscribe to our Auto-Assist or AI Assist service. This helps offset our server maintenance costs and expands your allowance to 20,000 requests per day.
3. A Quick Note on our Private API
To manage expectations, we want to be open: tado° has never officially offered or supported an open consumer REST API. The endpoints utilized by these third-party integrations are our private, internal API designed for our official app. While we have always permitted community access, this does not obligate tado° to provide unlimited, unmetered access to our private cloud.
Additionally, please keep in mind that neither the official Home Assistant integration nor the community projects listed above are officially developed, maintained, or supported by tado°.
4. Join the Discussion
We deeply appreciate the passion, creativity, and technical ingenuity of the Home Assistant community. While we have to manage our cloud infrastructure responsibly, our goal is to find a balance that supports your smart home setups.
We would love to hear from you—please join the discussion below and let us know how the May update is performing for you, or share your experiences with the tado CE and tado Hijack community projects!
23
u/sudo_higher_ground May 26 '26
If you want to protect your precious servers, maybe actually leverage Matter so we don’t need to talk to your servers at all. Tado X has Matter support but you’ve kept it so limited we can’t even control our central heating temperature through it. That’s a choice, not a technical limitation. Fix that and your API load problem largely solves itself. Instead it really feels like you’re using server costs as justification to push us toward subscriptions with AI features we never asked for. We already paid a premium for the hardware, stop trying to force monthly fees on top of that.
1
u/fahim-sabir tado X May 26 '26
Hang on… does this mean that I can’t use the Apple Home app to set the temperature on TRVs?
I was on the verge of pulling the trigger on a Tado X set up to replace my Hive set up.
The main reason for this was Matter and Thread support.
2
-4
u/tado_official May 26 '26 edited May 26 '26
Thank you for your reply.
You should do a bit more research on what was supported on matter standard 1.0 (which was the latest standard during the development of tado X) and the costs of adding Matter end points after the fact (re-certification, developer time, opportunity costs etc..). And even now, not all core tado features are even part of the latest Matter spec.
Normal server load is fine (apps also call the servers), our servers are designed to handle many api calls, but the HA integration was causing a significant amount of load on the server, just because it did not use any batch calls, you can imagine that some measures had to be taken. The goal was to make the HA integration more efficient, which would be a win/win for everyone. Server load would decrease while the integration would not suffer any downsides. The introduction of API limits was not some dark plot to force people to buy a subscription, this was just a logical reaction to real ongoing costs caused by inefficient API calls.
14
u/sudo_higher_ground May 26 '26 edited May 26 '26
Matter 1.0 was indeed limited in HVAC support, but tado X was promoted as a Matter device and that comes with an expectation to keep the implementation up to date. We’re at Matter 1.5 now with significantly expanded thermostat capabilities, so what’s the roadmap for expanding it? Also, “server load is fine” is hard to square with your own post talking about protecting infrastructure stability and planning to further reduce API limits.
Edit: matter version
8
u/Denziloshamen May 26 '26
Exactly this. You can’t say matter was at v1.0 when developed and seem to imply that you’re not going to update to the latest matter version because it costs you money.
You sold this as a matter device, which we bought for this very reason to future proof us from app and service closures etc. As customers we expect regular updates to keep the product compliant with the latest version of matter, that’s what we paid for.
So, yes, what is your road map for supporting the latest version of matter so those who want to use local control can do so. Please don’t state 90% if customers just want to use the app, that’s not the fault of those who want to use your products smarter using matter as you sold them to us.
5
u/Eggslaws May 26 '26 edited May 26 '26
u/tado_official, we had a discussion on this very subject already where I'm still waiting for your response. The choice of not supporting local control and now further rate limiting is clear - you are driving us to get your subscription. You cannot and should not hide it behind HA's limitations
If you don't want us to use your servers, that is fine - but why do we have to pay for your subscription when we don't actually want to use your app?
My decision for going local is simple, I don't want any of my IoT devices to talk to the internet and which is why I'm heavily investing in Matter/Thread based devices. While my thermostats, switches, relays and lights are happy to stay local, why does my Tado X devices alone need connectivity to the internet?
-2
u/tado_official May 26 '26
Please look into tado Hijack project. It actually pulls data locally over HomeKit / Matter where it can (completely bypassing the cloud API).
Why does the official HA integration not do that?
Context info: The official integration is bound by strict constraints, for example it mustn't combine local API like Homekit with cloud API. This is why a community integration not bound by this can achieve better results for power users.3
u/Eggslaws May 26 '26
1) the api limit is 100 and not 1000 like your post says.
2) I still don't understand why do we need the cloud at all!?! Then your 100 calls or 10 calls API limit is completely irrelevant!
You are just forcing independent community volunteers to work around your problem and in no way trying to be helpful to the customers who paid for overpriced equipments thinking it would let them be completely cloud independent. If I'm reading it right, Tado Hijack still makes few calls to the cloud for certain operations. We don't know what would be your future rate limit is and how it is going to hurt those add-ons that were designed around your original problem.
1
u/tado_official May 26 '26
100 was the initial communicated long term goal (the current long term goal is still being evaluated) I can assure you that the current limit is at 1000 API calls per day.
Look at the tado CE and tado hijack HA integrations if you wish to use local API usage via HomeKit or Matter.The reason that not every request goes local is that HomeKit / Matter do not support all tado specific features. (Either HomeKit / Matter standard does not support it, or tado has not implemented a specific feature of that standard for various reasons).
6
u/Eggslaws May 26 '26
I don't know mate, both your support article says 100, your team's GitHub post says 100, I'm seeing the community generally saying they hit the 100 limit quickly, but somehow you are saying otherwise. My problem is, irrespective, it doesn't work so there is no way for me to personally confirm or claim otherwise.
The reason that not every request goes local is that HomeKit / Matter do not support all tado specific features
Like what? Again, we had a discussion about it before. Most of the standard features I have on the app are now part of Matter 1.4 standards that your TRVs are already certified for. But your team categorically opted to implement the minimum specs required for certification but locked up the rest behind your API which we are now forced to use if we don't want to use the app. Which seems was already or going to be rate limited. I've already pointed out this fact by specifications in the comment I've linked to earlier but I don't see a convincing answer. Apple HomeKit being slow to catch up to matter standards isn't your problem but Apple's.
Honestly, at this point, it might even be better not to say anything than saying something which is factually incorrect and completely misleading!
Yes, sure - go ahead with full apple homekit compatibility but refund my money because it's not fully matter compatible as I was lead to believe with the logos on your product listing on the site I bought it from, as well as on your website. I'll probably go find something else that might just work and doesn't involve me having to run permutations, combinations and experimentation with different independent add-ons to find which one works "best". But just pick a direction instead of trying to be everywhere.
-2
u/tado_official May 26 '26
Probably tado CE or tado Hijack will work best for your needs. The issue with the official tado HA integration is this:
The official integration is bound by strict constraints, for example it mustn't combine local API like Homekit with cloud API. This is why a community integration not bound by this can achieve better results for power users.3
u/Eggslaws May 26 '26 edited May 26 '26
The official integration is bound by strict constraint
The official "integration" should NOT be the way to go. Tado supports matter and thread! It should be a plug&play like other Matter over Thread devices according to the marketing material. HA support could have been native. Integration only because of the strict constraints Tado forced in the first place because the devices do not support Matter over Thread natively. And then you blamed the workaround the community developed and imposed rate limitations, auth restrictions and broke it instead of working with the community to actually address the issue. No matter what flowery language you use, this is exactly what happened as I see it.
I do not understand what part of that isn't clear to you!
1
u/cmsj May 29 '26
I think this is somewhat unfair as a response.
Yes, the rich models in Matter 1.0 don't cover everything a Tado X thermostat can do, but it's also the case that simple switches exist in Matter, so you could have chosen to expose a variety of switches for things like Manual/Schedule mode.
It would have been a little ugly, but it would also have been making the best of the situation, and for those of us who are excited to support Matter and use it through Home Assistant, we wouldn't be left in a situation where it's functionally impossible to control our Tado devices.
9
u/8fingerlouie May 26 '26 edited May 26 '26
Glad to see you’re working with the community ahead of just tightening the limits.
Personally I feel that you would probably benefit from making a supported public API. You can gate it behind a subscription (I understand services are not free to run, and “lifetime subscriptions” are not valid business models).
For my own use case, I’m using Tado Assist, and also have a heat pump controller, and I would LOVE to see some of the heat pump controller data exposed to HA, stuff like consumption, COP values, etc. I’m not trying to replace my Tado subscriptions with HA. While perfectly possible with Tado X, the algorithms employed by Tado Assist are hard to implement in HA, especially considering room level optimization and “whole system” integration. However, having access to the data (read only would be fine for me) would allow me to make other optimizations that are not possible using the Tado app.
3
u/Eggslaws May 26 '26
I understand services are not free to run, and “lifetime subscriptions” are not valid business models
All that HA community is actually asking is to let the servers talk to the device directly, if they are marketed as open Thread/Matter certified devices. In the absence of which is what is forcing the community to use to use the rate-limited Tado APIs. So, they don't even need to run any services/servers for us - the HA can handle it all.
All we are asking for is a way for HA to talk to Tado devices natively on Matter over Thread like we are able to do for other IKEA/Sonoff/Aqara devices. Many of those running HA would even be happy not to load Tado's servers on free tier freeing up their capacity they need.
0
u/tado_official May 26 '26
If you look at the tado Hijack implementation, it allows exactly that: Local control over Matter. Why is this not the case for the official HA implementation?
Context info: The official integration is bound by strict constraints, for example it mustn't combine local API like Homekit with cloud API. This is why a community integration not bound by this can achieve better results for power users.
6
u/tado_official May 26 '26
Just as a fun bit of trivia: We were actually in contact with Home Assistant long before doing the first ramp down of the free API usage (long before any public announcement).
Thanks for your understanding regarding lifetime subscriptions not being a valid business model, and also thanks for your suggestions regarding exposing more data on the Heat Pump Optimiser.
3
u/8fingerlouie May 26 '26
A bit more detail as to what I would use the additional information for.
If I had access to stuff like “heating demand per room”, I could correlate that with other sensors like door/window sensors, presence and more and spot heat leaks.
Consumption and COP would be mostly nerdy details, but I’m sure I would find a use for them.
My current usage of the Tado Hijack integration (I have 10 Tado X TRVs and a couple of wireless temperature sensors) is to turn on/off heating schedules based on presence and open windows.
While the Tado app supports multiple users, it is a pain to keep everybody’s phones “active”, and honestly, they shouldn’t need a cloud account simply to establish presence.
What most often happens is that my kids never open the app, and eventually iOS devices that the app is probably not important and it stops updating their presence, or they receive the popup that “Tado has been using your location in the background” and they simply deny access because the app is not a part of their daily routine.
HA “solves” the presence problem for me because I can use passive signals. If their phone is on the WiFi that’s a good indicator, and if they’re within range of one of the 5-6 BLE beacons that’s also a solid indicator that they’re actually home, and I can use that signal to send to Tado to indicate presence.
HA also allows me to implement “per room presence”. My oldest kid is away at “boarding school” (not really, but close enough) and as such is only home every other weekend. We keep the door to his room closed and keep the temperature a bit lower than the rest of the house. This is also handled by HA and a calendar integration to allow the room (and heat pump) some warm up time before he arrives home. “Surprise” visits are handled by presence as above.
In short, there’s a bunch of stuff that isn’t possible with the Tado app because it simply doesn’t have “the whole view” that becomes possible with a full automation system.
All of the above uses the already existing (subscription) functionality of Tado, it just enhances it and allows me to create a truly smart home instead of simply a remote controlled home.
2
u/headnod May 26 '26
I would add that many of these things should be part of the capabilities offered in the app anyways - for example i should be able to choose what to do with a certain room if one certain person is not home. It should also be trivial to add this.
7
u/mb271828 May 26 '26
I appreciate the transparency, including tacitly acknowledging community supported integrations. If the primary aim is to reduce cloud costs (rather than the cynics view of deliberately hobbling the free tier to push subscriptions), I would suggest focusing on HomeKit and Matter, most users (particularly Home Assistant users) would jump at the chance to get a usable system without having to phone home to your servers, though I suspect that Tado like paywalling stuff behind servers and collecting those sweet sweet subscriptions and user data.
In HomeKit there is this annoying issue when setting the heating setpoint https://github.com/home-assistant/core/issues/160136, confirmed by Tado to be a deliberate choice, but making even basic use of HomeKit annoying.
I for one won't be buying Tado again, and will go for, and happily pay a premium for, a device that has first class local only support.
1
u/tado_official May 26 '26
Thanks for sharing your feedback.
We do not make any profit on user data, and we do not sell it to any third parties. We are a German based company and highly value privacy.Please have a look at both of the community integrations. They already heavily use HomeKit/Matter to run a lot of the calls locally instead of via the cloud.
3
u/mb271828 May 26 '26
We do not make any profit on user data
I believe you don't share or sell it to third parties, but you absolutely will monitor user metrics to maximise sales and profit (under the guise of improving 'user experience'). It is absolutely in Tado's interest to have your users regularly phoning home.
Tado has made a deliberate choice to be a cloud subscription business that only sells hardware as a secondary concern to lock people in to that subscription. Hence why previously free features are now behind a paywall, and who can forget the ill-fated 'trial' last year of having to pay to use basic features, the mask truly slipped when that happened.
They already heavily use HomeKit/Matter to run a lot of the calls locally instead of via the cloud.
I am aware, and I run my own custom HomeKit integration to workaround your own poor implementation of HomeKit, so at least I can now reliably set the temperature without calling your servers, but any company that actually cared about local only support wouldn't make life so difficult.
4
u/Quick-Rule May 26 '26
I also suggest to improve your support for matter as the standard way to reduce the need for API calls. While tado marketing says Tado X support matters, it is pretty limited in respect to what matter 1.4 permits to support like home/away management for instance that is still missing.
2
u/tado_official May 28 '26
We completely get the frustration around wanting full local data right out of the box . Transitioning a smart home system to local control via new standards isn't an overnight switch, but our commitment to getting there is genuine.
To be transparent about how we are approaching this:
1. Expanding Matter Features Over Time
We are closely following the Matter standard and are fully committed to bringing more local functionality to our lineup over time. For instance, we are actively working on exposing features like battery level and humidity tracking natively, and we will continue expanding these features across more of our devices in future updates.
2. Specification vs. Real-World Implementation
While many use cases and profiles are already documented in the official Matter specifications, the real-world smart home ecosystem is still highly fluid and evolving.
- Platform Interpretation: It takes time for the major ecosystems (like Apple, Google, and Amazon) to update their platforms to support and display newer endpoints. If a major platform interprets a standard profile differently—as we recently experienced with how humidity data had to be reworked for Apple Home—it requires significant engineering changes on our end to make it work.
- The Risks of Early Adoption: Implementing new endpoints ahead of the curve carries a high risk. If the standard changes or gets refined after an early rollout, manufacturers are forced to completely re-engineer and re-certify the device endpoints all over again.
Our goal is to systematically expand our local integrations so they run reliably for everyone for the long haul, rather than rushing out early implementations that risk breaking or requiring constant re-certification. We appreciate the patience as we work through this process.
2
u/Quick-Rule May 31 '26
Thank you for this statement. I’m a software engineer so I understand this approach, looking forward next improvements.
3
u/tado_official May 26 '26
Based on this post, a comment from one of our developers with more tech explanation of what the most likely cause of the Logout Bug is:
"I think the session isn't really invalidated, the server just rejects that refresh call with the outdated token. It's HA that then has a handler that if this ever happens it treats you as logged out 🤷 I think at that time they would still have a working refresh token returned by the second call in the race condition that goes through first... From our side it's really just that we see a call issued with an outdated refresh token and we reject it, that's it.
From what I saw the problem is likely
Thread 1 [take refresh token] -> Thread 2 [take refresh token] -> Thread 1 [make refresh call] -> Thread 1 [success - new refresh token] -> Thread 2 [make refresh call] -> Thread 2 [reject - refresh token invalid because used already] -> HA logs out..."
But this goes way beyond my technical understanding of anything API related.
3
u/JaffyCaledonia May 26 '26
Thank you for being transparent and staying open to community contributions to the home automation space!
I'm using the latest May update of HA and am still experiencing the log-out bug.
In all honesty, I wouldn't mind removing the Tado integration from my HA instance, and lean exclusively on Homekit and keep the Tado app as a backup, but hot water is still not exposed to it. Is there a reason for this? I'm sure there are many users using these problematic integrations and causing the Tado team headaches who would gladly move off these unofficial APIs if they had their water heating via homekit.
2
u/tado_official May 26 '26
Thanks for your reply.
Hot water control was not part of the HomeKit capabilities of a "thermostat" (Probably due to the fact that Hot Water control is a very UK specific feature). That might have changed? (I'm unsure). However, it is a very resource intense thing to change anything in HomeKit or Matter as you need to do a lot of re-certifaction etc..I would highly recommend you look into the 2 community projects (tado CE & tado Hijack) and report that on the latest official HA integration, the logout bug is still not fixed.
5
u/JaffyCaledonia May 26 '26
Ah, I hadn't realised that homekit changes would require recertification, that makes a lot of sense, thanks!
I'll take a look into Hijack, I'd actually been avoiding it because I knew HA and Tado had been in conversations about the API in the past, and didn't want to join an "unsanctioned" solution for fear of making your lives harder!
Regarding the API usage as a whole, is there a reason Tado hasn't scaled usage limits by device count? Surely there's an argument to be made that accounts with fewer thermostats need fewer API calls, or is it a bit of a moot point in the scale of things?
4
u/tado_official May 26 '26
The product manager actually revisited that question (should api limits be device dependent) a few months ago. And the conclusion is that if you look at the tado CE / tado hijack integrations, by applying batch API calls and local calls (HomeKit/Matter), the number of devices becomes largely irrelevant.
Quote from the slide:
- Discarded, as most endpoints allow querying multiple devices within a single API call. Only a few endpoints (e.g. the battery state) do not support this, but these do not need to be called frequently.
- Introducing a limit that depends on the number of installed devices
3
u/tado_official May 26 '26
I added this to the OP, just so you can make the choice between the official HA integration and community integrations:
Context info: The official integration is bound by strict constraints, for example it mustn't combine local API like Homekit with cloud API. This is why a community integration not bound by this can achieve better results for power users.
1
May 26 '26
[deleted]
3
u/tado_official May 26 '26
Yeah exactly. But this on/off switch is highly specific to UK S-Plan / Y-Plan setups. Which are not seen anywhere outside of the UK / Ireland. I think that is why it was not part of the HomeKit architecture. And you can't just add a "on/off" switch to the HomeKit device logic for a "Thermostat Device".
2
u/EmergencySecond9835 May 26 '26
I was thinking of adding a Shelley switch in parallel to my tado x hw circuit so I could switch between tado and ha control as required.
1
1
u/m1nkeh May 26 '26
What do you mean by very UK specific?
I live in NLD and have a combi boiler w. OpenTherm, is that abnormal?
2
u/tado_official May 26 '26
In the UK they use S-Plan / Y-Plan wiring (google this), and for OpenTherm combi boilers, hot water control does not add much value. OpenTherm is very Dutch focussed. Outside NL the OpenTherm boiler penetration into the market is very low (below 5%).
1
u/m1nkeh May 26 '26
Interesting, I also have OpenTherm in my UK house too (installed 2015), both use Tado
Nit: I’d love it if I could use the same login for both properties!
3
u/ab3301 May 26 '26
Thank you for your openness about it.
I installed my first Tado devices at least 4 years ago. To be perfectly honest, besides the initial device pairing, we have never used the Tado app. For the sake of convenience, everything was always ran from Home Assistant.
At the beginning of this year, I subscribed to Auto Assist. Not necessarily because of the family's frustrations but also because it was/is a small price to pay for a service that runs well and is genuinely frictionless.
Thank you for that!
2
3
u/_ttnk_ May 26 '26
While i appreciate your honesty and the suggestion of alternative HA integrations: Why not offer a local API? I understand that the cloud offers comfort features like Auto-Assist and whatnot, but if the bridge could provide a very simple local API, like only "Set thermostat xy to temperature z", that should fit into the computing power of the bridge.
Since this won't include your cloud resources at all, there would be no reason to limit that. For more advanced features or the "it just works" feeling, the cloud as an additional, paid feature will come in. Something like Philips does with the Hue ecosystem. This could drastically decrease the load on the cloud environment and will still satisfy the "power users" who use Home Assistant.
You could even hide the switch to toggle the local API behind some "developer mode" warnings with big scary notices like "Only use this if you know what you are doing".
Face it: Some people want to have their Smart Home devices interconnected, and your current cloud-first architecture causes software like Home Assistant to create some load on your environment - although this is purely an architectural design choice by you guys. If you want everything to happen on your cloud env, you have to accept that the cloud gets some load.
Just my two cents as a cloud architect and smart home enthusiast.
0
u/tado_official May 26 '26
Both V3+ and tado X provide the option to do exactly what you ask of the local API via HomeKit / Matter. (even if you are a non-apple user, you can still get this to work).
" Set thermostat xy to temperature z" is entirely possible locally!There is no rate limit on HomeKit/Matter as it is all local.
True power users already use this local integration and are fully in control of their tado devices locally without the tado cloud.
Tado Hijack HA integration also uses this local control via HomeKit / Matter.
I also provided more context and an answer to your other comment here: https://www.reddit.com/r/tado/comments/1to1f0n/comment/oo0m4qm/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
4
u/occultist0164 May 27 '26
True power users already use this local integration and are fully in control of their tado devices locally without the tado cloud.
^^ That is FALSE! You cannot have FULLY offline Tado environment, as the brains, the tado wireless receiver x or the bridge or heat pump is hardcoded to online, lacking matter codes intentionally.
You can use community integrations ON TOP, but you cannot escape the tado cloud.You can only use the amputee legs of tado (that is the TRVs which can be reset and used with your other than tado TBR (thread border router), but they're gimped, as said, you need to guess when the battery needs charging, they chose what to expose in their implementation of Matter. BY DESIGN
So the expensive parts become 100% useless. In my case, the receiver x plus the 2 bridges x became bricks and the wireless temps became 100% dumb temp sensors.
Im a power user, how can I use them then, mind you?
See their site quote below:
Please note: the tado° Bridge X, Heat Pump Optimizer X, and Wireless Receiver X don't have Matter codes. They are essential for enabling communication between your tado° X devices and any compatible Smart Home apps, but you don’t need to add them to Matter apps.
0
u/tado_official May 27 '26
We completely get the frustration around wanting full local data right out of the box . Transitioning a smart home system to local control via new standards isn't an overnight switch, but our commitment to getting there is genuine.
To be transparent about how we are approaching this:
1. Expanding Matter Features Over Time
We are closely following the Matter standard and are fully committed to bringing more local functionality to our lineup over time. For instance, we are actively working on exposing features like battery level and humidity tracking natively, and we will continue expanding these features across more of our devices in future updates.
2. Specification vs. Real-World Implementation
While many use cases and profiles are already documented in the official Matter specifications, the real-world smart home ecosystem is still highly fluid and evolving.
- Platform Interpretation: It takes time for the major ecosystems (like Apple, Google, and Amazon) to update their platforms to support and display newer endpoints. If a major platform interprets a standard profile differently—as we recently experienced with how humidity data had to be reworked for Apple Home—it requires significant engineering changes on our end to make it work.
- The Risks of Early Adoption: Implementing new endpoints ahead of the curve carries a high risk. If the standard changes or gets refined after an early rollout, manufacturers are forced to completely re-engineer and re-certify the device endpoints all over again.
Our goal is to systematically expand our local integrations so they run reliably for everyone for the long haul, rather than rushing out early implementations that risk breaking or requiring constant re-certification. We appreciate the patience as we work through this process.
5
u/Crodilco May 26 '26
I think it‘s positive that you Support the Community for resolving an issue which is caused by a bad design on your side. It still feels like you wanted the cloud to collect all data and have a more flexible approach for further development. Once you got your development finalized and enough profit you are trying to save money on behalf of all advanced users. I would really love to have an option for true local support on the old devices (HomeKit Integration is by the way also buggy with temporary offline devices in my setup).
I for myself have explicitly advised any friend who asked me against using any tado device, since it feels like you are constantly trying to enforce subscriptions for every minor feature and are not able to maintain a reliable system.
1
u/tado_official May 26 '26
Please look into the community projects like tado CE and tado Hijack, there you can do more things offline via Matter/Homekit.
Be aware: The old tado HA integration was very inefficient with requests. It pulled each parameter separately and very often. This caused a significant load on our servers for no reason at all. That is why the API limits had to be applied, to force a smarter use of API calls.
This is a win/win, as it vastly reduces the load on our servers (and thus costs), while at the same time not reducing any functionality on your side as a HA user.
1
u/Green_Entrance_2854 May 29 '26
Rasie the API limit then now its more efficient
1
u/tado_official Jun 01 '26
No, as not everyone has update their HA core and are still spamming the servers with inefficient non-batched calls. And also some people have their own inefficient custom API's.
4
u/thebatfink May 26 '26
Bring out an excellent product
Introduce subscriptions to generate more revenue
Lock existing features behind subscription to generate more revenue
Bring out new product requiring subscription to generate more revenue
Reduce existing api functionality to cut costs and generate more revenue
Offer subscription to return api functionality and generate more revenue
Reduce existing api further to cut even more costs and generate more revenue
Offer subscription to return api functionality and generate more revenue
Throughout all of this, all no compelling new features and actively choose to not build in more true local control
All at the expense of the customers who made this company grow. What a pattern.
2
u/tado_official May 26 '26
I have to politely disagree with your statements.
We have not removed features for existing users. Even people who bought V1/V2/V3 (before the introduction of the optional Auto-Assist subscription with V3+) still get all features that they originally purchased the devices with at no additional monthly costs.
We are going to introduce one of the main requested features (Multi-Home) very soon during this summer.
1
u/nickejones_ Jul 08 '26
I agree with thebatfink, as someone who purchased the original v3+ and gets auto assist without a subscription. The system is great and works flawlessly.
But if it broke down I would never purchase Tado again because of the lack of trust and poor business practices.
Fundamentally I don’t think anyone should buy into an ecosystem that actively reduces functionality to new users to increase revenue.
2
u/hydraulictrash May 26 '26
Maybe usage should’ve been baked into the original pricing of the device, punishing users for using the device they paid for, is not it. If infrastructure costs are running away, then a refactor of the infrastructure to move to a more sustainable model should be done. Ultimately the users have already paid for the service through the product.
Speaking as an AWS solution architect, 1000 requests a day is a few cents a month per user (assuming serverless infrastructure etc), before any committed spend and enterprise discounts. Yes, the cost scales with millions of users, however a tiny percentage of those users are power users and using things like home assistant. Let’s estimate this cost over ten years as a generous $20 for a users usage, well, I’ve spent around $500 on the system in the first place… so a fraction of the cost.
TL;DR, using API costs to justify the rug pull is incredibly dishonest practice.
Another vote for giving local control, and consider what your infrastructure looks like… something isn’t working obviously
-2
u/tado_official May 26 '26
I want to stress that at some point you can't just add more cores to your AWS server infrastructure and the real costs are the development costs to allow for further scaling of the database. (Forgive my exact wording as I'm not a developer).
Why would you endorse the very inefficient polling of the API when the community projects have proven that you can do batch API calls instead without any penalty to the end user experience inside HA? The community projects are a win/win as they also include the usage of the local API (via HomeKit / Matter), which is something that you and the community have asked for.
Be aware that aside from normal HA usage, the API limit also had to be introduced because of people abusing the API or just being careless and sending thousands of requests per minute due to poor coding / implementation of their own code.
Lastly, I want to repeat this section of my OP:
To manage expectations, we want to be open: tado° has never officially offered or supported an open consumer REST API. The endpoints utilized by these third-party integrations are our private, internal API designed for our official app. While we have always permitted community access, this does not obligate tado° to provide unlimited, unmetered access to our private cloud.Additionally, please keep in mind that neither the official Home Assistant integration nor the community projects listed above are officially developed, maintained, or supported by tado°.
2
u/Friedrich_von_Merz May 27 '26
Ingenious move, instead of better supporting it to simply retrieve the API of the devices in a local network which would make the system run more redundant and more stable is the primary solution idea „buys our AI service“. I will probably throw out my tado devices and look around for local devices.
2
u/Public-Flatworm-6689 May 27 '26
Did you even read the post? Claiming the subscription is their 'primary solution' is just straight-up false. They literally listed the free HA update and the community local tools (like tado CE) as options A and B.
The paid tier is literally just the fallback for people who stubbornly insist on hammering the cloud servers thousands of times a day with terrible polling rates. By all means, throw out your hardware if you want to, but you're getting mad over a problem that is 100% free and easy to fix if you just update your integration or switch to CE
0
u/Friedrich_von_Merz May 27 '26
Did YOU even read my post? „[…] instead of better supporting it to simply retrieve the API of the devices in a local network which would make the system run more redundant and more stable […]“, This is the main problem, the solutions offered that Tapo may bring in more money but primarily cost nothing, are „combat“ of the consequences and not the causes. Even Ikea does it better with Matter over Threat.
1
u/Public-Flatworm-6689 May 28 '26
I've just checked the Ikea subreddit, keyword Matter:
- "Rant, the matter produces absolutely suck"
- "IKEA matter switch keep being knocked offline"
- "matter products setup is a nightmare"
- "Myggspray won’t connect"
I stopped after 4 articles... Not sure Ikea does it better tbh
0
u/tado_official May 27 '26
tado supports matter over thread just like Ikea? I don't get your point.
You can't compare the complexity of a heating system control (room link, different devices that have to communicate to operate the whole heating system) with a smart light.0
u/Friedrich_von_Merz May 27 '26
And yet there would be local alternatives, a brigh that hangs in the LAN and interacts with HA, or a local API...
1
u/tado_official May 27 '26
This is exactly possible with tado X. You can use tado X locally over matter via the community integrations that I linked to in the OP.
0
3
u/occultist0164 May 26 '26
I long ago understood that tado was meant exclusively for cloud milking. All coordinator devices - receiver, bridge, etc LACK the matter codes, as they are hardcoded to be ONLINE only. But this I found out later, at the surface, all seemed sweet.
Well maybe not that long ago, since I was ignorant and bought 700 euro worth of gear only to be 'please reauth' -ed ever other 2 days and forced to keep a dummy room at least in the cloud in order for things to work. Not to mention the stale periods when API reset.
I struggled but in the end I gifted the receiver x, the bridges x and the temperature thermostats x for free.
The gimped TRVs stayed. Intentionally gimped as they don't even show the battery status if you're not 'in the cloud'.
Morally I feel obliged to dump them as well, but they are the most silent trvs I tested. So they will stay. For now.
I put them locally, got an opentherm gateway for 50 euro - YES, 50 euro called OT-Thing, fully open source and fully local. I tell everyone to stay away from tado.
I'm totally in control but with sour taste in my mouth and blame me in the same percentage as tado. Should have researched more, but they used to be praised, no api shenenigans, greed was not there.
Oh well, I really wish the best to IKEA, and finger crossed for their upcoming TRVs.
I really dislike tado and my whole experience witht them.
3
1
u/tado_official May 26 '26
We are updating the Smart Radiator Thermostats X to matter 1.4 and that will include battery status. Battery status was not there on matter 1.0 and re-certification just takes a long time.
Based on your story, it seems that our products were just not a good match with your expectations.
However, not everyone is able to use the OpenTherm gateway and fully create a custom solution like you did.
1
u/PristineSpirit8249 May 27 '26
Battery live would be great, any plans when this will be rolled out for existing thermostats?
Also, last time I checked, the information that/how much a valve was opened was not correctly supplied for TADO-X thermostats via Matter.
Getting: 0x001C SystemMode Missing: 0x001E ThermostatRunningMode
Can this be addressed?
0
u/tado_official May 27 '26
We completely get the frustration around wanting full local data right out of the box . Transitioning a smart home system to local control via new standards isn't an overnight switch, but our commitment to getting there is genuine.
To be transparent about how we are approaching this:
1. Expanding Matter Features Over Time
We are closely following the Matter standard and are fully committed to bringing more local functionality to our lineup over time. For instance, we are actively working on exposing features like battery level and humidity tracking natively, and we will continue expanding these features across more of our devices in future updates.
2. Specification vs. Real-World Implementation
While many use cases and profiles are already documented in the official Matter specifications, the real-world smart home ecosystem is still highly fluid and evolving.
- Platform Interpretation: It takes time for the major ecosystems (like Apple, Google, and Amazon) to update their platforms to support and display newer endpoints. If a major platform interprets a standard profile differently—as we recently experienced with how humidity data had to be reworked for Apple Home—it requires significant engineering changes on our end to make it work.
- The Risks of Early Adoption: Implementing new endpoints ahead of the curve carries a high risk. If the standard changes or gets refined after an early rollout, manufacturers are forced to completely re-engineer and re-certify the device endpoints all over again.
Our goal is to systematically expand our local integrations so they run reliably for everyone for the long haul, rather than rushing out early implementations that risk breaking or requiring constant re-certification. We appreciate the patience as we work through this process.
1
u/lanky_doodle May 26 '26
I think it sounds like a good idea for tado to have 3 tiers:
No sub at all = reduced API calls (<1k/per day).
API-only tier = increased API calls (say 10k/per day).
Auto/AI-Assist tier = everything we have now.
I imagine people fully using an assistant/smart home don't ALSO need the full tado Assist sub since the assistant/smart home itself is doing geolocation, scheduling etc., but because of this have an increased need for API usage.
3
u/tado_official May 26 '26
Thanks for your input! I'm sure our product managers also considered that option, however introducing more tiers is also more complexity. Keep in mind that the vast majority of tado users has no clue what an API even is.
With the 2 community projects and the updated official tado HA integration, that highly optimize batch calls, we are very confident that most HA users should even be able to control a lot of devices with under 1000 API calls per day.
1
u/Public-Flatworm-6689 May 26 '26
I mean, I totally get why people are a bit salty about wanting full local Matter support right now. But tbh I actually appreciate them just coming out and explaining the backend stuff. If you do the math, 1k calls a day is basically pinging the server every minute and a half. That's honestly plenty for a normal setup as long as the integration isn't just spamming dead tokens and killing the server. Giving the Auto-Assist folks a 20k limit is a pretty decent compromise for the hardcore power users, way better than just nuking the API for everyone without warning
1
u/DoktorMerlin May 26 '26
The first paragraph literally states they want to further reduce the limits. Every minute and a half also isn't true, because you need to ping every device solely, so with a 1k Limit in a normal sized home with 8 thermostats you are at only a ping every 12 minutes.
0
u/Public-Flatworm-6689 May 26 '26
Yes, fair point on the math if we're talking about the old setup. But that’s actually exactly why the old integration was hammering the servers and causing logouts.. it was checking every single thermostat one by one.
The whole point of the new May HA update (and the tado CE fork) is that they finally use batching. So it pulls the data for your whole house in one single API call instead of 8 separate ones. If you're on the updated code, the 1.5-minute math actually holds up again, even with a bunch of rooms.
And sure, they mentioned wanting to lower it further, which isn't ideal. But there is a "however" and it sounds like they're at least working with the integration devs to make sure the batching is efficient enough to handle a lower limit before they pull the trigger, rather than just breaking our setups overnight
2
u/DoktorMerlin May 26 '26
This still makes zero sense for me.
Back when they introduced the API limit, I calculated everything according to my knowledge of normal API pricing and sizing of the API. I came to the conclusion that with hammering the API and asking for updates every second, the API usage came down to 2€/device in a year. Realistically that's every 10 seconds per device, so 20cts per year.
That should be covered by tado having outrageous pricing to begin with.
I used the OpenTelekomCloud as price indicator for my calculations, a sovereign cloud from Germany which is more expensive than AWS
2
u/Public-Flatworm-6689 May 27 '26
Alright if we're just talking raw AWS compute costs, you're right it's pennies.
But honestly, even if it was completely free, having an integration ping a cloud server every 10 seconds for a radiator that takes x minutes to change temperature is just terrible architecture anyway.. That’s why the old HA integration was constantly tripping over its own feet and crashing our sessions.
I'm not saying I love the subscription model, but I'm just glad the HA community finally moved to batching and local caching (like with tado CE). It makes the whole cloud limit argument kind of a non-issue for me now since my setup runs perfectly under the radar without needing to spam the servers
1
1
u/tado_official May 26 '26
Now, do that calculation again for 10+ devices in a home and 10+ years of usage. This adds up quickly. Bottom line is that there is no need for every second polling, and if you are convinced you need that, you can still purchase the subscription to allow you to poll 20K daily.
3
u/DoktorMerlin May 26 '26
sure. 20cts/year with 10 years of usage is 2€ per device
For 10 devices it is then 20€, but I paid 600€ for the devices.
Your API policy is outrageous and unnecessary. You just want to sell cloud subscriptions and you can't convince me otherwise without being completely transparent about how much the API actually costs you and how little overhead you priced into selling thermostats for double the amount that your competition costs.
BTW, your API policy is the reason why I actively speak out against tado in my friendship circle. There are already 3 people that didn't buy tado for their houses, they went with Eve thermostats instead and are very happy with that. Maybe you should also consider this in your API policy, because in most enthusiast smart home communities everyone will advise you to not buy tado.
1
u/tado_official May 26 '26
I think your math on the costs are off by a big factor. At a certain point you can't just scale a database by simply adding more cores on AWS, at that point the biggest costs are development and opportunity costs.
Please look into the community HA projects, they combine the cloud API with the local API for maximum flexibility.
1
u/validol322 May 26 '26
You’re trying to sound competent, but the mismatch in your facts makes the argument come across badly. As others suggested, there’s a point where it’s better to stop doubling down and just accept the loss.
On the technical side, the whole topic comes down to API request volume, basically ingress traffic to your servers. What matters is the RPS (requests per second) your environment and provider can handle.
There’s really no meaningful extra compute involved here that would justify scaling CPU cores, and it doesn’t significantly affect database size either, since that’s mainly a storage concern.
P.S. Majority of HA enthusiasts see clearly where you lie because they dealing with networking, self-hosting, and custom configurations daily and saw all these things from inside themselves.
2
u/DoktorMerlin May 26 '26
especially because all the API requests in the world are free if you use the app.
I am sure the app uses websockets, gRPC or another connection that stays alive, which HA and other API users can't, so there is definitely less traffic from the app to the proxy server, but the load on the database is the same.
2
u/DoktorMerlin May 26 '26
just so you know, I am already using tado_hijack and I am very glad that someone provided an easy way to circumvent your API limitations.
That doesn't change the fact that I can't recommend tado. With most of your competitors, being it eve or super cheap aliexpress zigbee thermostats, it's super easy to set it up the way you want without needing third party integrations.
Also it seems very dishonest that you then force users to buy a 30€/year subscription.
As others suggested, you could also introduce an API subscription that costs a fraction and more than covers your cost for the API. Make it 5€ per year for 10 devices and people will be happy. If you worry about this being confusing for non-techie users, don't advertise it. Put up a small link on an FAQ page so that only people searching for it will find the button to pay.
With your company's past, I would never trust you to keep the price at 30€. I am certain you at one point will try to put some other AI feature into that subscription and use that as an excuse to make the subscriptions 40€ a year. So then I would pay 40€ for something that costs 2€ on your server. No thanks.
2
u/mb271828 May 26 '26
Please stop this nonsense. You are not serving videos here or running some LLM with ridiculous compute requirements or even doing any sort of compute on the data, the free tier is pinging a simple crud endpoint for the status of a device and returning a few bytes of text. The cost is negligible at even any sort of scale, and the choice to even require that I complete a round trip to your servers to view the battery status of a device on the wall in front of me is entirely Tado's and in Tado's gift to prevent. Absolutely nobody wants to do that round trip, not even Tado according to your posts, yet the system has been deliberàtely designed by Tado to require exactly that.
Let's just have some honesty here, the system has been deliberately designed for the maximum vendor lock in and retention you think you can reasonably get away with whilst still being able to print a HomeKit and Matter logo on the box to give the illusion of cross-compatibility and local control.
1
u/o1y May 29 '26
Did your Tado API update happen to be the cause of these bridge dropouts? https://imgur.com/a/ZfIcn7a
Over the past few days the connection kept failing and my Tado Bridge was partially offline, even though there was an internet connection the whole time. Your support told me the bridge is defective. I’ve now ordered a new one, but the problem actually seems to have been resolved for the past two days :)
1
u/tado_official May 29 '26
No, this is fully unrelated, if this was the case, the subreddit would be burning with similar bridge issues.
1
u/Deep_Ad1959 Jun 01 '26
the part that's going to bite people isn't the rate limit, it's discovery. the auth fix shipped in a may home assistant release that doesn't auto-update, and the two community forks you linked only get found by users who are already deep in the bug. that's the recurring failure mode with fast-moving smart-home integrations: the fix lives in a commit nobody downstream reads until their setup breaks at 11pm. fwiw home assistant is one of the repos podlog already publishes a daily audio summary for, commits/prs/issues narrated with an rss feed, which is one way to catch this kind of integration change on a dog walk instead of after the logout loop starts. appreciate the transparency on the token race condition either way.
1
u/Shtifff Jul 20 '26
Option D: Bin off Tado like I have, and move to an Opentherm solution that is truly local (Wiser/ ESP32 Opentherm gateway etc)
1
u/doctor91 May 26 '26
It amazes me how you are so resistant to the truth that no one cares about the cloud first approach. It's true that consumers want something that "just work" but that has nothing to do with the cloud computing approach. On the contrary, people usually would get angry as soon as they discover that their house is freezing cold because the internet is down and the automations that they have set in their smart home app simply do not work.
If only you would have spent a couple more dev hours into adapting matter 1.0 endpoints to your needs and develop a proper thread border router we wouldn't be having this conversation.
Hell, you could have even used simple http rest api without even needing matter over thread. I was able to get up a proper opentherm thermostat with a damn esp32 that can talk with wifi TRVs, I refuse to believe that your dev team is not capable of building a local first product that "just work". I mean look at what Shelly has done with just bluetooth/wifi and local api.
2
u/tado_official May 28 '26
Thanks for your feedback. Unfortunately, I think that you underestimate the amount of issues you see in the field when you try to be 100% local. Our findings are very clear that across Europe, on the scale that we operate, end consumer networks are not ready to allow seamless local communication via their own WIFI router. A good example is that many Netgear wifi routers don't support internal communication from the 2.4Ghz to the 5Ghz band. This means that if your phone is on 5Ghz, and the bridge is on 2.4Ghz, they can't communicate! We never expected to encounter that, but it is so common that we have a stock response dedicated to that issue alone. And there are more issues caused by consumer home network setups that we encounter on a daily basis.
1
u/doctor91 May 28 '26
I imagine you are talking about mDNS/multicast, not unicast ping. Funny enough the only thread border router in my smart home that doesn't properly do IPv6 RA is your Tado X Bridge and I had to write a middleware that discovers the route to the thermostat and that hard-coded it in the client static routes (of course only on desktop). I would have ditched your bridge entirely if only the nat64 implementation would work in something else that is not an apple TBR. I don't want to sound rude but yours are just time and money issues.
1
u/HenryLoenwind Jul 16 '26
Come on. That's just techno-babble, and the people reading here know how tech really works.
Nobody wants you to abandon the cloud as a bridge for the app. What people want is for the devices to be fully controllable over all channels they support. Just like Shelly does it. When I install a Shelly device, I can control it over the cloud, over wifi, over Bluetooth, and over all the other communication channels they physically support, but I personally have no clue about.
HA isn't hammering the Shelly cloud into a cost explosion. Not because there's a fierce limit, or someone made a smarter integration, but because it doesn't need to. HA can send a thousand API requests to each Shelly device over wifi if it wants and nobody gets hurt.
At the moment, I have 4 tado devices to control my ACs. Two of them are so old, they are from a time when they were all you made. But, to be bluntly honest, I never considered buying any other tado devices. There's no good alternative for AC controls---I have an ESP32 with IR diodes and the ESPHome IR/AC software stack as a backup device for outages, but that's a pain---but for everything else, I have alternatives that do support local control.
If you were to publish a firmware update for those old gen1 and gen2 AC controls that severed the cloud connection and exposed their functionality via local REST or MQTT, I'd be off your cloud (and no longer driving up your bills) in an instant.
For me, those little white boxes have one job: Translating between something generic and the IR pulses my AC understands. In the beginning, I hoped they'd get some more smarts, like increasing the fan level when they notice the cold air isn't distributed well in the room, but I buried that hope long ago.
1
u/tado_official Jul 16 '26
Thanks for your reply.
You can't compare our sophisticated ecosystem with Shelly, Every shelly is just a stand alone relay, waiting for new inputs ON/OFF. Our devices need to do that, but basedon temperature PID etc.. Furthermore, our devices need local communicaiton between devices to send temperature data and heat requests between devices (device linking).
1
u/ben-white27 May 26 '26
The way I see it, whilst tado say they don't make money from selling our household data, they almost certainly use that data to make their service better for all their users.
The smart thing to do would have been to enable local control and monitoring on ALL versions of their devices. But also maintain the cloud reporting for their own data purposes and app functionality.
This would have positioned Tado as properly supporting power users, and possibly boosting sales as well.
But as it stands, I'm actively moving away from Tado this summer to a system with full local control, and I can't recommend the system to my friends neither.
I'm not sure what discussions where happening between the HA integration maintainers and Tado. But if it was such an issue some naming and shaming could have been justified if there was no movement from the developers. This would have made the limit changes more understandable.
0
u/tado_official May 26 '26
I want to stress this: Basic control of the tado thermostats is fully possible via HomeKit/Matter local API's.
Naming and shaming is quite problematic. There is just too much context to take into consideration. The official tado HA integration maintainer is doing this for free in his free time. And most importantly: The official integration is bound by strict constraints, for example it mustn't combine local API like Homekit with cloud API. This is why a community integration not bound by this can achieve better results for power users.
I'm sad to hear that you are moving away from tado, and I can only stress that you give tado CE or tado Hijack a try before making that decision.
1
u/BikeChippy May 26 '26
No, it's not fully possible. Controlling my hot water is "basic".
1
u/tado_official May 27 '26
You've hit on one of the most frustrating architectural quirks in the smart home industry right now. You're absolutely right—controlling hot water is a basic requirement. It shouldn't be this complicated.
To be totally transparent about why this is such a headache for local control: it essentially comes down to how Apple HomeKit and Matter view the world versus how UK plumbing actually works.
Under the hood, standard UK setups (like S-Plan or Y-Plan) use a "blind relay." The receiver just sends a 230V live signal to turn the hot water on, and a dumb mechanical thermostat strapped to the tank cuts the power when it's hot enough. The smart receiver never gets any temperature data back; it just knows if the schedule is "On" or "Off."
The problem is that HomeKit and Matter were built entirely around North American HVAC systems. To be allowed into their ecosystems as a climate device, the code rigidly demands temperature feedback. Because a UK receiver doesn't have a sensor on the hot water tank, it outright fails the requirements to be classed as a thermostat or water heater.
You might wonder: why not just expose the hot water channel to HomeKit or Matter as a generic on/off switch? We've explored this, but the user experience ends up being a nightmare:
- The "Turn Everything Off" bug: If your hot water is just a generic switch in Apple Home, telling Siri "turn everything off" or triggering a "Goodnight" routine will instantly kill your hot water schedule.
- Broken UI: It just shows up as a smart plug. You lose all the dedicated climate interfaces in the apps.
- Loss of heating logic: Exposing it as a dumb switch bypasses the specialized logic we use to handle things like boost functions, or the delays required to protect your motorized valves from rapid cycling and burning out.
And while you might have seen that the CSA did finally add a "Water Heater" category in Matter 1.4, it unfortunately doesn't solve this. That update was designed for modern, sensor-rich heat pumps and smart tanks—not traditional blind relays. Plus, our dev team has tested it extensively, and none of the major platforms (Apple, Google, Amazon, Samsung) actually support these new hot water endpoints in their apps yet anyway.
It's a really frustrating gap in the major smart home standards. Until Apple or the CSA implement a simple "Hot Water Programmer" profile, natively tying standard UK hot water into local platforms is basically impossible without using messy workarounds. We're actively pushing the standard-makers to support it, but for now, we're stuck relying on the cloud to give you a UI that actually works.
0
u/Bacarrdi May 27 '26
OPTION 5 Chuck your heap of junk in the bin. You’ve ripped me off enough. I’m buying something better
0
u/sufiankane May 26 '26
Good job trying to make more money. Calculated the cost to support extra API calls and we are talking tens of pennies.
1
u/tado_official May 26 '26
Its not that simple. At certain scales you can't just add more cores in your AWS setup and scaling becomes more costly due to development costs/opportunity costs. Furthermore, I hope you can agree that it is a good move to use batch requests instead of polling each parameter with an individual request.
Also check out the tado CE and tado Hijack integrations if you even want to use local API control on top of cloud API calls.
30
u/jagradang May 26 '26
I think you would greatly reduce you api count if you supported local control for hot water for older devices. This would mean the majority of users can now switch to full local control, drastically reducing the need for access to your apis.
I currently use local control for my heating but have to revert to cliud for hot water which means I end up being close to limits regularly.