Tado API limits

[Punsher (Felix)]

I received an email from tado today stating that they want to limit the amount of API calls due to high traffic on their end.

They plan to ramp the allowed number of requests down to 200/day for users without auto assist and 20.000/day for those with auto assist.

For local operations they point to using the homekit API of the local bridge. However as far as I know there is no Openhab binding that allows to connect to devices with this API. The available homekit Integration only works in the opposite direction.

So as far as I can see it we would need to redesign the tado binding in order to remain usable.

[ErikDB (Erik)]

@Punsher

They plan to ramp the allowed number of requests down to 200/day for users without auto assis

You mean 100…

I already posted it here before, but it deserves its own topic indeed. (Unless there is a dedicated topic for the binding, but I haven’t found it.)

I don’t know HomeKit, but it seems some Apple equipment is required?

I think @AndrewFG is the binding developer?

[Punsher (Felix)]

I don’t think you would need to have apple hardware. The other big system already has this kind of implementation.

Only problem is probably that it will only give you a set of standard properties similar to matter.

[AndrewFG (Andrew Fiddian-Green)]

Is this HomeKit api documented somewhere? If so I will write an integration for it.

[Punsher (Felix)]

Hi Andrew,

that should be the Honekit Acessory Protocol. If you search for it you can find the specification as pdf. Though the link I found was from a rivalling Plattform. So I don’t really know if I should post it here.

Regards Felix

[marcel_erkel]

If mean Home Assistant why not just call it Home Assistant? We’re not hostile to other home automation solutions in this community.

[sihui]

@marcel_erkel

why not just call it Home Assistant?

There are many more, which are even better than HA

[Punsher (Felix)]

Well in that case. Home Assistanr has that API already implemented as it seems. Apart from that I found the specification here: https://forum.iobroker.net/assets/uploads/files/1634848447889-apple-spezifikation-homekit.pdf

[AndrewFG (Andrew Fiddian-Green)]

@Punsher

I found the specification here

Thanks for the link. But crikey that’s heavy. Most of the 259 pages are describing the device servers in very bureaucratic terms, so it would be nice if someone has a practical implementation guide for clients over HTTP. I will have a look at the HA code to see if there is something to be learned there. But be warned coding for such a monster in OH will be massive and take quite some time.

[Punsher (Felix)]

Yep I looked into it myself already. What I did find was a reference implementation of the password exchange protocol they mentioned. Other than that there should already be the openhab implementation of the other side. Maybe there is a lot of classes to re-use etc.

The only other implementation of such a thing i could find was this project. GitHub - forty2/mqtt2homekit: Use MQTT to control HomeKit-enabled devices

But I don’t know if it’s really maintained.

[AndrewFG (Andrew Fiddian-Green)]

@Punsher

should already be the openhab implementation of the other side. Maybe there is a lot of classes to re-use etc.

[tado] Upcoming changes to the tado° API

[engine (Engineer)]

Thanks for bringing attention to this topic!

According to this answer on GitHub the auto-assist customers will get 20000 calls/day even if auto-assist was bundled to the old V3 bridge without subscription fees.

The V3 (DIB01-TA-04) bridge doesn’t support Apple Homekit. Only the V3+ (DIB01-TA-06) does.

As I still have the V3 bridge running, I’d really welcome it if you do not change anything towards Homekit in general for all bridge types

For V3 users with included auto-assist the current setup should continue to work even with 20000 calls/day limit if the binding only fetches updates every 30 seconds for each zone with a maximum of 6 zones. It wouldn’t be necessary to upgrade to a V3+ bridge.

The homes/<id>/deviceList endpoint lists my V3 bridge as {..., device: {deviceType: “IB01”, ...}, ...}

And the homes/<id> endpoint lists {..., "generation": "PRE_LINE_X", ..., “skills”: [“AUTO_ASSIST”, “PRE_2025_FREE_FEATURES”], ...}

I hope this helps to identify V3 tado systems which are capable of the 20000 calls/day and don’t support Homekit.

Edit: According to the packages, both V3 and V3+ support Homekit.

[ErikDB (Erik)]

@engine

if auto-assist was bundled to the old V3 bridge without subscription fees.

I’ve read that a few times. But what does that mean?

[engine (Engineer)]

@ErikDB

I’ve read that a few times. But what does that mean?

I bought the starter pack with the V3 bridge back then in 2017 I guess when Auto-Assistant was just an included feature. I’m not even sure if it was already called Auto-Assistant.

Only later they introduced it as additional subscription when they brought the V3+ to the market. I guess V3+ is identical to V3, just Apple didn’t allow certifying devices as Homekit compatible which were already sold. That’s why tado took the chance to also switch Auto-Assist to a subscription model. (This is pure speculation… )

A year later sometimes in 2018 I guess I bought another starter kit, because it was cheaper than buying two separate thermostats. I have a never used the V3+ bridge, because I don’t want to lose my “early adopter status” with the free Auto-Assist from V3.

I even remember that tado introduced a new app back then which you had to upgrade to by paying 20€ I guess… as I didn’t use these features, I never had interest in spending so much on an app upgrade. After a while they made it cheaper and cheaper until it was available for free… I guess they finally just wanted to get rid of the old app users somehow.

In all these years there were some questionable decisions from tado’s side, but I always thought it’s at least good to support a local company (I’m from Munich, they are from Munich…).

Let’s see how long this journey can continue

@ErikDB

This is the response on a HTTP call, I presume? Which one?

It’s the calls that the web app does, you can inspect it in the browser

Edit: According to the packages, both V3 and V3+ support Homekit.

[ErikDB (Erik)]

@engine

It’s the calls that the web app does, you can inspect it in the browser

I later realized you included the calls more or less. I should have payed more attention.

Here is an unofficial documentation of cloud API, by the way: tadoº API v2 - community managed

Unfortunately, I assume I’ve got V3+ devices. And if I can believe a lot of comments on GitHub, the Home Kit solution lacks several API ‘features’ the cloud API does? Quite troublesome… (Aside from the fact that it’s apparently quite task to get that Home Kit solution integrated…)

[Punsher (Felix)]

Most likely the Homekit solution has only those field that are part of the apple specification. So something like operation mode, set point, temperature and (hopefully) humidity. But I guess that makes up for the majority of the calls.

The rest might still be fetched from the cloud API.

[ErikDB (Erik)]

@engine

And the homes/<id> endpoint lists {..., "generation": "PRE_LINE_X", ..., “skills”: [“AUTO_ASSIST”, “PRE_2025_FREE_FEATURES”], ...}

I just checked, that’s the exact same info I get. But in my tado Android app, “Auto-Assist” is not included:

[engine (Engineer)]

@ErikDB

Here is an unofficial documentation of cloud API, by the way: tadoº API v2 - community managed

Thanks for the link!

I checked the “me” endpoint, but it doesn’t show if auto-assistant is active, either.

I thought there was a property at some time which showed it, but I cannot remember it…

At least it seems to be possible to tell from the zones/<id>/state endpoint:

• if the property openWindow exists, Auto-Assistant is active
• if it doesn’t exist, but openWindowDetectedexists, Auto-Assistant is inactive

See discussion here in this issue: [tado] openWindowDetected not available in API response · Issue #17558 · openhab/openhab-addons · GitHub

@engine

The homes/<id>/deviceList endpoint lists my V3 bridge as {..., device: {deviceType: “IB01”, ...}, ...}

@ErikDB do you also get IB01 as device? The endpoint returns an entries property with a list of objects for each device including the bridge. If you get e.g. IB02, we could at least distinguish the V3 and V3+ bridges.

[ErikDB (Erik)]

@engine

• if the property openWindow exists, Auto-Assistant is active
• if it doesn’t exist, but openWindowDetectedexists, Auto-Assistant is inactive

I’ve got neither in the response to zones/<id>/state.

@engine

@ErikDB do you also get IB01 as device? The endpoint returns an entries property with a list of objects for each device including the bridge. If you get e.g. IB02, we could at least distinguish the V3 and V3+ bridges.

Yes: "deviceType": "IB01".

[engine (Engineer)]

This comment gave the right hint.

The web app loads https://susi.tado.com/api/homes/skills and it responds with this JSON for my V3 bridge:

{"AUTO_ASSIST":[{"source":"TADO_MANAGED","status":"ACTIVE","type":"PRE_V3_PLUS_DEVICE","startDate":"<date>"}],"PRE_2025_FREE_FEATURES":[{"source":"TADO_MANAGED","status":"ACTIVE","type":"TADO_MANAGED","startDate":"<date>"}]}

With this it should be at least possible to determine if a bridge supports Homekit or not.

Edit: According to the packages, both V3 and V3+ support Homekit.