Page 3 of 47 FirstFirst 1234567813 ... LastLast
Results 21 to 30 of 464

Thread: Evohome app broken

  1. #21
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default

    Still seeing a significantly high API query failure rate of maybe 30% - enough to leave intermittent chunks out of my graphs.

    Can someone from Honeywell please comment on whether there are new stricter rate limits in place (in which case please let us know what they are) or whether there are still server issues ?

    The last couple of weeks is the most unreliable the API has been for a couple of years now and quite frankly it's getting extremely frustrating.

  2. #22
    Automated Home Jr Member
    Join Date
    Oct 2016
    Location
    Cambridge
    Posts
    24

    Default

    Perhaps we should always complain on social media first, to embarrass Honeywell into some action?
    Complain on Twitter for an instant response

    https://www.theguardian.com/money/20...air-on-twitter

    Capture.JPG
    Last edited by Karrimor; 10th November 2018 at 08:00 PM.

  3. #23
    Automated Home Guru
    Join Date
    Mar 2017
    Posts
    177

    Default

    Been fine for me since I made my change, but something must have changed to force me to make my change..

  4. #24
    Automated Home Ninja
    Join Date
    Dec 2016
    Posts
    273

    Default

    Quote Originally Posted by gordonb3 View Post
    Quote Originally Posted by Stevedh View Post
    Just checked and as far as I can tell I've been using the same session id for over a day now and haven't had a single count limit error in that time.
    is there any chance its an hour since last use?
    Never used to be like that. The sessionid always became invalid one hour after it was created, regardless of whatever interval you used for querying the portal. It is however possible that they changed that behaviour and a query now acts as a sessionid timeout counter reset.
    Did some verifying and it actually says in the OAuth return that the authentication token has a life span of 3599 seconds. There is a secondary token named refresh_token returned, but I don't know what that does or how it is supposed to be used.

    In any case I have no problem resending credentials once an hour and I actually use that moment to renew all local cached data (installation info, schedules).

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

    Default

    There will be a different API endpoint where you can exchange the refresh token for a new authentication token.

  6. #26
    Automated Home Ninja
    Join Date
    Dec 2016
    Posts
    273

    Default

    Quote Originally Posted by dty View Post
    There will be a different API endpoint where you can exchange the refresh token for a new authentication token.
    Yeah, I had a similar kind of thought but I'm not really seeing the point of it. If I need to do some special call it really makes no difference whether I send that secondary token or resend my credentials. And I'll still refresh all the information at that point because I want to catch changes that are not volunteered by the portal.

  7. #27
    Automated Home Ninja
    Join Date
    Aug 2016
    Posts
    489

    Default

    Quote Originally Posted by gordonb3 View Post
    Yeah, I had a similar kind of thought but I'm not really seeing the point of it. If I need to do some special call it really makes no difference whether I send that secondary token or resend my credentials. And I'll still refresh all the information at that point because I want to catch changes that are not volunteered by the portal.
    Imagine you were building IFTTT, or a similar service. This would allow you to request the user's credentials, get a token, and then dispose of the credentials. As long as you refresh your token regularly, you don't need to either store the credentials or request the user to reenter them.

  8. #28
    Automated Home Ninja
    Join Date
    Dec 2016
    Posts
    273

    Default

    Quote Originally Posted by dty View Post
    Imagine you were building IFTTT, or a similar service. This would allow you to request the user's credentials, get a token, and then dispose of the credentials. As long as you refresh your token regularly, you don't need to either store the credentials or request the user to reenter them.
    Excellent point. Bit stuck in the domotica way of thinking, where you actually do store the credentials because you wouldn't want to enter several passwords if the program is restarted.

  9. #29
    Automated Home Lurker
    Join Date
    Aug 2017
    Posts
    8

    Default

    iOS App has been updated and seems to be working fine now.

  10. #30
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default

    Still seeing significant intermittent breaks in my graphs and after digging a bit further it does indeed seem to be caused by much more aggressive (than previously) rate limiting on Honeywell's servers, even though I am only making one call to each API every 5 minutes.

    It also looks like the rate limiting counter is shared between V1 and V2 API's - so because my Hot water script calls both API's one after the other (one to get temperature and one to get hot water on/off status) this apparently gets counted as two API calls in a short space of time and sometimes leads to rate limiting.

    As a workaround I'm going to add a 20 seconds delay between the calls to the V1 and V2 API's, but I'm just stabbing in the dark here without knowing what the rate limits are on the server and what time period rate limiting is counted over.

    I know the Honeywell guys have not been active on this forum for a while but can anyone from Honeywell advise what the new API rate limits are - number of requests and within what time period to trigger rate limiting ?

    I know the API has never been "officially" supported or documented for individual use (although we came close to that when Jack from Honeywell was active on here) but many of us do rely on it so it is discouraging that changes are made that effectively breaks it for us without any sort of communication.

    I would point out that the only reason I and a number of others of us need to use the API in the first place is because Honeywell has failed to provide any built in means of graphing temperatures and set points - something that most of your competitors like Tado now provide, even in their iOS apps. So lack of built in graphing support and an API that is unreliable and/or has undocumented rate limits that cause it to effectively be unreliable is just one more reason to consider a competitor that does support graphing next time I'm looking at a new heating system.

    I would add that it's customary for an "HTTP 429 Too many requests" response (which the server is returning) to provide an explanation of what rates were being exceeded and/or a retry-after header, but there is nothing like this in the server response, so we are left completely in the dark as to what limits are being exceeded.
    Last edited by DBMandrake; 17th November 2018 at 11:57 AM.

Posting Permissions

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