Page 32 of 47 FirstFirst ... 22272829303132333435363742 ... LastLast
Results 311 to 320 of 461

Thread: Decoded - EvoHome API access to control remotely.

  1. #311
    Automated Home Lurker
    Join Date
    Dec 2016
    Posts
    6

    Default

    Quote Originally Posted by DBMandrake View Post

    If the V1 API works but the V2 API returns errors it probably means your evohome-client python libraries are outdated and should be updated from here:

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

    There was a change to the server hostname for the V2 API some time back and the python client libraries were updated to include this change but if your evohome-client library is out of date it will be querying the old server hostname which may no longer exist.
    I tried to query V2 API and it returned the error.
    I proved that the version I used is the actual version from git-repository

    This one is linked in the domoticz wiki as well.

    Frustrating...

    Tried to debug:

    Code:
    DEBUG: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\nConnection: keep-alive\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.12.3\r\nAuthorization: Basic YjAxM2FhMjYtOTcyNC00ZGJkLTg4OTctMDQ4YjlhYWRhMjQ5OnRlc3Q=\r\nContent-Length: 306\r\nContent-Type: application/x-www-form-urlencoded\r\n\r\nUsername=secret&Host=rs.alarmnet.com%2F&Password=verysecret&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 200 OK\r\n'
    header: Set-Cookie: tccna=R3709470637; path=/; expires=Mon, 12-Dec-2016 14:04:12 GMT
    header: Cache-Control: no-cache
    header: Pragma: no-cache
    header: Content-Length: 1433
    header: Content-Type: application/json;charset=UTF-8
    header: Expires: -1
    header: Server: Microsoft-IIS/8.5
    header: X-Powered-By: ASP.NET
    header: Server: Web1
    header: Date: Sun, 11 Dec 2016 13:59:48 GMT
    DEBUG:requests.packages.urllib3.connectionpool:https://tccna.honeywell.com:443 "POST /Auth/OAuth/Token HTTP/1.1" 200 1433
    DEBUG:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): tccna.honeywell.com
    send: 'GET /WebAPI/emea/api/v1/userAccount HTTP/1.1\r\nHost: tccna.honeywell.com\r\nConnection: keep-alive\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.12.3\r\napplicationId: b013aa26-9724-4dbd-8897-048b9aada249\r\nAuthorization: bearer AZqFqY0t8dVUzXN2QY13AxwWTuhB8VDEuyN3sz-41jeLSHGWw-HCNgPVH0ZfXOSvWOf2_uqKWMHYBn41F9TNQO8ld_intfBM7QsugBs1C0tDNOsz8oQHre2jJP6Bs1FVIlWlrLiUI2Bf5WvSlZ_MPAPb_znvVujEgtF3f3dWolMaVtb23eu3VAqRkNXgH7mdkaxuwrCYE7wvW1nmgMetkl3rkd3bCTfHYSufyC6DqnOFiN3xzWcq0McifxNpPvm8v8HJUIoJZyb1JNMznA0kouu8TaqVMeouc6bOrtL5OrPf4vmcJH8fWzAGnHlDHnL0F1CCxgFVm8ywgLglBRrUTHNhlxqfqtTsxkvlW-zaFNlJfdzljEjR2UTti4lBBRt8FVJEppuT2EQFn_oajO3onFKKJR1EmtzgdNPbQEdixJ0CtpBTufnQ4J264KG-WD1zLzVbCZ25uOg-jSUteq19jHh1rjuFmXlDlAGXfBkjd3qr_QazTafCtRsEauFugsRT7Ok2dqNfupMniRLpFm4HKJmVMJqYwrHI3vx-YnoxEfc3wNOpfYjvgWNaR7JsMdM8X9jxXkZS_JFugzjMo5BcUE5_qfsACt7LxK-X9QYC8odBeKdd0_rTcLvNUPZ_7yhrR4YA9g\r\n\r\n'
    reply: 'HTTP/1.1 400 Bad Request\r\n'
    header: Set-Cookie: tccna=R3709470637; path=/; expires=Mon, 12-Dec-2016 14:04:12 GMT
    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: X-AspNet-Version: 4.0.30319
    header: X-Powered-By: ASP.NET
    header: Server: Web1
    header: Date: Sun, 11 Dec 2016 13:59:48 GMT
    header: Content-Length: 167
    DEBUG:requests.packages.urllib3.connectionpool:https://tccna.honeywell.com:443 "GET /WebAPI/emea/api/v1/userAccount HTTP/1.1" 400 167
    Traceback (most recent call last):
      File "test.py", line 5, in <module>
        client = EvohomeClient('secret', 'verysecret', 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 76, in _login
        self.installation()
      File "/usr/local/lib/python2.7/dist-packages/evohomeclient2/__init__.py", line 86, in installation
        r = requests.get('https://tccna.honeywell.com/WebAPI/emea/api/v1/location/installationInfo?userId=%s&includeTemperatureControlSystems=True' % self.account_info['userId'], headers=self.headers)
    TypeError: list indices must be integers, not str
    so there ist an error 400 (bad request)

    any ideas?
    Last edited by thtools; 11th December 2016 at 03:06 PM.

  2. #312
    Automated Home Jr Member
    Join Date
    Jan 2016
    Location
    Minneapolis, MN, USA
    Posts
    35

    Default

    I just tried the evohomeclient2 locally and it worked no problem.

    Based on your logfile, it looks like the client couldn't get the "userId" number from GET /WebAPI/emea/api/v1/userAccount
    developer.honeywell.com | I work for Honeywell. API Evangelist. Views are my own.

  3. #313
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,844

    Default

    What version does 'python -V' report ? What operating system and platform are you running on ?

    Also does your password have any unusual punctuation in it ? I wonder if the evohomeclient library doesn't correctly escape certain punctuation in passwords.

    I notice that you have a different version of python-requests than me but other than that and the order of some of the HTTP headers I can't see any difference, so it might be worth temporarily changing to a more plain password (just letters and numbers) and seeing if it works then, as different usernames and passwords would be the main difference between your setup and my working one.
    Last edited by DBMandrake; 12th December 2016 at 10:47 PM.

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

    Default

    Hi all,

    I like to start with a big thank you to all those that managed to figure out the protocol. I've been running the Domoticz scripts with the python evohome-client for quite some time but it became more and more of an annoyance that python is so heavy on resources. So I started out creating a C++ library for the methods. It's still a bit rough around the edges, but I did manage to create a first working application with it that combines all the functions of the Domoticz scripts.

    I'm a bit puzzled at the moment however about what is version 2 API and what is version 1 API. The one I currently access uses URIs that start with /WebAPI/emea/api/v1/. Posts in this thread seem to indicate that this is the version 2 API. Is that correct? In my implementation I calculate the next scheduled switch point - I already did that in the python scripts - and on the Honeywell developer site I found an example output that already includes that information. I was hoping the other API which I figured to be the version 2 API but apparently is version 1(?) would supply me that output, but I can't seem to get any schedule information using that API.

    Hope you guys can enlighten me. In the meantime if you're interested in checking out my project, it is here on GitHub

  5. #315
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,844

    Default

    Quote Originally Posted by gordonb3 View Post
    I'm a bit puzzled at the moment however about what is version 2 API and what is version 1 API. The one I currently access uses URIs that start with /WebAPI/emea/api/v1/. Posts in this thread seem to indicate that this is the version 2 API. Is that correct?
    Yes that's correct. Looking at watchforstock's evohome-client python library this is the URL accessed for the "V2" API:

    https://tccna.honeywell.com/WebAPI/emea/api/v1/

    The older "V1" API uses:

    https://tccna.honeywell.com/WebAPI/api/

    So a bit confusing on the naming side - it is those of us here who have coined the API's as V1 and V2, or old and new API's - apparently honeywell considers the new version to be V1 which is confusing.

    Basically the old API didn't support scheduling while the current newer API does support scheduling. Both API's are still available and have different but overlapping feature sets. In general the newer API is the best one to use - it supports reading and writing schedules and reading hotwater status, neither of which the old API does. The only advantage the old API has is that it provides measured temperatures to two decimal places whereas the V2 API rounds measured temperatures to the nearest half a degree then biases it towards the set point (same as the evotouch interface) so if you want accurate unmodified temperature readings you'll want to pull that from the older API. (The latest versions of the Domoticz evo-update.sh do that)
    In my implementation I calculate the next scheduled switch point - I already did that in the python scripts - and on the Honeywell developer site I found an example output that already includes that information. I was hoping the other API which I figured to be the version 2 API but apparently is version 1(?) would supply me that output, but I can't seem to get any schedule information using that API.
    Correct - the older API does not support scheduling information at all, only reading temperatures and performing manual overrides.

  6. #316
    Automated Home Jr Member
    Join Date
    Jan 2016
    Location
    Minneapolis, MN, USA
    Posts
    35

    Default

    https://tccna.honeywell.com/WebAPI/api/ is used exclusively for our North American products now.

    As the product base increased and considering the fact those products have different command needs we implemented a version of TCC just for UK/EMEA. Hence: https://tccna.honeywell.com/WebAPI/emea/api/v1/

    The only reason v1 and v2 became terms is because of evohome-client. :-)

    Everything on https://developer.honeywell.com is for our Lyric family of products, so that's a bit different. I keep wanting to make the TCC API more self-service as well but other things take priority for better or worse.
    developer.honeywell.com | I work for Honeywell. API Evangelist. Views are my own.

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

    Default

    Hmmm... But you did add a v1 literal to the new URIs, so that kind of implies that the older client is considered to be something of a beta? Doesn't really make it any easier. Now I don't know whether I should follow the definition introduced by this thread or keep the running code as is and simply rename the currently unused class for the second API into something like old or deprecated evohomeclient.

    In any case, since there appears to be no smarter way to retrieve schedule information other than requesting them for each zone individually, I think I'll maintain my current method of using a local cache for this information. It's not like people will be changing that information multiple times a day. I should probably extend the current method to include a timestamp in the cache for automatic renewal though. I'm also considering adding a secondary time until input of +XX minutes to the front end application, which is something I recently realized to be using quite a lot for the children's bedrooms around bedtime.

  8. #318
    Automated Home Jr Member
    Join Date
    Jan 2016
    Location
    Minneapolis, MN, USA
    Posts
    35

    Default

    In the definitions for evohome-client, for zones they have the "Setpointmode" and "TimeUntil" values.

    I think based on the code:
    0 == "FollowSchedule"
    1 == "PermanentHold"
    2 == "TemporaryHold"

    If "setpointmode" == "FollowSchedule" then "TimeUntil" should always equal next schedule switchpoint. Unless no schedule is set.

    For instance, if you changed "SetpointMode" from 0 to 2, and left "timeUntil" with the same value you would have a temp hold until the next switchpoint.

    Also it looks like evohomeclient2 is getting schedule data.
    developer.honeywell.com | I work for Honeywell. API Evangelist. Views are my own.

  9. #319
    Automated Home Lurker
    Join Date
    Dec 2016
    Posts
    6

    Default

    Quote Originally Posted by DBMandrake View Post
    What version does 'python -V' report ? What operating system and platform are you running on ?

    Also does your password have any unusual punctuation in it ? I wonder if the evohomeclient library doesn't correctly escape certain punctuation in passwords.

    I notice that you have a different version of python-requests than me but other than that and the order of some of the HTTP headers I can't see any difference, so it might be worth temporarily changing to a more plain password (just letters and numbers) and seeing if it works then, as different usernames and passwords would be the main difference between your setup and my working one.
    Version python is 2.7.12
    OS is Ubuntu 16.04.1 LTS

    There is no punctuation in username or password (just letters and numbers)
    Password has been changed, still no effect

    In Addition: the username is an email-adress, so it contains not only letters
    Last edited by thtools; 15th December 2016 at 07:51 AM.

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

    Default

    Surely if the mobile app works then it's not the username or password?

Tags for this Thread

Posting Permissions

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