Page 2 of 33 FirstFirst 123456712 ... LastLast
Results 11 to 20 of 327

Thread: Evohome app broken

  1. #11
    Automated Home Jr Member
    Join Date
    Oct 2016
    Location
    Cambridge
    Posts
    22

    Default

    The only way I have found to "fix" this issue, is to remove the device from the system. This shouldn't be necessary, but it seems to fix the problem for now:


    1. Login on the Total Connect Comfort account from a PC or laptop.
    2. Tap on "Location name" under "My Locations"
    3. Tap on the "View Settings" box under "Comfort System"
    4. MAKE A NOTE OF THE MAC AND CRC CODES
    5. Tap on "Remove Comfort System" and confirm the action.
    6. Tap on "Add System" under "Comfort System" to add THE MAC ID and CRC (from step 4) and click "Submit"



    I had to perform the above steps during the last outage . This is an overkill, but it may work if you are desperate to get the device, app and web working again.

  2. #12
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,795

    Default

    Checked my graphs today and see that there are huge intermittent breaks in the graph, tried querying the API manually with a test python script I use, which was just returning errors for both V1 and V2 API's.

    Tried logging in to the total connect website only to be told "You have attempted to login with incorrect credentials too many times. Please try again later."

    Umm, no I haven't Honeywell, that's the first time I've tried to log into the web interface for a long, long time...

    Domoticz and evohome-munin do use the same login and password to connect, but I know they are correct because they are hard coded into the config scripts, so will not somehow "forget" what the correct password is.

    As I had been meaning to change my Honeywell password for a while (to a password manager generated random character one) I thought I might as well do this now, so used the forgot my password link to reset my password which it claims I was successful in doing.

    Try to log into the web interface again with the new just set password, "You have attempted to login with incorrect credentials too many times. Please try again later.". And naturally now my iPhone client cant connect either, as it is also reporting too many wrong attempts, despite there never being ANY wrong attempts, at least not from me.

    So, anyone else still having problems ? Anyone else falsely being told they've had too many wrong password attempts ? Anyone know how long the lockout will be ? Very annoying...

    For a year or so the API has been pretty reliable but the reliability has been absolutely shocking in the last couple of months with multiple ongoing intermittent problems. Please sort it out Honeywell!

    Edit: Here is debug output from the python script: (password censored)

    Code:
    pi@pi1monitor:~ $ ./evohome_V2
    INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): tccna.honeywell.com
    send: 'POST /Auth/OAuth/Token HTTP/1.1\r\nHost: tccna.honeywell.com\r\nContent-Length: 304\r\nAccept-Encoding: gzip, deflate\r\nAccept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml\r\nUser-Agent: python-requests/2.9.1\r\nConnection: keep-alive\r\nContent-Type: application/x-www-form-urlencoded\r\nAuthorization: Basic YjAxM2FhMjYtOTcyNC00ZGJkLTg4OTctMDQ4YjlhYWRhMjQ5OnRlc3Q=\r\n\r\nUsername=xxxxxxx%40xxxx.com&Host=rs.alarmnet.com%2F&Password=xxxxxxx&Pragma=no-cache&Cache-Control=no-store+no-cache&scope=EMEA-V1-Basic+EMEA-V1-Anonymous+EMEA-V1-Get-Current-User-Account&grant_type=password&Content-Type=application%2Fx-www-form-urlencoded%3B+charset%3Dutf-8&Connection=Keep-Alive'
    reply: 'HTTP/1.1 429 Too Many Requests\r\n'
    header: Cache-Control: no-cache
    header: Pragma: no-cache
    header: Content-Type: application/json;charset=UTF-8
    header: Expires: -1
    header: Server: Microsoft-IIS/8.5
    header: Set-Cookie: thlang=en-US; expires=Wed, 07-Nov-2068 13:10:56 GMT; path=/
    header: Server: Web1
    header: Date: Wed, 07 Nov 2018 13:10:55 GMT
    header: Content-Length: 34
    header: Set-Cookie: NSC_UDDOB-TTM-WT=ffffffff090ecc1a45525d5f4f58455e445a4a42378b;expires=Wed, 07-Nov-2018 13:12:56 GMT;path=/;secure;httponly
    DEBUG:requests.packages.urllib3.connectionpool:"POST /Auth/OAuth/Token HTTP/1.1" 429 34
    Traceback (most recent call last):
      File "./evohome_V2", line 6, in <module>
        client = EvohomeClient('xxxxxxx@xxx.com', 'xxxxxxxxxxxx', debug=True)
      File "/usr/local/lib/python2.7/dist-packages/evohomeclient2/__init__.py", line 18, in __init__
        self._login()
      File "/usr/local/lib/python2.7/dist-packages/evohomeclient2/__init__.py", line 69, in _login
        self.access_token = self._convert(r.text)['access_token']
    KeyError: 'access_token'
    Looks like the real issue is an HTTP/1.1 429 Too Many Requests response from the server, not a password issue. Too many requests from my IP or just too many requests to that server in general ?

    If it was only for my IP, why would I see the same issue with the web interface, when I am accessing that using a browser from a different broadband connection (work) completely unrelated to my home IP where my system is graphing from...

    PS the reset password page seems to display errors in Spanish ? "Lo sentimos, se ha producido un error inesperado. Por favor, inténtelo más tarde."
    Last edited by DBMandrake; 7th November 2018 at 01:24 PM.

  3. #13
    Automated Home Sr Member
    Join Date
    Mar 2017
    Posts
    80

    Default

    This may or may not be of help.
    My issues to do with controlling via app or web interface seem to have resolved themselves.
    My issue with too many connections while graphing seems to have been related to me creating a new session every 5 minutes when I did a read. I modified my code so that it reused the session id and the gaps I was getting have vanished...
    However, it had been reading fine before so maybe Honeywell have tightened up on things.

  4. #14
    Automated Home Sr Member
    Join Date
    Mar 2017
    Posts
    80

    Default

    ok I take some of that back... seems app and web interface still aren't working, at least not reliably, time to give Karrimor's suggestion a go

  5. #15
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,795

    Default

    Quote Originally Posted by Stevedh View Post
    My issue with too many connections while graphing seems to have been related to me creating a new session every 5 minutes when I did a read. I modified my code so that it reused the session id and the gaps I was getting have vanished...
    However, it had been reading fine before so maybe Honeywell have tightened up on things.
    Strangely, the issue seems to have resolved itself, for the moment.

    When you say "reusing the session id" what do you mean ?

    I use these python bindings, I'm not sure there is any way to do this as it authenticates from the beginning every time, and the python script calling the routines is run as a munin plugin so is freshly launched every time a query is sent:

    https://github.com/watchforstock/evohome-client

    I suspect what you're doing only works around underlying intermittent server issues by bypassing the first https request where the username and password are sent - that seems to be the query that is the one to fail whenever there are problems.
    Last edited by DBMandrake; 7th November 2018 at 02:02 PM.

  6. #16
    Automated Home Sr Member
    Join Date
    Mar 2017
    Posts
    80

    Default

    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.

  7. #17
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,795

    Default

    Quote 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:

    https://github.com/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; 7th November 2018 at 03:24 PM.

  8. #18
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    128

    Default

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

  9. #19
    Automated Home Sr Member
    Join Date
    Mar 2017
    Posts
    80

    Default

    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?

  10. #20
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    128

    Default

    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.

Posting Permissions

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