Page 24 of 47 FirstFirst ... 14192021222324252627282934 ... LastLast
Results 231 to 240 of 470

Thread: Decoded - EvoHome API access to control remotely.

  1. #231
    Automated Home Jr Member zcapr17's Avatar
    Join Date
    Oct 2014
    Location
    UK
    Posts
    20

    Default

    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

  2. #232
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,132

    Default

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

  3. #233
    Automated Home Jr Member zcapr17's Avatar
    Join Date
    Oct 2014
    Location
    UK
    Posts
    20

    Default

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

  4. #234
    Automated Home Jr Member zcapr17's Avatar
    Join Date
    Oct 2014
    Location
    UK
    Posts
    20

    Default

    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.

  5. #235
    Automated Home Jr Member zcapr17's Avatar
    Join Date
    Oct 2014
    Location
    UK
    Posts
    20

    Default

    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?

  6. #236
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,688

    Default

    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.

  7. #237
    Automated Home Sr Member
    Join Date
    Oct 2015
    Posts
    80

    Default

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

  8. #238
    Automated Home Jr Member zcapr17's Avatar
    Join Date
    Oct 2014
    Location
    UK
    Posts
    20

    Default

    Quote 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

  9. #239
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,688

    Default

    Sounds like it might be time to fire up wireshark.

  10. #240
    Automated Home Jr Member
    Join Date
    Jan 2016
    Location
    The Netherlands
    Posts
    21

    Default

    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

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
  •