Evohome app broken

[G4RHL]

Count me in too, got a "communication with the system has been lost" error in the app, but controller responds to Alexa just fine.

I don't think I've ever known a system with quite so many bugs and flaws.

Had it a couple of years or so now and I'm contemplating writing it off as a failed experiment and looking for something else as this is just pathetically unreliable at the moment.

A geek can live with it, but when it starts to become a problem for she who must be obeyed, then the tech is on borrowed time.

After a little over 4 years of use I don’t have an issue with Evohome. Whilst I criticise the design of the app and that it should look better, have more functions and all should work with HomeKit, it does all work and I do not experience “so many bugs and flaws”. The only issue I have is if the server goes off line for maintenance, but that happens with other apps and systems from time to time. They all do it. This time Honeywell are spending a few weeks doing it intermittently. The lady of the manor knows how to operate the system - just. “Just” because I think the Control Panel and app need to be more user friendly and easier to use. Plus it is a must that we are able to see all control apps we use in one place - one day! But bugs, only rarely. I have no hesitation in recommending the system to other potential users.

[Cchris]

Ive got three controllers in the house. All connected to the same wifi, all with a status of connected.

I can set the heat via alexa to any room on any of the controllers. This tells me that the servers must be up and running to some degree, and that they can communicate with my controllers via the wifi.

Alex takes command > communicates with honeywell > honeywell communicates with controller > controller comunicates with valves.


Open the app and when I select controller 1 or 2 it works fine. Select controller 3 and I get the "Communication with the system has been lost" - even though the system must be in communication with Honeywell for it to accept changes from Alexa. Same result from different phones running the app.

Its a Honeywell fault, and its appeared since they d*cked around with stuff yet again.

[DerekWilliamsUK]

Even 'The Register' website cannot get a reply from Honeywell/Residio re continued service disruption:

https://www.theregister.co.uk/2019/0..._service_down/

[peterf]

Yep, I agree. Don't forget 99% up-time is still down over three days a year

Also, I have more confidence that Honeywell, or at least the brand, will be around a bit longer than some of the other start-up firms.

I think it's just a shame about the communication but I don't think that Honeywell have decided whether Evohome is an end-user product or one for the installation market and that's compromised their communication strategy.

After a little over 4 years of use I don’t have an issue with Evohome. Whilst I criticise the design of the app and that it should look better, have more functions and all should work with HomeKit, it does all work and I do not experience “so many bugs and flaws”. The only issue I have is if the server goes off line for maintenance, but that happens with other apps and systems from time to time. They all do it. This time Honeywell are spending a few weeks doing it intermittently. The lady of the manor knows how to operate the system - just. “Just” because I think the Control Panel and app need to be more user friendly and easier to use. Plus it is a must that we are able to see all control apps we use in one place - one day! But bugs, only rarely. I have no hesitation in recommending the system to other potential users.

[Tigerruss]

Just got an email confirming connection has been restored. - Hope it stays that way and that it was all done to give us the features, functionality and integration we demand.

Yep, I agree. Don't forget 99% up-time is still down over three days a year

Also, I have more confidence that Honeywell, or at least the brand, will be around a bit longer than some of the other start-up firms.

I think it's just a shame about the communication but I don't think that Honeywell have decided whether Evohome is an end-user product or one for the installation market and that's compromised their communication strategy.

[Tigerruss]

Just got an email confirming connection has been restored. - Just hope it stays that way and that the massive downtime was all done to give us the features, functionality and integration we deserve.

Yep, I agree. Don't forget 99% up-time is still down over three days a year

Also, I have more confidence that Honeywell, or at least the brand, will be around a bit longer than some of the other start-up firms.

I think it's just a shame about the communication but I don't think that Honeywell have decided whether Evohome is an end-user product or one for the installation market and that's compromised their communication strategy.

[Cchris]

No such joy here, still got communication with the system lost error on one controller, but working fine with the other two. Yet I can still set that controller via Alexa.... So clearly theres a problem with the App connection somewhere at Honeywells end.

[gordonb3]

I don't really subscribe to the hacking theory. They're hardly likely to release an email saying effectively that "we're going to be a hacking target from next week and it's going to last for a month".

That's not what I said, nor is what I meant to say.

The thing here is that we do not all use the official app only to connect to the portal. People have been using (python) scripts to pull data into and send commands from home automation systems. About a month or two ago people starting raising issues that these scripts were suddenly showing errors and it was soon suspected that the portal was apparently actively blocking connection attempts. This turned out to be fact, Honeywell did really add a limit to their login method. They *are* building walls.

[DBMandrake]

The thing here is that we do not all use the official app only to connect to the portal. People have been using (python) scripts to pull data into and send commands from home automation systems. About a month or two ago people starting raising issues that these scripts were suddenly showing errors and it was soon suspected that the portal was apparently actively blocking connection attempts. This turned out to be fact, Honeywell did really add a limit to their login method. They *are* building walls.

I've had to do a partial rewrite of the evohome-munin python scripts that I use to attempt to work around the rate limiting that seems to be in place, along with the unreliability of the servers.

With the munin plugin architecture each zone is called as a separate script instance so to avoid polling the servers once for each zone it implements local caching so only the first instance in each 5 minute polling period actually polls the servers and the other zones all query the local cache.

However there was a design flaw in the script such that if the connection failed the cache would not be updated, meaning the following zone would then attempt to poll the servers, and if that failed the one after that would etc...multiplied by the number of zones in the system... (9 for me counting hot water) the result being that if the servers did not give a favourable response a few times the repeated per zone attempts which weren't being cached would hit the new rate limits.

And once the rate limit was hit all requests would fail, causing 9 attempts per 5 minute cycle to be attempted which kept my system semi-permanently locked out by rate limiting.

So I've rewritten the script to avoid repeatedly polling the servers after a failed connection due to invalidated cache. This improved the situation and I started seeing a more solid graph, but I noticed that even when the rate limit is not being hit I see intermittent failures from the server where a retry 10-20 seconds later sometimes succeeds.

So I then further modified it so that in each 5 minute period it will try once - if it fails, it will wait 20 seconds and try a second time, if it fails after that it will wait the full 5 minutes before any further attempts to avoid rate limiting. This improved things further however I am still seeing both small (5 minute period) and large (hours) gaps in my graphs where two queries in a row 20 seconds apart both fail and after hours of work and experimentation with the script I can't get it to work any better.

From what I can see it takes about 6 API queries in a row in a "short" period of time (5 minutes I think) to trigger rate limiting, however even if you try only once or twice every 5 minutes there is still a relatively high random failure rate seemingly unrelated to rate limiting.

I really hope these server problems are resolved soon, my temperature graphs have looked like swiss cheese for weeks if not months now when they used to be perfect.

[gordonb3]

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.