It might not have to do with the request itself, but with the timing of the request. But, it could also clearly be related to the user-agent. For testing, I would try faking an actual browser user-agent, and also making a random user-agent string for each request, and see what the results are.
Here is the user-agent I currently use in my browser:
Mozilla/5.0 (Windows NT 10.0; WOW64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.5666.197 Safari/537.36
Here is the user-agent I should have been using (but I run a user-agent switcher in the browser):
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0
It looks like it is working again. At least in my case. So hopefully it was a temporary glitch. I will wait and see if there is a recurrence before I doing anything to change the code.
HOWEVER .. I am also working on a HomeKit binding to intergrate these things via the LAN rather than the WAN.
In that code, I used the token I had copied from the browser (after logging into tado.com, of course). It returned 200 (and 403 for the call for which I opened up the Stack Overflow topic).
So at the same moment, the token I got from tado.com worked, while another token returned 429. That’s why I assume that if our binding manages to log in “as if” it were the web app (and/or uses the refresh token that the web app provides), it should work.
Is it possible to manually set the refresh token somewhere for debugging purposes?
Python syntax makes me dizzy (haven’t used Python since 2005, I can’t stand whitespace based syntax), so I’m not sure that I even want to try to figure out what’s happening there.
I don’t think you should assume that there’s a problem with the token itself. But, they could use any combination they want of token, user-agent, IP address and request rate (and any other information they receive with the request) to make “rules” for what to respond. Ultimately, you must try to figure out what their rules are before you can “adapt” to them.
This still might have been an unintended hiccup on their part, that might not occur again.
Of course, it’s possible. They can evaluate all kind of information when they first issue the token, including JavaScript based stuff that will only work with an actual browser. But, if that is what happens, how can you use that to help OH work? You can’t base a binding of users manually copy/pasting their token from the browser, a token with probably a quite limited lifetime anyway.
I would focus more on figuring out exactly what criteria they have implemented, if this situation returns again.
I only meant it as a starting point for a treasure hunt. But I now understand that there are JavaScript hoops that a browser can, but a binding can’t jump through…
Maybe just stating the obvious but if you have 8 Tado devices refreshing every 30 seconds then 24 x 120 x 8 >> 23000 …
So there would clearly even be an issue if one did pay for the subscription. Currently each zone thing makes its own requests, but I am wondering if multiple zones refreshes can be amalgamated in one call.
EDIT: I checked the API specification and there is unfortunately NOT a call for downloading the Zone state details of multiple devices in one go. (There is an API call for listing all Zones in a Home, but that does not include the detailed state of each).
I have 10 tado devices.
Even with only one call for all devices, only 4 calls per hour are possible without a subscription. (100/day)
That is not realistic. There must be another way.
I’m thinking about taking out a subscription for a year.
According to my logs, the bridge went offline on 15.09. at 23:27 CEST, on 16.09. at 23:20 CEST, and on 17.09. at 23:37 CEST. It was back online on 16.09. at 13:56 CEST and on 17.09. at 13:57 CEST.
I am using 19 devices distributed across 9 zones. Additionally, geofencing-information of two cellphones is used in several rules.
My auto-assist-subscription is covered by the tado starter kit.
If you have N devices then each of them must have a refreshInterval of around N x 5 seconds. So with your 21 devices the interval needs to be around 105 seconds as a minimum.
I don’t know if Tado thought this through: If you own one old device, you’re probably fine. But, if you’ve bought many recent devices, you’re basically fucked even with a subscription. Seems like a case of “punishing” the wrong behavior…
Hello again,
I contacted tado support and asked about the API limits. I currently have 10 devices, 3 phones, and 1 bridge in openHAB. All with a refresh rate of 60 seconds. That would be 14 x 60 x 24 = 20.160 requests. But I still don’t get a response between approximately 4:45 AM and 1:57 PM.
I received the following answer.
“Thank you for your patience. I’d like to explain how things are currently working.
Currently, all tado° users (regardless of account type) have a daily quota of 20,000 requests within a 24-hour window. You can confirm this directly in the API response headers:
• “ratelimit-policy: “perday”;q=20000;w=86400” → this shows that the quota is 20,000 requests per 24 hours (86,400 seconds).
• “ratelimit: “perday”;r=0;t=123” → this indicates how many requests you have left (r=…) and how many seconds remain until your limit is reset (t=…).
If you’ve been experiencing issues recently, there’s a very good chance that your account has already reached its 20.000 daily limit.”
Yesterday, I increased the refresh rate to 120 seconds. Now I get a response from the server even after 4:45 AM.
OpenHAB seems to be sending more than one request per device and interval.
It would also be useful to display the remaining API calls and the reset time in the binding.
It sends at least one request per device (including any phones) every refreshInterval. In addition there are extra requests to check the battery state. Plus also requests any time you send a command. Plus a full download for each device when the thing is enabled. Plus also a request every time the token needs to be refreshed.
PS I have 9 devices each with refreshInterval of 90 seconds and that seems to fit within the 20k/day limit.
Just for info, the 20k/day limit counter resets at 00:00 UTC .. so you will need to figure out what that means for you in local time.
I am sure “it would be useful”.. but (just for info) I am currently spending all my time developing a HomeKit integration that (among others) would allow a local integration of Tado devices without needing any cloud server access. So I will not be doing any work on the Tado binding in the foreseeable future..
