Evohome app broken

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Stevedh
    Automated Home Guru
    • Mar 2017
    • 177

    #16
    Ok those scripts seem very different to the one I based mine on, I'm only graphing the data so its a lot simpler.

    I'm using cacti and my script is triggered once every 5 minutes.

    1) it gets session using
    postdata = {'Username': USERNAME, 'Password': PASSWORD, 'ApplicationId': '91db1612-73fd-4500-91b2-e63b069b185c'}
    header = {'content-type': 'application/json'}
    url = 'https://tccna.honeywell.com/WebAPI/api/Session'
    data = json.dumps(postdata)
    response = requests.post(url, data=data, headers=header, timeout=15)
    str_response = response.content.decode("utf-8")

    2) then I dump all the data from my locations using

    url = 'https://tccna.honeywell.com/WebAPI/api/locations?userId=%s&allData=True' % userid
    #print(url)
    header['sessionId'] = sessionId
    response = requests.get(url, data=json.dumps(postdata), headers=header, timeout=15)

    I was previously doing steps 1 & 2 every poll, however now I store the userid and sessionid from step 1 and just do step 2 and so far its now been fine.

    Comment

    • DBMandrake
      Automated Home Legend
      • Sep 2014
      • 2361

      #17
      Originally posted by Stevedh View Post
      Ok those scripts seem very different to the one I based mine on, I'm only graphing the data so its a lot simpler.

      I'm using cacti and my script is triggered once every 5 minutes.

      1) it gets session using
      postdata = {'Username': USERNAME, 'Password': PASSWORD, 'ApplicationId': '91db1612-73fd-4500-91b2-e63b069b185c'}
      header = {'content-type': 'application/json'}
      url = 'https://tccna.honeywell.com/WebAPI/api/Session'
      data = json.dumps(postdata)
      response = requests.post(url, data=data, headers=header, timeout=15)
      str_response = response.content.decode("utf-8")

      2) then I dump all the data from my locations using

      url = 'https://tccna.honeywell.com/WebAPI/api/locations?userId=%s&allData=True' % userid
      #print(url)
      header['sessionId'] = sessionId
      response = requests.get(url, data=json.dumps(postdata), headers=header, timeout=15)

      I was previously doing steps 1 & 2 every poll, however now I store the userid and sessionid from step 1 and just do step 2 and so far its now been fine.
      I presume that there is a timeout on the sessionid though, and that it doesn't last forever ?

      Are you only preserving the sessionid across the poll for each zone but then obtaining a new sessionid at the next 5 minute period ?

      I'm using evohome-munin as the graphing plugin:

      Munin plugin for monitoring room/zone temperatures controlled by the Evohome of Honeywell - Infern1/evohome-munin


      This uses the watchforstock python libraries as the basis for connecting. I have it scheduled to poll every 5 minutes. To minimize server queries it implements a local disk cache with an expiry that is a bit longer than the polling period.

      Munin launches a separate instance of the evohome-munin plugin for each zone, however it does so sequentially, so the first zone runs, checks the cache, finds it is out of date and connects to the server to pull the data for all zones, saves that to the disk cache then returns the data for its own zone.

      The second and subsequent zones within the 5 minute poll interval run one after another but because the cache is fresh they all pull their data from the cache so no further API connections are opened. So there is only one API connection per 5 minute period. Sort of.

      To get maximum temperature resolution most of the data is retrieved using the old "V1" API, and this is what is cached, however hot water on/off status can only be read from the V2 API. So the hot water zone script both checks the V1 cache for the temperature reading, but also separately calls the V2 API (once) to find the hot water status.

      So there is one call to both API's every 5 minutes. I have been running Domoticz in parallel as well for the last couple of years which would have doubled that to 2 API calls to each API every 5 minutes (since it also queries both V1 and V2 API's) however due to this issue today and the fact that I never check the Domoticz dashboard anymore, I've decided to shut down Domoticz and only use Evohome-munin, which will halve the number of API calls coming from my client. If rate limiting is indeed happening, I'd rather one graphing solution works reliably than having two that are unreliable!
      Last edited by DBMandrake; 7 November 2018, 04:24 PM.

      Comment

      • gordonb3
        Automated Home Ninja
        • Dec 2016
        • 273

        #18
        Originally posted by DBMandrake View Post
        I presume that there is a timeout on the sessionid though, and that it doesn't last forever ?
        The sessionid stays valid for a maximum of one hour. This is implemented in Domoticz with the internal Web API connector, which keeps track of that limit and drops the sessionid on its own account when this limit is reached, rather than have the portal report that the sessionid is invalid.

        As it happens my log shows the "Request count limitation" error on the v1 API only. I have had 8 of those in the last three days. I do get other errors on the v2 API, including "Authorize error" and "Runtime error" which I think are being generated by the back-end software and not the portal itself. My guess would be that the portal may be under some kind of attack by script-kiddies trying to find user/password combinations.

        Comment

        • Stevedh
          Automated Home Guru
          • Mar 2017
          • 177

          #19
          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?

          Comment

          • gordonb3
            Automated Home Ninja
            • Dec 2016
            • 273

            #20
            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.

            Comment

            • DBMandrake
              Automated Home Legend
              • Sep 2014
              • 2361

              #21
              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.

              Comment

              • Karrimor
                Automated Home Jr Member
                • Oct 2016
                • 24

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

                Twitter is becoming so widely used for complaints that companies, from LA Fitness to BT, have Twitter accounts specifically to deal with customer feedback


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

                Comment

                • Stevedh
                  Automated Home Guru
                  • Mar 2017
                  • 177

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

                  Comment

                  • gordonb3
                    Automated Home Ninja
                    • Dec 2016
                    • 273

                    #24
                    Originally posted by gordonb3 View Post
                    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).

                    Comment

                    • dty
                      Automated Home Ninja
                      • Aug 2016
                      • 489

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

                      Comment

                      • gordonb3
                        Automated Home Ninja
                        • Dec 2016
                        • 273

                        #26
                        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.

                        Comment

                        • dty
                          Automated Home Ninja
                          • Aug 2016
                          • 489

                          #27
                          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.

                          Comment

                          • gordonb3
                            Automated Home Ninja
                            • Dec 2016
                            • 273

                            #28
                            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.

                            Comment

                            • Hankscorpion
                              Automated Home Lurker
                              • Aug 2017
                              • 8

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

                              Comment

                              • DBMandrake
                                Automated Home Legend
                                • Sep 2014
                                • 2361

                                #30
                                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; 17 November 2018, 11:57 AM.

                                Comment

                                Working...
                                X