Is there a use case for Tado Local from the perspective of the Home Assistant HomeKit integration?

[java-devil]

Forgive me for asking such a seemingly "obvious" question, but I wasn't able to find a definitive answer anywhere (which is probably indicative that the README.md could be improved upon a bit in this area).

As you probably know - the official HA Tado integration uses HomeKit out of the box. As you might not know - this integration is highly unreliable. It polls data surprisingly rarely compared to the web API. I suspect (but am not sure) this is the fault of the protocol implementation (by Tado), and not of the integration itself (by the Open Home Fundation).

Therefore... is there any benefit of using your solution in with Home Assistant? Does TadoLocal offer more resilient / higher resolution data? Is there even a need to develop a Home Assistant addon based on TadoLocal given what I asked above?

Cheers,
Adam

[rhuijben]

I'm not an HomeAssistant user, and use multiple scripts. All of these need access to some of the info, but mostly share the same cloud limits Tado gives us.

What I did was consolidate the info in a service that you can just query without having to look at the Tado limits. So you can build and use multiple tools against this.

I don't know if the HomeKit developers are going to provide all this info from HomeKit... I just built the part of the puzzle that I needed for my Domoticz + custom scripting with the hope that the same piece would fit a lot of other requirements.

So one generic piece that might fit in more environments.

And for me it allowed to look at things in more details than by trying to provide a few patches to other projects with the hope that this would allow me to tinker just the limits a tiny bit. (And with the limits announced to go tighter every month... as we see today, we will see where this goes)

[Bekkie]

@java-devil as far as i known the official Home Assistant Tado integration uses the Tado Cloud API and not the Home Kit interface. There is also a HA HomeKit Device integration, which provides a generic HomeKit interface.

[TomSuperHero124]

@Bekkie, you're right — that is also the reason for the discussion in the Home Assistant repo about removing the Tado integration. But I just found a HACS Repo for Tado Loal

[Nicko33127]

@Bekkie, you're right — that is also the reason for the discussion in the Home Assistant repo about removing the Tado integration. But I just found a HACS Repo for Tado Loal

Yes the addon you libked worked very well and this combined with this addon will make a very complete solution https://github.com/nielsfaber/scheduler-card

With the both hacs addon I can control home away using my zone.home as a condition in the scheduler, and I also use windows as a second condition and with the " Re-evaluate when conditions change" option ticked in. As soon as one of the condition changes my thermostats act accordingly. Without this and only using -1 when away.. when back home, the temp would go back to previously know temperature not currently desired temp in schedule.

Boost can be done via an automation

[DariukaB]

Why not using:

https://github.com/banter240/tado_hijack

and

banter240/tado_hijack#28

?

[Nicko33127]

Why not using:

https://github.com/banter240/tado_hijack

and

banter240/tado_hijack#28

?

Local tado is fully local. No need for api calls at all so removed all needs for tado.. if they ever decide to stop their services completely, local tado would still work. Not sure hijack project would still work as looks like it's still relies on tado server's

[DariukaB]

Hijack is hybrid - it uses the api cloud pooling only for smart cloud features. the rest is fully local through homekit integration. local tado if not managing to bring somehow the smart features to work local (eg. auto mode) is basically the same thing with homekit integration in HA... also tado local is not 100% local since u still have to authenticate to tado servers and all the other entities apart from basic climate one pulled from cloud - so u still have the need for api calls time to time. so basically a different approach but still a hybrid solution. the only way to get everything fully local is to hack the tado bridge, reverse engineer, replicate the cloud to a local server solution and redirect api calls to this... which i believe is not possible (not yet, at least)...

[chinezbrun]

Local tado is fully local. No need for api calls at all so removed all needs for tado.. if they ever decide to stop their services completely, local tado would still work. Not sure hijack project would still work as looks like it's still relies on tado server's

From my understanding, TadoLocal still seems to have some dependency on Tado Cloud.

During installation there is an authentication step against Tado Cloud, and during runtime I can see periodic “Sync with Tado Cloud” messages in the logs.

I’m trying to better understand:

• what data is being synced from Tado Cloud and at what interval

• whether these syncs are optional or configurable

• and if they involve actual Tado Cloud API calls (and potentially count toward rate limits)

This would help clarify the level of cloud dependency for users aiming for a mostly or fully local setup.

[DariukaB]

Tado local is not 100% local. It is another approach similar to hijack tado. It works through HomeKit api for main functions but for extra smart cloud options it still uses tado API and calls their servers periodically. The main benefit tho is, since you will pair with a local instance through homekit, even when HA is restarting, rebooting, main tado functions will still work (you can use webgui). But if u have an Apple hub like HomePod or Apple TV… you can just use the basic HomeKit and will be the same. For V3+ tho, as of now, schedules are also stored in the bridge and even without internet it will be basically locked to auto until internet resumes. If the developers will find a way to replicate every aspect of Tado through local API we can talk about a fully 100% local solution. Atm as I said before it is just another hybrid “solution” to tado api limit. But kudos to developers that they are spending time and effort to try to figure out a fully local solution.

[chinezbrun]

Clear. Hope that those API calls will not exceed the daily quota (i.e 100).
Are these extra 'smart cloud options', optional for TadoLocal users?

[DariukaB]

this is the whole idea: trying to bring everything working locally (including open window, schedules etc). when using it this way (tado local) you will probably not exceed the 100 calls/day since for basic calls it uses homekit (100% local) but schedules and other staff will still use API calls to tado cloud

[Bekkie]

Tado Local only syncs with the Cloud API every 4 hours to retrieve battery status, device metadata, and zone configuration. Home metadata is retrieved once every 24 hours. This results in approximately 7 API calls per day.

To control the HVAC system, Tado Local communicates directly with the Tado Internet Bridge using the HomeKit protocol. Therefore, changing the target temperature or switching the Smart Schedule on or off does not require any API calls. Even if the Cloud API is down, these functions continue to operate. Open-window detection is also handled locally.

Battery and device metadata are not available or accessible via the Internet Bridge.

Configuring the Smart Schedule itself requires the Tado app or access through the Tado website, as has always been the case, including when using the Tado Home Assistant native integration. However, with Tado Local, it is possible to create a Smart Schedule using Home Assistant or Domoticz, although it will then be completely separated from the Tado app.