Page 19 of 47 FirstFirst ... 9141516171819202122232429 ... LastLast
Results 181 to 190 of 470

Thread: Decoded - EvoHome API access to control remotely.

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

    Default

    You're right, that's my fault.

    Today it points to rs.alarmnet.com/totalconnectcomfort

    You drop the directory. So for instance in the code today it calls:
    https://rs.alarmnet.com:443/TotalCon...v1/userAccount

    It should change to:
    https://tccna.honeywell.com/WebAPI/e...v1/userAccount

    I'll edit my previous post to compensate.
    developer.honeywell.com | I work for Honeywell. API Evangelist. Views are my own.

  2. #182
    Automated Home Jr Member
    Join Date
    Oct 2015
    Posts
    13

    Default

    Quote Originally Posted by Krejt View Post
    Switching to the tccna.honeywell.com host doesn't seem to be as simple as to search and replace that host name in all evohomeclient2 files. I tried that (being totally clueless ;-) and hit a HTTP/1.1 404 Not Found error on the very first request. I bet the tccna.honeywell.com machine uses different directories. This is something for smarter guys like watchforstock to look into ;-)

    You need to drop the /TotalConnectComfort/ out of the URL.

    So from this: https://rs.alarmnet.com/TotalConnect...PI/api/Session
    to this: https://tccna.honeywell.com/WebAPI/api/Session

    Seems to be working for me so far

  3. #183
    Automated Home Jr Member
    Join Date
    Jan 2016
    Location
    The Netherlands
    Posts
    17

    Default

    Perfect! Dropping the /TotalConnectComfort directory from the URL while changing from the rs.alarmnet.com host to the tccna.honeywell.com host did the trick!
    I patched my evohomeclient2 and now seem to be able to request temperatures using the V2 API without any error 500 messages. (Just tested for about an hour.)

    Note to watchforstock: maybe check the need for the :443 port numbers in your code. This port number isn't consistently declared in the zone.py and hotwater.py files?

  4. #184
    Automated Home Jr Member
    Join Date
    Mar 2014
    Posts
    19

    Default

    I've updated the library to reflect this change - based on a quick check it seems to be working ok - feedback welcome!

    Either download it direct from github at https://github.com/watchforstock/evohome-client or run:

    Code:
    pip install evohomeclient
    or if you've previously installed it using pip:

    Code:
    pip install -U evohomeclient
    @jzwack-honeywell, I've had a question come in from a US user - this library isn't working for them (which isn't surprising given the emea elements in the URLs). Is there an easy change to make that'll mean it works for the US?
    Last edited by watchforstock; 19th January 2016 at 10:05 PM.

  5. #185
    Automated Home Jr Member
    Join Date
    Mar 2014
    Posts
    19

    Default

    @Krejt - thanks for the note about ports, I've just posted an update to the library which as well as making the changes noted above removes the port numbers. It won't have affected anything, but better to clean up!

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

    Default

    @watchforstock - Unfortunately no, the US API resource structure is very different from EMEA, different API keys, accounts, devices, etc. Willing to help though if you're interested.
    developer.honeywell.com | I work for Honeywell. API Evangelist. Views are my own.

  7. #187
    Automated Home Jr Member
    Join Date
    Oct 2015
    Posts
    14

    Default

    This is something Honeywell should include, data logging, maybe inside the web interface.
    Should be great some enhancements in the iPhone app too, such as the ability to copy the entire week schedule to another zone (feature present on EvoHome Touch Control), and native geofencing inside the app (already present in USA Lyric App), without the need of Life360 and IFTTT.

    Schermata 2016-01-19 alle 23.28.07.jpg

  8. #188
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,952

    Default

    Quote Originally Posted by jzwack-honeywell View Post
    You're right, that's my fault.

    Today it points to rs.alarmnet.com/totalconnectcomfort

    You drop the directory. So for instance in the code today it calls:
    https://rs.alarmnet.com:443/TotalCon...v1/userAccount

    It should change to:
    https://tccna.honeywell.com/WebAPI/e...v1/userAccount

    I'll edit my previous post to compensate.
    Quote Originally Posted by watchforstock View Post
    I've updated the library to reflect this change - based on a quick check it seems to be working ok - feedback welcome!

    Either download it direct from github at https://github.com/watchforstock/evohome-client or run:

    Code:
    pip install evohomeclient
    or if you've previously installed it using pip:

    Code:
    pip install -U evohomeclient
    @jzwack-honeywell, I've had a question come in from a US user - this library isn't working for them (which isn't surprising given the emea elements in the URLs). Is there an easy change to make that'll mean it works for the US?
    I wanted to thank watchforstock for the Python API that many of us use, not only for writing it in the first place also but updating it so quickly to change the URL - I have updated my copy via Pip and have also removed the certificate that I had manually installed for rs.alarmnet.com to work around the certificate issue, and can confirm that both V1 and V2 API's are working on the new URL.

    I'd also like to thank Joe for joining this thread so that we have some contact with someone from honeywell who works on the API!

    As you have probably gathered Joe, the existing libraries and implementations such as the one from watchforstock were originally developed based on a reverse engineering of the over the air protocol, so it's possible that not everything about the API is understood correctly or done correctly - for example we were unaware that the address of the servers had changed, so it's a good thing you came along when you did.

    Presumably the mobile apps were updated in a recent update to use the new servers but those of us using the APIs directly were oblivious to the change so would have been wondering what was wrong when the old servers were finally retired!

    I have a quick question regarding the V1 and V2 API's - which API is recommended for use for simple tasks such as polling the zone temperatures and set points every 5 minutes for graphing purposes - I had been using the V1 API purely because the V2 API had been returning about 25% HTTP 500 errors, thus leaving lots of gaps in my graph data. As the same data I needed was available from the V1 API and that did not seem to return any errors I used that.

    Assuming that the HTTP 500 errors are no longer an issue with the new server address, should I be switching back to the V2 API ? I don't know much about the APIs but I get the impression that the V2 API was implemented to provide for the new iPhone/Android app functionality of configuring schedules remotely which was absent in the V1 API, and it looks like the V2 API functionality is a superset of V1. So is it likely that the V1 API will get phased out any time soon ?

    After the update to the server URL's I'm finding both API's much quicker than before - previously the V1 API was taking maybe 10 seconds and the V2 API (when it worked) about 20 seconds. With the new server address the V1 API takes 3 seconds to return all my zone temperature and set point data and the V2 API takes 6 seconds, and so far (touch wood) no HTTP errors.
    Last edited by DBMandrake; 20th January 2016 at 11:47 AM.

  9. #189
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,952

    Default

    Quote Originally Posted by watchforstock View Post
    @Krejt - thanks for the note about ports, I've just posted an update to the library which as well as making the changes noted above removes the port numbers. It won't have affected anything, but better to clean up!
    Just noticed this after writing my previous post - V1 and V2 API's are returning data in slightly different formats, is this expected ? (I didn't check this before updating evohomeclient with pip, so I don't know if it was always like this)

    V1:
    {'temp': 14.0, 'setpoint': 5.0, 'thermostat': u'EMEA_ZONE', 'name': u'Hall', 'id': 1377389}
    {'temp': 11.0, 'setpoint': 5.0, 'thermostat': u'EMEA_ZONE', 'name': u'Living Room', 'id': 1378782}
    {'temp': 15.5, 'setpoint': 5.0, 'thermostat': u'EMEA_ZONE', 'name': u'Main Bedroom', 'id': 1438045}

    V2:
    {'temp': 14.0, 'setpoint': 5.0, 'thermostat': 'EMEA_ZONE', 'name': u'Hall', 'id': u'1377389'}
    {'temp': 11.0, 'setpoint': 5.0, 'thermostat': 'EMEA_ZONE', 'name': u'Living Room', 'id': u'1378782'}
    {'temp': 15.5, 'setpoint': 5.0, 'thermostat': 'EMEA_ZONE', 'name': u'Main Bedroom', 'id': u'1438045'}

    Notice the difference at the end after id. Edit: also just before EMEA_ZONE.

  10. #190
    Automated Home Jr Member
    Join Date
    Jan 2016
    Location
    The Netherlands
    Posts
    17

    Default

    Yup, this difference in syntax was there already before the recent evoclient update. I noticed this last week already and made a note to investigate the meaning of the 'u'. (user?) Another difference I noticed then was a difference in the order of the zones. Your post suggests that difference is gone? I'll look into this tonight.
    Evohomeclient temperatures on ThingSpeak: https://thingspeak.com/channels/79213

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
  •