Alexa and Evohome

[philchillbill]

Just a note, the Web API method in Domoticz is near to being broken and as I've given up supporting the Domoticz port of my (old version) library it's just a matter of time before it will completely seize.

Thanks for the heads-up. What is it about it that's nearly broken? Doesn't it just run the well-known TCC API calls under the hood?

[gordonb3]

Thanks for the heads-up. What is it about it that's nearly broken? Doesn't it just run the well-known TCC API calls under the hood?

Yep.

Currently broken is the higher temperature resolution which is due to Honeywell having changed some of the responses on v1 API and at the same time having stripped the applied API key of its right to keep a session alive - i.e. you need to login again after a certain amount of time and the current implementation in Domoticz fails to detect correctly that the session is no longer valid.

About to break is the EMEA aka v2 API which is again related to API key rights. There's a new key but you can't simply swap it because it uses translated fields for both output and input.

[DBMandrake]

Yep.
Currently broken is the higher temperature resolution which is due to Honeywell having changed some of the responses on v1 API

Are you sure ? I'm still receiving high resolution temperature readings using the V1 API with Evohome python bindings. I use it for my graphing.

About to break is the EMEA aka v2 API which is again related to API key rights. There's a new key but you can't simply swap it because it uses translated fields for both output and input.

Ergh... where did you find this out ? Do you know if watchforstock is aware of this to update the Python bindings when the time comes ? (Still seems to be working at the moment, although I don't actively use the V2 API as I don't use any control functionality that would benefit from it)

[philchillbill]

There's a new key but you can't simply swap it because it uses translated fields for both output and input.

Have you found this out by trial and error or did somebody at Resideo tip you off? Rather silly of them to break this with no likely reason other than to mess things up for the maker community. They benefit indirectly from the (free) development efforts of the open source community as it all goes towards making Evohome a more attractive product overall. Rather than hampering us they should be removing barriers...

[gordonb3]

Are you sure ? I'm still receiving high resolution temperature readings using the V1 API with Evohome python bindings. I use it for my graphing.

Yes, I'm sure. Session renewal right was stripped last December and I submitted a fix for that issue when the errors started popping up. Three months later they changed the HTTP return code on the explicit session renewal request and that causes the module to fail and keep trying to use the expired session ID. The fix to this never made it to Domoticz main line.

Ergh... where did you find this out ? Do you know if watchforstock is aware of this to update the Python bindings when the time comes ? (Still seems to be working at the moment, although I don't actively use the V2 API as I don't use any control functionality that would benefit from it)

The new API key is already in watchforstock's python binding. He got it from Joe Zwack who also submitted the necessary changes to correct for the renamed fields and values. As I was to receive my own API key I did not copy it at the time and kept using the one that watchforstock used before that time as well. I never did receive that key though and as communicating with the Domoticz project owner was already troublesome I decided to leave it as is because it actually works for most but somehow it is starting to block new users more frequently and consistently.

[gordonb3]

Have you found this out by trial and error or did somebody at Resideo tip you off? Rather silly of them to break this with no likely reason other than to mess things up for the maker community. They benefit indirectly from the (free) development efforts of the open source community as it all goes towards making Evohome a more attractive product overall. Rather than hampering us they should be removing barriers...

Neither, it's all in Joe Zwack's submit to the watchforstock evohomeclient project on GitHub. As Joe pointed out at the time they were not too happy about "sniffed" keys from their own apps being used in open source projects and I suspect that when they figure that no person could possibly still be using the apps from that time they will invalidate those keys completely. And yes that will impact watchforstock's client as well because they only gave him an API key for the EMEA (v2) client.

[DBMandrake]

Yes, I'm sure. Session renewal right was stripped last December and I submitted a fix for that issue when the errors started popping up. Three months later they changed the HTTP return code on the explicit session renewal request and that causes the module to fail and keep trying to use the expired session ID. The fix to this never made it to Domoticz main line.

You misunderstand - I know about the 15 minute reauthentication issue that's been there for quite a while now. watchforstock's V1 client deals with this gracefully so it's able to reuse the token twice with my 5 minute polling then reauthenticate seamlessly on the third attempt, and because I'm only authenticating once every 15 minutes I don't seem to hit any authentication rate limiting. (However I did when I still simultaneously had domoticz polling, so I ditched domoticz as I much prefer the graphs in my evohome-munin setup)

I was referring to the high resolution temperature measurements - I'm still receiving temperatures in high resolution on the V1 API while you were suggesting that was gone.

The new API key is already in watchforstock's python binding. He got it from Joe Zwack who also submitted the necessary changes to correct for the renamed fields and values. As I was to receive my own API key I did not copy it at the time and kept using the one that watchforstock used before that time as well. I never did receive that key though and as communicating with the Domoticz project owner was already troublesome I decided to leave it as is because it actually works for most but somehow it is starting to block new users more frequently and consistently.

Ahh ok. I thought this was a new change. I knew about the one a year or so ago that had been incorporated into watchforstock's evohomeclient2. What I didn't know was that this change has apparently not gone into domoticz. (I wouldn't have noticed as I don't use it anymore)

[gordonb3]

I was referring to the high resolution temperature measurements - I'm still receiving temperatures in high resolution on the V1 API while you were suggesting that was gone.

Well, the thing here of course is that Honeywell *did* strip the session renewal right from that API key and so I do think you should keep in mind that they may eventually invalidate it completely, as I stated earlier. A complicating factor in Domoticz was that the web access method it provides was configured to return absolutely nothing if a HTTP error occurred (for GET operations). In the December 2019 fix this was solved by using the explicit session renewal call that uses a PUT operation and that did return usable data for session validation.

I should also mention that I had this stored incorrectly in memory. The change from March 2020 does not result in the v1 session validation routine in Domoticz to always return True, it always returns False and as a result it does a new login at every poll and you do hit the rate limit that they installed I think in 2018 or so.

Ahh ok. I thought this was a new change. I knew about the one a year or so ago that had been incorporated into watchforstock's evohomeclient2. What I didn't know was that this change has apparently not gone into domoticz. (I wouldn't have noticed as I don't use it anymore)

You wouldn't have noticed it either way because it's all under the hood. In fact in Domoticz you can't even notice the difference between the Web API client and the HGI/RFBee based client. That was the whole purpose for writing this client.

[DBMandrake]

I think we're talking at cross purposes here. I don't use Domoticz. I was referring to the over the air API's only.

I was just trying to point out that the V1 API does still report high resolution temperatures through the evohomeclient library, because my own graphing solution does still record high res values.

Whether domoticz does or doesn't is none of my concern

[gordonb3]

I think we're talking at cross purposes here. I don't use Domoticz. I was referring to the over the air API's only.

I was just trying to point out that the V1 API does still report high resolution temperatures through the evohomeclient library, because my own graphing solution does still record high res values.

Whether domoticz does or doesn't is none of my concern

I get that. That wasn't the point though. On topic is Phil's Alexa bridge and the suggestion to use Domoticz as an intermediate to communicate with Evohome through any of the supported "hardware". My comment was about the integrated Web API method being unmaintained *and* showing issues due to changed policies on the Honeywell side.


@philchillbill:
I don't know what methods you'd like to implement in your Alexa bridge, what programming language you use and if you can already communicate with Domoticz, but I have a project named dzEvo on GitHub that allows specifying zone names rather than numeric IDs as well as alternate methods for specifying setpoint and `until` time. Maybe you could use (parts of) it to get a jump start.