Page 4 of 36 FirstFirst 12345678914 ... LastLast
Results 31 to 40 of 357

Thread: Evohome app broken

  1. #31
    Automated Home Sr Member
    Join Date
    Mar 2017
    Posts
    83

    Default

    Still working fine here, have you had a look at caching tokens so you don't re login every 5 mins

  2. #32
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    134

    Default

    Quote Originally Posted by Stevedh View Post
    Still working fine here, have you had a look at caching tokens so you don't re login every 5 mins
    Not 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.

  3. #33
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,825

    Default

    Quote Originally Posted by Stevedh View Post
    Still working fine here, have you had a look at caching tokens so you don't re login every 5 mins
    Unfortunately saving the tokens doesn't seem to be possible in my situation as the script that calls the evohome-client libraries is not persistent across each session. (And I'm not even sure whether watchforstock's evohome-client python library can do token caching in the first place)

  4. #34
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,825

    Default

    Quote Originally Posted by gordonb3 View Post
    Not 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.
    I've added a 30 second pause between querying the V1 and V2 API's, also I've added a 30 second pause before sending the V1 query if the cache has expired.

    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.

  5. #35
    Automated Home Ninja
    Join Date
    Aug 2016
    Posts
    489

    Default

    Quote Originally Posted by DBMandrake View Post
    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.
    Have you looked at the headers and/or body of the response? It might be that it describes the limits in there somewhere.

  6. #36
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,825

    Default

    Quote Originally Posted by dty View Post
    Have you looked at the headers and/or body of the response? It might be that it describes the limits in there somewhere.
    No, as I specifically mentioned in an earlier post there is no additional information in the 429 response to say what the rate limits are or how long until it's OK to retry. So we can only guess what the rate limits might be.

  7. #37
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    134

    Default

    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.

  8. #38
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,594

    Default

    I 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.

  9. #39
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    134

    Default

    Quote Originally Posted by paulockenden View Post
    I 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.
    Don't think that is related. @DBMandrake mentions an HTTP return code, which in my application would translate as an unknown HTTP error, while I receive a Json formatted response informing me about the request count limit.

  10. #40
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,594

    Default

    Quote Originally Posted by gordonb3 View Post
    Don't think that is related.
    The Laravel update I'm talking about resulted in data services returning 429 errors. Exactly the same as this. We saw it with things like share price feeds.

    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; 18th November 2018 at 09:29 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •