Decoded - EvoHome API access to control remotely.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • DBMandrake
    Automated Home Legend
    • Sep 2014
    • 2361

    Originally posted by Krejt View Post
    At this moment the Total Connect servers and the API are down for maintenance. The evohomeclient spits an error "No JSON object could be decoded" everytime you try to read the temperatures. Can't something be made in the client to handle that error and/or this situation where the servers are down a little more gracefull?

    Traceback (most recent call last):
    File "/home/pi/Evohome/evospeak.py", line 105, in <module>
    main()
    File "/home/pi/Evohome/evospeak.py", line 62, in main
    client = EvohomeClient(EVOHOMELOGIN,EVOHOMEPASS)
    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']
    File "/usr/local/lib/python2.7/dist-packages/evohomeclient2/base.py", line 32, in _convert
    return json.loads(object)
    File "/usr/lib/python2.7/json/__init__.py", line 338, in loads
    return _default_decoder.decode(s)
    File "/usr/lib/python2.7/json/decoder.py", line 366, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
    File "/usr/lib/python2.7/json/decoder.py", line 384, in raw_decode
    raise ValueError("No JSON object could be decoded")
    ValueError: No JSON object could be decoded
    It's really up to you as the caller to the library to catch the exception and do your own error handing, for example:

    &#8230;opriate exit code and error message (for the munin-node.log) instead of just crashing.

    Comment

    • private4587
      Automated Home Lurker
      • Oct 2014
      • 8

      Hi rotor I have just purchased a Raspberry Pi 2 with some thing like this in mind, although i have no knowledge of Python i am very keen to learn. This is the sort of project i have in mind. Could you please let me know when you have it all set up.

      many thanks

      Comment

      • MrB
        Automated Home Sr Member
        • Oct 2015
        • 80

        @Joe (Honeywell)

        Anything on the DHW setpoint temp yet?

        Also, any chance to find out why the HR92s always report "Off" and why the correct data cannot be returned via the API?

        Many thanks in advance....

        Comment

        • sbarriba
          Automated Home Lurker
          • Mar 2016
          • 1

          I'm recently installed evoHome in our house for 4 UFH and 6 radiator zones plus the hot water bolt on. It's working fairly well but I'm disappointed in the lack of graphs showing actual vs desired vs heat demand hence my interest in the API.

          It's great to see the hard work already gone into understanding the API and it was therefore easy for me to get the PHP clients et al pulling down data for my install.

          However I'm unable to find data points which indicate 1) if a particular zone is calling for heat (which you don't see visually on the central controller either) and 2) an indication if the zone is in "Optimised Start" mode e.g. its starting heating in advance of a set point to ensure that set point is meet? Neither data is shown in the iOS app either.

          I'm looking at data returned from the "https://tccna.honeywell.com/WebAPI/emea/api/v1/location/[loc]/status?includeTemperatureControlSystems=True" call.

          Anyone find a way to obtain or derive the above two data points?

          Thanks in advance

          Comment

          • DBMandrake
            Automated Home Legend
            • Sep 2014
            • 2361

            I think the general consensus is that heat demand and optimal start information is not available through the Web API, and only a software update on the controller would ever make that possible.

            If you were monitoring the wireless traffic between devices with an HCI80 then theoretically the heat demand of each zone thermostat would be available however optimal start information would not because zone thermostats just see that as a set point change occurring earlier than it otherwise would. They have no knowledge in the over the air protocol of why that set point changed and whether it might be earlier than a scheduled time.

            Comment

            • zcapr17
              Automated Home Jr Member
              • Oct 2014
              • 20

              Hi All,

              First, a big thanks to everyone who's contributed to this thread. I'm writing an app to connect to EvoHome and it wouldn't be possible without the people here.

              Some questions I have about the EvoHome API:

              1) Is it possible to obtain information about the battery status of rad valves?
              [I can't see anything, but perhaps it's accessible from another endpoint like zone schedules?]

              2) Is it possible to determine if the 'window function' is active or not for a zone?
              [This is something the main EvoHome controller displays so I hope to replicate it in my app. At the moment I've having to deduce that the 'window function' is active if the setpoint has dropped to 5C and the mode is not 'Off' and the setpoint is not 5C in the schedule.]

              3) Is it possible to obtain the temperature setpoint when it has been overridden at the rad valve?
              [Overrides set using the main controller or the smartphone app seems to be reported, but if the setpoint is over-ridden at the rad valve it never seems to be reported. I suspect this isn't possible without a controller firmware update.]

              4) Has anyone (as an individual customer) had any luck gaining access to the official API documentation and support via Honeywell themselves?

              Thanks

              Comment

              • DBMandrake
                Automated Home Legend
                • Sep 2014
                • 2361

                Originally posted by zcapr17 View Post
                Hi All,

                First, a big thanks to everyone who's contributed to this thread. I'm writing an app to connect to EvoHome and it wouldn't be possible without the people here.

                Some questions I have about the EvoHome API:

                1) Is it possible to obtain information about the battery status of rad valves?
                [I can't see anything, but perhaps it's accessible from another endpoint like zone schedules?]
                Through the API - no.
                2) Is it possible to determine if the 'window function' is active or not for a zone?
                [This is something the main EvoHome controller displays so I hope to replicate it in my app. At the moment I've having to deduce that the 'window function' is active if the setpoint has dropped to 5C and the mode is not 'Off' and the setpoint is not 5C in the schedule.]
                Even the smart phone app is not aware whether window or optimisation mode is active, so as far as we know this information is not available via the API either.
                3) Is it possible to obtain the temperature setpoint when it has been overridden at the rad valve?
                [Overrides set using the main controller or the smartphone app seems to be reported, but if the setpoint is over-ridden at the rad valve it never seems to be reported. I suspect this isn't possible without a controller firmware update.]
                What model of controller do you have ? If you have the original colour controller with the separate RFG100 then no, HR92 local overrides are never reported back to the controller and thus aren't reported via the API either. Honeywell have indicated that no updates are forthcoming for this model controller so you are out of luck if you have this model.

                If you have the new Wifi model controller you should by now have received a firmware update for the controller which enables reporting HR92 overrides back to the controller - as a consequence the phone apps and API will also now indicate the HR92 local overrides. In effect the controller with new firmware converts a local override into a timed zone override, but only for single room zones.

                Comment

                • zcapr17
                  Automated Home Jr Member
                  • Oct 2014
                  • 20

                  Originally posted by DBMandrake View Post
                  What model of controller do you have ? If you have the original colour controller with the separate RFG100 then no, HR92 local overrides are never reported back to the controller and thus aren't reported via the API either. Honeywell have indicated that no updates are forthcoming for this model controller so you are out of luck if you have this model.

                  If you have the new Wifi model controller you should by now have received a firmware update for the controller which enables reporting HR92 overrides back to the controller - as a consequence the phone apps and API will also now indicate the HR92 local overrides. In effect the controller with new firmware converts a local override into a timed zone override, but only for single room zones.
                  Thanks for the quick reply. Sadly I have an original colour controller and separate RFG100. I'll have to do some more research into any more advantages of the new wifi model to see if it's worth getting one and eBaying my old model.

                  Comment

                  • zcapr17
                    Automated Home Jr Member
                    • Oct 2014
                    • 20

                    One more thing… having just re-read this thread I’ve noticed people are referring to different versions of the API (“v1”, “v2”, "US" vs "EMEA") and I’m now not sure which version I’m using and, more importantly, which is the best one to use.

                    At the moment my app is authenticating using: https://tccna.honeywell.com/Auth/OAuth/Token
                    Then GETting and POSTing objects using: https://tccna.honeywell.com/WebAPI/emea/api/v1/...
                    I had assumed that this is the latest and greatest version of the API for EMEA, is this correct?

                    However, I’ve also seen references to:

                    https://rs.alarmnet.com/TotalConnect...PI/api/Session
                    https://rs.alarmnet.com/TotalConnect...I/emea/api/v1/

                    Is anyone able to summarise the differences between all the various versions of the API, which ones to use when, and if any of them are depreciated?

                    Many Thanks.

                    Comment

                    • zcapr17
                      Automated Home Jr Member
                      • Oct 2014
                      • 20

                      Got an email from Honeywell today:

                      We noticed that you are using an old version of the Total Connect Comfort Intl app on at least one of your mobile devices.
                      The following versions of the app will no longer be supported and will stop working on the 20th of April 2016:
                      • 1.3.6
                      • 2.2.16
                      • 3.0.25
                      Thing is, the only mobile app I'm using is the latest iOS one (4.0.9), so I suspect Honeywell think I'm using an older product because of the applicationId ('b013aa26-9724-4dbd-8897-048b9aada249') that's embedded the custom app I've developed, which uses the ../emea/api/v1/.. API.

                      Anyone know any more about this, will all our custom apps using the 'b013aa26-9724-4dbd-8897-048b9aada249' applicationId stop working next week?!? Is there a newer applicationId that we can use? Or am I just getting worried over nothing?

                      Comment

                      • paulockenden
                        Automated Home Legend
                        • Apr 2015
                        • 1719

                        Ah, THAT explains the email!

                        I wonder whether it's the V1 API that's being retired? I think there's lots of scripts still using that, rather than V2.

                        Comment

                        • MrB
                          Automated Home Sr Member
                          • Oct 2015
                          • 80

                          Originally posted by zcapr17 View Post
                          Got an email from Honeywell today:



                          Thing is, the only mobile app I'm using is the latest iOS one (4.0.9), so I suspect Honeywell think I'm using an older product because of the applicationId ('b013aa26-9724-4dbd-8897-048b9aada249') that's embedded the custom app I've developed, which uses the ../emea/api/v1/.. API.

                          Anyone know any more about this, will all our custom apps using the 'b013aa26-9724-4dbd-8897-048b9aada249' applicationId stop working next week?!? Is there a newer applicationId that we can use? Or am I just getting worried over nothing?
                          I would guess it's to do with the old AlarmNet URL
                          Should be using much newer:
                          https://tccna.honeywell.com/WebAPI/api/......
                          As mentioned by Joe(Jack)@Honeywell USA who appeared here much earlier this year.

                          I've got old/current test/debug programs (Windows) that connects to all the old and new URLs with different params so I can test on the 20th.
                          Of note - I have not received such an email (yet), but I don't use the old URLs.

                          Comment

                          • zcapr17
                            Automated Home Jr Member
                            • Oct 2014
                            • 20

                            Originally posted by MrB View Post
                            I would guess it's to do with the old AlarmNet URL
                            Should be using much newer:
                            https://tccna.honeywell.com/WebAPI/api/......
                            As mentioned by Joe(Jack)@Honeywell USA who appeared here much earlier this year.

                            I've got old/current test/debug programs (Windows) that connects to all the old and new URLs with different params so I can test on the 20th.
                            Of note - I have not received such an email (yet), but I don't use the old URLs.
                            My app's has only ever used https://tccna.honeywell.com/WebAPI...hence why I'm thinking it's something to do with the applicationId. I suspect the applicationId (b013aa26-9724-4dbd-8897-048b9aada249), was originally obtained by packet-sniffing one of the early versions of the app (?)...

                            FYI, the app I've developed is an (unofficial) Evohome connector for SmartThings, since SmartThings' development of the official app appears to have ground to a halt. It's written in Groovy. If anyone's interested, see https://community.smartthings.com/t/...egration/44953 and https://github.com/codersaur/SmartThings

                            Comment

                            • paulockenden
                              Automated Home Legend
                              • Apr 2015
                              • 1719

                              Sounds like it might be time to fire up wireshark.

                              Comment

                              • Krejt
                                Automated Home Jr Member
                                • Jan 2016
                                • 21

                                Yup Paul, Wireshark..... or Honeywell!

                                ( Both the Evohomeclient and evohomeclient2 currently use the https://tccna.honeywell.com domain.
                                The evohomeclient uses the ApplicationId 91db1612-73fd-4500-91b2-e63b069b185c and URL's like https://tccna.honeywell.com/WebAPI/api/...
                                The evohomeclient2 uses the applicationId b013aa26-9724-4dbd-8897-048b9aada249 and URL's like https://tccna.honeywell.com/WebAPI/emea/api/v1/..... )

                                On my Raspberry Pi I use the evohomeclient2 and do not remember to have recieved the mail mentioned above in the mailbox of the related Total Connect Comfort account, but I might have missed it?
                                And since Zcapr17 in his SmartThings connector uses the same https://tccna.honeywell.com/ domain, the /WebAPI/emea/api/v1/..... URI and the b013aa26-9724-4dbd-8897-048b9aada249' applicationId we might all face breakdown next week!

                                Good idea to fire up Wireshark (who?),.. and let's ask Honeywell to provide some more information and guidance on using the API? It is about time....

                                @Honeywell: It isn't very 2016 to have us sniff and reverse engineer your API! Please provide some information and guidance in the discussion above first, and include Evohome in your Connected Home open API program (https://developer.honeywell.com/) quickly?
                                Evohomeclient temperatures on ThingSpeak: https://thingspeak.com/channels/79213

                                Comment

                                Working...
                                X