Evohome app broken

[FullBore]

The Register article referred to by DerekWilliamsUK now has an update:-

Updated to add:-

A spokesperson for Resideo has been in touch to say its cloud infrastructure couldn't keep up with its customers' devices:

Some of our customers that have attempted to control their thermostats via our app have experienced periodic connectivity issues with their connected thermostats recently. Strong growth in our connected thermostats is one cause, which has increased the load on our cloud infrastructure. We’re in the process of implementing upgraded infrastructure across our connected products to ensure reliability due to greater demand, and mitigating issues with our existing infrastructure.

We notified our customers by email and social media that they may experience brief, intermittent connectivity through February as we implement new systems.

In our communications, we reassured customers that during these brief, intermittent outages, the thermostats would perform as intended locally, control the heating and cooling equipment correctly, and follow any schedules the homeowner has created. We recognize that many customers purchased these thermostats to control them remotely, and not being able to for a short time is an inconvenience.

We sincerely apologize for any inconveniences the outages have caused in the interim.

Surely if one's cloud infrastructure can't keep up this indicates more users than anticipated, thus more revenue & profits, some of which should have been utilised in enhancing the cloud infrastructure - before it failed.

FB

[DBMandrake]

You need to store and re-use the auth key between your script runs.

For v1 API: the session key will stay valid if you do at least one call every 12 minutes.

For v2 API: the session will stay alive for exactly 1 hour after which you must renew it. On login you receive two auth tokens, one to use for querying and submitting commands, the other one to recreate your session after it expired. Using that second auth key has a better rate of success than resending your credentials.

Can't do that unfortunately.

watchforstock's python bindings don't support any storing of session keys between different script instances. I've tried to contact him a while ago to see if it is possible for something like that to be added but I haven't had any response so I'm assuming that the evohome-client bindings are unmaintained at the moment or he's too busy to look into it.

So I'm kinda stuck. Used to work perfectly for me for a couple of years, now it doesn't. BTW, "better rate of success than resending your credentials" shows just how unreliable these servers are...! A server should just work, it shouldn't have a "success rate", and that is at the root of the problems. (Load balanced server farm with one or two duff servers ?) The authentication mechanism should be 100% reliable - caching the session key is only a workaround for an unreliable authentication system IMO.

[gordonb3]

Can't do that unfortunately.

watchforstock's python bindings don't support any storing of session keys between different script instances. I've tried to contact him a while ago to see if it is possible for something like that to be added but I haven't had any response so I'm assuming that the evohome-client bindings are unmaintained at the moment or he's too busy to look into it.

So I'm kinda stuck. Used to work perfectly for me for a couple of years, now it doesn't. BTW, "better rate of success than resending your credentials" shows just how unreliable these servers are...! A server should just work, it shouldn't have a "success rate", and that is at the root of the problems. (Load balanced server farm with one or two duff servers ?) The authentication mechanism should be 100% reliable - caching the session key is only a workaround for an unreliable authentication system IMO.

I'd say it should be possible to query the key value and save it to a file and then on re-entry skip the login and fetch the key from the file instead. An alternative could be to break up the script in two parts and run one of them as a service that the other half can query. watchforstock's library does in fact not store and support the token refresh API call, but it's not that big a deal to add it. You can copy it from my C++ port of the library.

[peterf]

The app appears to be running much faster for me this morning. Both heating and security side.

Perhaps their upgrade is bearing fruit.

[G4RHL]

The app appears to be running much faster for me this morning. Both heating and security side.

Perhaps their upgrade is bearing fruit.

I have noticed any difference in opening and running the heating part of the app but logging in to the security seemed quicker.

[DBMandrake]

App seems to be working OK for me recently but I still have small random gaps in my graphs.

[DBMandrake]

I'd say it should be possible to query the key value and save it to a file and then on re-entry skip the login and fetch the key from the file instead. An alternative could be to break up the script in two parts and run one of them as a service that the other half can query. watchforstock's library does in fact not store and support the token refresh API call, but it's not that big a deal to add it. You can copy it from my C++ port of the library.

While I'm reasonably OK with my own python code, I'm afraid my python skills are not up to the task of modifying watchforstock's library in any substantive way. I've had a look through it before and got a bit lost to be honest, so wouldn't know where or how to implement caching.

Ideally it would automatically cache the API key to disk based on matching username and password. This could be done completely transparently from the point of view of the calling python script. So after logging in successfully hash the username and password together and store that hash with the API key and a last used date on disk. Next time it tries to log in it can hash the username and password and see if it is already recently cached, if so use the API key. If it's found but expired delete it from the cache and log in again. If not found at all just log in again then cache again.

[gordonb3]

While I'm reasonably OK with my own python code, I'm afraid my python skills are not up to the task of modifying watchforstock's library in any substantive way. I've had a look through it before and got a bit lost to be honest, so wouldn't know where or how to implement caching.

Ideally it would automatically cache the API key to disk based on matching username and password. This could be done completely transparently from the point of view of the calling python script. So after logging in successfully hash the username and password together and store that hash with the API key and a last used date on disk. Next time it tries to log in it can hash the username and password and see if it is already recently cached, if so use the API key. If it's found but expired delete it from the cache and log in again. If not found at all just log in again then cache again.

Not too big on python myself and I also hate the fact that running watchforstock's library takes 40-50 seconds to load and execute on the embedded system I use. But as far as I can see python does not appear to have a mechanism for privatizing variables, so you should be able to dump the API key to screen using `print client.access_token` (and its expiration time `client.access_token_expires`).

The only real problem here is that the client init procedure automatically calls the _login method. You need to delete that line in the library and then let your script decide whether to inject the API key from local storage or run the usual login procedure.

[DBMandrake]

Not too big on python myself and I also hate the fact that running watchforstock's library takes 40-50 seconds to load and execute on the embedded system I use.

Good grief, what sort of embedded system is that ?

I run mine on an original single core 2013 Raspberry Pi 1 which is not exactly the fastest thing, and it only takes about 5 seconds to go through the entire login process and return all zone temperatures. Given how slowly a Raspberry Pi 1 runs python code in general I think that's pretty reasonable.

But as far as I can see python does not appear to have a mechanism for privatizing variables, so you should be able to dump the API key to screen using `print client.access_token` (and its expiration time `client.access_token_expires`).

The only real problem here is that the client init procedure automatically calls the _login method. You need to delete that line in the library and then let your script decide whether to inject the API key from local storage or run the usual login procedure.

How applicable is what you suggest to both the V1 and V2 API's ? I actually use both API's, and they each have separate implementations in the library.

All zone temperatures are retrieved using the V1 API for increased resolution, but I also have to call on the V2 API to get the hot water on/off status. (Which is a bit of a pain to be honest, but as far as I can see the V1 API can't report this)

[gordonb3]

Good grief, what sort of embedded system is that ?

I run mine on an original single core 2013 Raspberry Pi 1 which is not exactly the fastest thing, and it only takes about 5 seconds to go through the entire login process and return all zone temperatures. Given how slowly a Raspberry Pi 1 runs python code in general I think that's pretty reasonable.

How applicable is what you suggest to both the V1 and V2 API's ? I actually use both API's, and they each have separate implementations in the library.

All zone temperatures are retrieved using the V1 API for increased resolution, but I also have to call on the V2 API to get the hot water on/off status. (Which is a bit of a pain to be honest, but as far as I can see the V1 API can't report this)

armv5te - and it's really just python misbehaving like that.

Previous entry should apply to both APIs. In both cases the library requires you to supply your credentials on creation of the client object and neither one needs a separate call to the login procedure. Both login procedures return a token that must be sent with every subsequent call and is thus stored within the client object, so between runs you can save and restore that token rather than request a new one by logging in again.