Decoded - EvoHome API access to control remotely.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • jzwack-honeywell
    Automated Home Jr Member
    • Jan 2016
    • 36

    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:


    It should change to:


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

    Comment

    • Caesium
      Automated Home Jr Member
      • Oct 2015
      • 13

      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

      Comment

      • Krejt
        Automated Home Jr Member
        • Jan 2016
        • 21

        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?
        Evohomeclient temperatures on ThingSpeak: https://thingspeak.com/channels/79213

        Comment

        • watchforstock
          Automated Home Jr Member
          • Mar 2014
          • 20

          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; 19 January 2016, 11:05 PM.

          Comment

          • watchforstock
            Automated Home Jr Member
            • Mar 2014
            • 20

            @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!

            Comment

            • jzwack-honeywell
              Automated Home Jr Member
              • Jan 2016
              • 36

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

              Comment

              • nico
                Automated Home Jr Member
                • Oct 2015
                • 14

                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

                Comment

                • DBMandrake
                  Automated Home Legend
                  • Sep 2014
                  • 2361

                  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:


                  It should change to:


                  I'll edit my previous post to compensate.
                  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; 20 January 2016, 12:47 PM.

                  Comment

                  • DBMandrake
                    Automated Home Legend
                    • Sep 2014
                    • 2361

                    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.

                    Comment

                    • Krejt
                      Automated Home Jr Member
                      • Jan 2016
                      • 21

                      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

                      Comment

                      • paulockenden
                        Automated Home Legend
                        • Apr 2015
                        • 1719

                        In JSON-speak, u at the start of a string means unicode.

                        Comment

                        • jzwack-honeywell
                          Automated Home Jr Member
                          • Jan 2016
                          • 36

                          Originally posted by DBMandrake View Post
                          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.
                          Yep, watchforstock and I have been chatting via PM. Fortunately the API our app uses in EMEA is the same as what I gave to SmartThings, I said when I get some spare time I'll provide suggestions (if I have any) on API use.

                          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!
                          Yes, eventually that domain would have gone completely dark. Glad I could help.

                          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.
                          So looking quick the V1 of the client uses our old API that works for both NA and EMEA devices (aside from the specific Evo resources). The V2 of the client uses the emea specific API. I would use that (it's the same our mobile app uses, along with SmartThings and other partners).

                          Also, glad you're finding the new endpoint quicker. That was part of the plan!
                          developer.honeywell.com | I work for Honeywell. API Evangelist. Views are my own.

                          Comment

                          • Caesium
                            Automated Home Jr Member
                            • Oct 2015
                            • 13

                            jzwack, while we have your attention

                            Do you know why the API does not return the correct value for a HR92 mode? That is, it always says "Off", but allowedModes indicates that it could return either "Heat" or "Off" depending on whether its calling for heat. This would be useful data to have from the API.

                            Comment

                            • jzwack-honeywell
                              Automated Home Jr Member
                              • Jan 2016
                              • 36

                              You specifically interested in what I would call "runtime"? As in is the valve actually open or closed? I don't know the specific answer to that, but I know in the US we don't enable that on all of our thermostats either. It's a power/firmware problem.
                              developer.honeywell.com | I work for Honeywell. API Evangelist. Views are my own.

                              Comment

                              • Caesium
                                Automated Home Jr Member
                                • Oct 2015
                                • 13

                                Originally posted by jzwack-honeywell View Post
                                You specifically interested in what I would call "runtime"? As in is the valve actually open or closed? I don't know the specific answer to that, but I know in the US we don't enable that on all of our thermostats either. It's a power/firmware problem.
                                Yes, whether the valve is open or closed. The percentage it is open would be icing on the cake

                                I assumed the controller must know whether a valve is open or not so it can control the boiler demand appropriately. Is this not the case?

                                Comment

                                Working...
                                X