Still working fine here, have you had a look at caching tokens so you don't re login every 5 mins
Evohome app broken
Collapse
X
-
Originally posted by Stevedh View PostStill working fine here, have you had a look at caching tokens so you don't re login every 5 mins
The v2 API (the one that confusingly has v1 in the URI) is not giving me any issues whatsoever. And I request status every 2 minutes.
Comment
-
-
Originally posted by Stevedh View PostStill working fine here, have you had a look at caching tokens so you don't re login every 5 mins
Comment
-
-
Originally posted by gordonb3 View PostNot seeing any real issues myself. The only thing I get is an occasional "Request count limitation exceeded, please try again later" message returned when I try to logon to the v1 (US) API for better temperature resolution. So yes that does require me to do a logon twice within a few seconds, but as said I only get this error occasionally - maybe once or twice a day.
The v2 API (the one that confusingly has v1 in the URI) is not giving me any issues whatsoever. And I request status every 2 minutes.
This avoids the issue where the first zone query in a 5 minute period gets a failure, fails to cache any results and the second zone then tries to query immediately afterwards and so on...
Otherwise failures results in potentially up to 8 queries in a short time (compounding on the rate limit) as each zone finds the cache empty and tries a query of its own. The alternative might be to update the cache file time but leave it empty so that following zones know not to try during that 5 minute period but that of course still results in no data for that 5 minute period and a gap in the graph.
These two queries have improved matters but I'm still seeing a lot of failures on the V2 API where it reports HTTP 429.
What do you guys do if your first attempt during a polling period fails - just wait until the next polling period with no more attempts ?
It would be really nice to have some sort of official word from Honeywell what the rate limiting policy is now as it has clearly changed, and in a big way, from what it used to be. Either that or they're under a DDoS or the servers are just really flaky.
Comment
-
-
Originally posted by DBMandrake View PostIt would be really nice to have some sort of official word from Honeywell what the rate limiting policy is now as it has clearly changed, and in a big way, from what it used to be. Either that or they're under a DDoS or the servers are just really flaky.
Comment
-
-
Originally posted by dty View PostHave you looked at the headers and/or body of the response? It might be that it describes the limits in there somewhere.
Comment
-
-
As a rule,you're bound to do multiple calls when you logon to the portal (using the v2 API):
1. logon
2. retrieve the user ID
3. fetch installation info
4. get status report
5. (optional) get schedule info for one or more zones (each a separate call)
Since there can be up to 12 zones for a single location and you can have multiple locations I do not think this limit they apparently introduced is related to just the number of calls originating from a single IP.
I am in fact not doing anything special. Domoticz internals also do not allow me to access the HTTP return and programmatically respond to it and so far I've not seen reason to enable debug output on it, nor did I hear from any other user seeing the HTTP 429.
Comment
-
-
Originally posted by paulockenden View PostI wonder whether Honeywell uses the Laravel PHP framework? There was an (undocumented!) change to the way it handles rate limiting a few months ago. Things that had been counted separately started to be measured together. One of our data suppliers got bitten by this.
P.
Comment
-
-
Originally posted by gordonb3 View PostDon't think that is related.
From my supplier:
"Turns out the latest version of the Laravel PHP framework that we use has made an (undocumented!) change to the way it handles rate limiting. Previously it would handle '/url1/feed/xml' and '/url2/feed/json' as separate urls, and thus apply the rate limiting individually.
However,we found that the framework's throttling handler was applying the rate limiting to ALL instances as a whole! So user 1 was hitting their feed 6 times a minute, which would put user 2 over their limit! Not only is this a stupid change, but potentially very dangerous to put into place without notifying developers - and was also seriously mind-boggling to track down."
I'm not saying that is the cause here - just that it looks suspiciously familiar.
P.Last edited by paulockenden; 18 November 2018, 09:29 PM.
Comment
-
-
Okay, but I'm not seeing the HTTP-429 or the error that the underlying framework in my case would produce in that case. I receive a Json message containing an error report, which implies HTTP-200 success and thus the cause appears to be at another level.
Comment
-
-
Originally posted by gordonb3 View PostOkay, but I'm not seeing the HTTP-429 or the error that the underlying framework in my case would produce in that case. I receive a Json message containing an error report, which implies HTTP-200 success and thus the cause appears to be at another level.
I'm definitely seeing HTTP 429 on the initial authentication pass when I get a failure. It's always the same mode of failure.
BTW, I discovered the version of evohome-client I was running, 0.2.5 was a couple of years out of date and there have been quite a few changes since then and 0.2.8 including changes to the API keys and how the login token is timed out:
Python client to access the Evohome web service. Contribute to watchforstock/evohome-client development by creating an account on GitHub.
However I've updated 0.2.8 and it didn't seem to make any real difference.Last edited by DBMandrake; 19 November 2018, 12:47 AM.
Comment
-
-
Originally posted by paulockenden View PostImplies how? 4xx errors can still have content. Just think about 404 error pages, for example.
Edit:
Do note that I'm only seeing this error on the v1 API. It is possible that the response from this API is different from that of the v2 API where @DBMandrake reports seeing this error. Although it is impossible for me to see the error code (other than by enabling debug) for the last several days I have not seen anything in the log that could be the result of HTTP-429 being returned by the portal.Last edited by gordonb3; 19 November 2018, 10:06 AM.
Comment
-
-
From the command line you need to use -f (or --fail) with curl if you want to to error on getting a 4xx status. Or if you are using a curl library in your code then set CURLOPT_FAILONERROR to 1. With these options it'll give you Error 22 CURLE_HTTP_RETURNED_ERROR when you get a 4xx error.
P.
Comment
-
Comment