Page 47 of 47 FirstFirst ... 37424344454647
Results 461 to 468 of 468

Thread: Decoded - EvoHome API access to control remotely.

  1. #461
    Automated Home Lurker
    Join Date
    Dec 2016
    Posts
    2

    Talking DHW Scheduling Issue Resolved

    Eventually managed to get DHW scheduling to work using the following URL and JSON coding:

    URL:
    https://tccna.honeywell.com/WebAPI/e...otWater/zoneID

    JSON:
    { "DailySchedules": [ { "DayOfWeek": 0 ,"Switchpoints": } [
    [{"TimeOfDay" : "7:0:00","dhwState" : "On"},
    {"TimeOfDay" : "8:0:00","dhwState" : "Off"},
    ......
    ]]]}

    Happy days

  2. #462
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    146

    Default

    Quote Originally Posted by philchillbill View Post
    I've discovered an official Total Connect Comfort API that's actually targeted towards Evohome and not Honeywell Home. I didn't see it mentioned anywhere in posts here so it's likely new (the page I'm looking at is dated Sept 17, 2019). I accessed it via https://mytotalconnectcomfort.com/WebApi/Help/LogIn and took the first login option there which just needs an ApplicationID. I used 91db1612-73fd-4500-91b2-e63b069b185c and got in no problem. In particular, the docs around the oauth flow would indicate that some effort has been put into this. There's an Access Control List concept, for example. Maybe this is the new API that jzwack eluded to in 2017 before going AWOL?
    I was wrong in my earlier reply. This is in fact the older (v1) API but it depends on the application ID whether functions are accessible.

    Reason for me rechecking BTW is that Honeywell appears to have changed something to the API, at least for this particular Application ID. Session keep-alive no longer functions and I have a feeing that this may be related to a recent email in which they told me that there is an updated version of the phone app. By inserting this annoyance they appear to want to give people an extra push that they should update. The big question here is: does this mean that they will be invalidating this Application ID somewhere in the near future?

  3. #463
    Automated Home Jr Member philchillbill's Avatar
    Join Date
    Jan 2017
    Location
    Eindhoven, Holland
    Posts
    48

    Default

    Quote Originally Posted by gordonb3 View Post
    I was wrong in my earlier reply. This is in fact the older (v1) API but it depends on the application ID whether functions are accessible.

    Reason for me rechecking BTW is that Honeywell appears to have changed something to the API, at least for this particular Application ID. Session keep-alive no longer functions and I have a feeing that this may be related to a recent email in which they told me that there is an updated version of the phone app. By inserting this annoyance they appear to want to give people an extra push that they should update. The big question here is: does this mean that they will be invalidating this Application ID somewhere in the near future?
    Did anybody from this or the Domoticz community ever succeed in getting an official appID from Honeywell? Or are we still collectively relying on one packet-sniffed years ago?

  4. #464
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    146

    Default

    Quote Originally Posted by philchillbill View Post
    Did anybody from this or the Domoticz community ever succeed in getting an official appID from Honeywell? Or are we still collectively relying on one packet-sniffed years ago?
    Shamefully, no. Joe did set something up for me a few years back, but the contact that was supposed to get me the information didn't send it to me straight but uploaded it to some Microsoft drive that I was unable to connect to (probably because as a Linux user I did not have a Microsoft account and creating it afterwards doesn't grant you the access to what was shared with you earlier).

    Should also note that the offered Application ID would have been for the v2 API only. This is sufficient for Domoticz to monitor and control your installation. The v1 API is only used to (optionally) retrieve a better temperature resolution than the 0.5 degrees C from the v2 API.

  5. #465
    Automated Home Jr Member philchillbill's Avatar
    Join Date
    Jan 2017
    Location
    Eindhoven, Holland
    Posts
    48

    Default

    Quote Originally Posted by gordonb3 View Post
    Shamefully, no. Joe did set something up for me a few years back, but the contact that was supposed to get me the information didn't send it to me straight but uploaded it to some Microsoft drive that I was unable to connect to (probably because as a Linux user I did not have a Microsoft account and creating it afterwards doesn't grant you the access to what was shared with you earlier).

    Should also note that the offered Application ID would have been for the v2 API only. This is sufficient for Domoticz to monitor and control your installation. The v1 API is only used to (optionally) retrieve a better temperature resolution than the 0.5 degrees C from the v2 API.
    I think v2 is better anyway because it also supports schedule editing whereas v1 does not (IIRC). When you say that session keep-alive is no longer working, do you mean that the oauth tokens are immediately invalidated after use and that a full re-logon is required, or what exactly do you mean? I just tried about 10 quick successive API accesses for zone data as a test, and all re-used the token successfully. I'm actually working on a very extended Evohome Alexa skill that will support scenes, multiple schedules by name (summer/winter/days/nights) and editing schedule by voice. I'd really hate if the appID was pulled...

  6. #466
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    146

    Default

    v1 API does not use oauth.

  7. #467
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,851

    Default

    Quote Originally Posted by gordonb3 View Post
    I was wrong in my earlier reply. This is in fact the older (v1) API but it depends on the application ID whether functions are accessible.

    Reason for me rechecking BTW is that Honeywell appears to have changed something to the API, at least for this particular Application ID. Session keep-alive no longer functions and I have a feeing that this may be related to a recent email in which they told me that there is an updated version of the phone app. By inserting this annoyance they appear to want to give people an extra push that they should update. The big question here is: does this mean that they will be invalidating this Application ID somewhere in the near future?
    The phone app does not use the V1 API and hasn't for a long time, so I don't quite follow the reasoning that a change to the V1 API would be related to an update to the app.

    Also, I've just checked my python client for the V1 API which has support for saving and reusing session state without reauthenticating and it is still definitely working.

    I can perform a query which goes through a full authentication and saves the session state, then deliberately fudge the password and run it again and it retreives valid results - this proves that the second poll used the saved session state and did not rely on using the password.

    It's possible that the amount of time the session remains valid (previously 15 minutes) has changed - my client does not have any hard coded delay, if it has a saved session it always tries to use it and if it fails it then falls back to full username and password authentication automatically and saves the newly aquired session state.

    In my application I call the API every 5 minutes and that seems to be frequently enough that it can perpetually use the saved session and almost never reauthenticate.
    Last edited by DBMandrake; 14th December 2019 at 11:15 PM.

  8. #468
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    146

    Default

    v1 API never had something like a "session state". As long as you kept polling the API within the assigned ID's expiration time the server would reset the timer. As such, from the client side it was static and did not require any special actions to keep the session alive. I'm unsure when it changed, I don't really watch the system every minute or even every day, but currently the session is ended after 15 minutes from when it was started, regardless of how recent the last call you made has been.

    Edit: renewal of v1 sessions started failing last Thursday (12/12) around 8:19 CET (the session was ended by 8:35).
    Last edited by gordonb3; Yesterday at 10:11 AM.

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
  •