Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Tiny info request - Evohome web client

  1. #1
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    201

    Default Tiny info request - Evohome web client

    Having switched to a newer API key I found several json field names and value types/formats to have been altered and needed adjusting in my evohomeclient code. Just last week I discovered I missed at least one as a cancel override returned 0C as the current setpoint (for which the front-end references the schedule because the update in the web portal is not instant). As my own installation does not contain a DHW device I am unable to verify what changes might have occurred to that particular device, particularly the schedule info.

    I'd appreciate it very much if somebody could supply me (partial) schedule info of his/her DHW device, using either watchforstock's python library or the schedule backup/restore demo app from my C++ implementation at https://github.com/gordonb3/evohomeclient

  2. #2
    Automated Home Sr Member philchillbill's Avatar
    Join Date
    Jan 2017
    Location
    Eindhoven, Holland
    Posts
    95

    Default

    Can you divulge the source of your new API key? Is Resideo issuing them to developers (again)?

  3. #3
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    201

    Default

    Not that new. I simply did not follow the API key change when Joe submitted it to Andrew's code. Noting an increasing number of reports from Domoticz users not being able to connect and this apparently being caused by the old API key it was time to make some changes. The trouble is that there is no real documentation on the API, so you sort of have to discover it all yourself.

  4. #4
    Automated Home Sr Member philchillbill's Avatar
    Join Date
    Jan 2017
    Location
    Eindhoven, Holland
    Posts
    95

    Default

    Interesting that the parameter naming in the JSON as returned would depend on the API key used. One would expect that the parameter values rather than the parameter names might be what's different. But hey, it's Resideo so anything's possible.

    It's so short-sighted of them not to publish details of an API that they already have, even if only under NDA to developers. One of the reasons that Logitech Media Server refuses to die in the face of competitors like Sonos is that Sonos is a closed system with no API while LMS is totally open. The hobbyist/maker community could do a lot of free development work for Resideo if they would only embrace more openness...

  5. #5
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    201

    Default

    Quote Originally Posted by philchillbill View Post
    Interesting that the parameter naming in the JSON as returned would depend on the API key used. One would expect that the parameter values rather than the parameter names might be what's different. But hey, it's Resideo so anything's possible.
    My understanding is that the API key defines what is and what is not allowed. For instance, in the original generic API the key does not allow you access to any of the calls that are specific to the Honeywell security products and in fact earlier this year they stripped the right to renew the key, so now you have to send your credentials again every 15 minutes.

    But yes, in most cases the difference between the older `v2` API key and the replacement key is in the presentation of boolean values, going from 0/1 to false/true but in the case of DHW needs to be off/on. Regarding schedules, with the old API key I had to change the field name "temperature" from requesting a schedule to "TargetTemperature" (case-sensitive) when setting a schedule. With the replacement key this is now "heatSetpoint" and appears to be so for both directions. What I don't know is whether the setpoint for DHW, which used to be "dhwState", is also renamed.

    Edit: No, that's not true. My existing code still translates the field names to become caps-first, so for sending it is "HeatSetpoint"

    It's so short-sighted of them not to publish details of an API that they already have, even if only under NDA to developers. One of the reasons that Logitech Media Server refuses to die in the face of competitors like Sonos is that Sonos is a closed system with no API while LMS is totally open. The hobbyist/maker community could do a lot of free development work for Resideo if they would only embrace more openness...
    I think what helps here is that Logitech didn't actually create the protocol themselves and originally they didn't even label it with their own brand as the main hub went from SLIM server (possibly an open-source project) to Squeezebox server and only then became LMS just two years before they launched their own `UE` protocol that died shortly after.
    Last edited by gordonb3; 9th December 2020 at 10:07 AM.

  6. #6
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    201

    Default

    Nobody have DHW?

  7. #7
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,303

    Default

    Quote Originally Posted by gordonb3 View Post
    Nobody have DHW?
    I do. I even graph the hot water temperature via the V1 API.

  8. #8
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    201

    Default

    You're just teasing me now, aren't you?

  9. #9
    Automated Home Sr Member
    Join Date
    Jan 2018
    Posts
    69

    Default

    @gordonb3 PM me your email address - I believe can give you access to my test bed via TCC website.

  10. #10
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,303

    Default

    Quote Originally Posted by gordonb3 View Post
    You're just teasing me now, aren't you?
    No ?

    I use the evohome-munin plugin to graph my zones and hot water:

    https://github.com/Infern1/evohome-munin

    It uses the V1 API via Watchforstock's python client bindings, although I have test scripts that use the V2 API as well.

    It graphs measured hot water temperature, however as hot water set point is not available in the API it uses the hot water on/off state with a pre-set hot water set point in the script for the purposes of graphing the set point.

    Is there something you want tested ?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •