Reply With QuoteCan you divulge the source of your new API key? Is Resideo issuing them to developers (again)?
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 0°C 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
Can you divulge the source of your new API key? Is Resideo issuing them to developers (again)?
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.
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...
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.Originally Posted by philchillbill
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"
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.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...
Last edited by gordonb3; 9th December 2020 at 10:07 AM.
Nobody have DHW?
I do. I even graph the hot water temperature via the V1 API.
You're just teasing me now, aren't you?
@gordonb3 PM me your email address - I believe can give you access to my test bed via TCC website.
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