Page 5 of 36 FirstFirst 1234567891015 ... LastLast
Results 41 to 50 of 357

Thread: Evohome app broken

  1. #41
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    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.

  2. #42
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,843

    Default

    Quote Originally Posted by gordonb3 View Post
    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.
    Check the debug output I posted back in post 12:

    https://www.automatedhome.co.uk/vbul...ll=1#post38658

    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:

    https://github.com/watchforstock/evo...b52e1...master

    However I've updated 0.2.8 and it didn't seem to make any real difference.
    Last edited by DBMandrake; 19th November 2018 at 12:47 AM.

  3. #43
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,602

    Default

    Quote Originally Posted by gordonb3 View Post
    I receive a Json message containing an error report, which implies HTTP-200 success
    Implies how? 4xx errors can still have content. Just think about 404 error pages, for example.

  4. #44
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    Quote Originally Posted by paulockenden View Post
    Implies how? 4xx errors can still have content. Just think about 404 error pages, for example.
    Because the underlying client I need to work with in this case returns a boolean value matching a return of `CURLE_OK` and if that does not evaluate to true also does not fill the target buffer with whatever content got sent along with that error. From that I know that if the error produced in the log is associated with (Json) content it has to be a HTTP-200


    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; 19th November 2018 at 10:06 AM.

  5. #45
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,602

    Default

    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.

  6. #46
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,843

    Default

    Quote Originally Posted by gordonb3 View Post
    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.
    I'm getting intermittent errors from both V1 and V2 API's. I use the V1 API for (more accurate) temperature readings and only use the V2 API for hot water on/off status.

    However watchforstock's python library only has a debug mode which will show the HTTP response for the V2 API, the V1 API call failing just results in an unhelpful uncaught python exception, so I don't know what the actual returned error is for the V1 API when it fails. However both API's seem to fail or succeed at the same time suggesting that there is shared rate limiting between them. If I manually spam queries to one API I then immediately get failures on the other API even though they use different URL's.
    Last edited by DBMandrake; 19th November 2018 at 10:30 AM.

  7. #47
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    Yeah, Python is quite ugly that way.

    I am actually still on the 0.2.5 level of that library. What I did though was rewrite that to C++ and add some logic that verifies whether I receive HTML or Json. The first application I created from this effectively did the exact same thing as the Python script on the Domoticz wiki page (to which I believe you added the v1 lines?), only in about 1 second rather than 40+ seconds. At a later time I integrated this code into Domoticz to defeat the refresh lapse on commands issued through the Domoticz API. As it happens this integration also defeats the library's capability of investigating and reporting on unexpected returns because the HTTP client offered by the Domoticz framework discards this content if the return code is not HTTP-200 (CURLE_OK).

    Reinvestigating that HTTP client library it appears that I can move one step up though, where I do seem to be able to see the return code. That could actually prove to be very helpful in tracing the source of weird errors that affect users on an individual base - many of which are apparently related to language settings in the portal.

  8. #48
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,843

    Default

    Quote Originally Posted by gordonb3 View Post
    Yeah, Python is quite ugly that way.

    I am actually still on the 0.2.5 level of that library.
    I was too, I updated to 0.2.8 a few days ago but it didn't help with this issue. (Not that I really expected it to)
    What I did though was rewrite that to C++ and add some logic that verifies whether I receive HTML or Json. The first application I created from this effectively did the exact same thing as the Python script on the Domoticz wiki page (to which I believe you added the v1 lines?),
    Yes I added the code to the Domoticz script to get the temperatures from the V1 API. Since that causes queries to both API's I suspect that may be causing issues for people using this script now that rate limiting is more aggressive.

    Prior to these recent server changes I was actually running both evohome-munin and domoticz using the python script in parallel without any issues - meaning two calls to each API every 5 minutes from the same IP address... although I did have domoticz and evohome-munin offset by 3 minutes so they weren't both trying to connect at the same time. As soon as these problems started I disabled domoticz as I don't really use it any more and halving the number of API calls in a 5 minute period helped slightly but not a lot.

    Adding a 30 second delay between calling V1 and V2 API's does seem to have helped a bit as well but isn't a cure. I still get a lot of HTTP 429's on the V2 API call to check the hot water status so my hot water graph is mostly gaps at the moment. Without knowing specifically what the rate limits are I'm just poking and prodding with no real direction, and I can't really do much more unless I want to give up on 5 minute polling.

  9. #49
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    Quote Originally Posted by DBMandrake View Post
    Yes I added the code to the Domoticz script to get the temperatures from the V1 API. Since that causes queries to both API's I suspect that may be causing issues for people using this script now that rate limiting is more aggressive.
    I assume that might be true. No mentioning on the Domoticz forum about it though.

    But let's take a few steps back. In post #31 @Stevedh suggested caching the auth token and that seems to be worth investigating. In my client I only do a login just shy of once per hour (on both APIs), so the maximum number of simultaneous logins that I have on the v2 API is 2 - with an interval of 5 minutes you have 11 or even 12 from that one application calling the script as a single run instance. I'm actually not sure about how the v1 API handles registered logins, but if that also has a 1 hour lifespan you are looking at up to 24 simultaneous logins. Since the errors you report are in fact related to login only I don't think rate limiting is the real issue at hand.

  10. #50
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    Did some digging...

    Turns out that the v1 API has a session ID with a life span of 15 minutes that gets renewed with every call you make to that API. As such, once logged on you can keep using the same session ID indefinitely as long as you keep the query interval within that 15 minute limit

    The v2 API uses OAuth mechanism for assigning session IDs (`access_token`) and this has a fixed life span of 1 hour. At present I simply discard the session ID in my application and perform a new logon. The logon response however also contains a `refresh_token` and it turns out you can use that any time to create a new access token, even after the old one already expired. I assume the refresh token must have a finite life span as well, but so far they seem to keep working indefinitely. Remarkably calling for a refresh does not invalidate the old session ID, so one should still take care when to call this method and not hit the session limit.

Posting Permissions

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