Evohome app broken

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Tigerruss
    Automated Home Lurker
    • Feb 2017
    • 2

    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.


    Originally posted by peterf View Post
    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.

    Comment

    • Cchris
      Automated Home Sr Member
      • Nov 2015
      • 95

      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.

      Comment

      • gordonb3
        Automated Home Ninja
        • Dec 2016
        • 273

        Originally posted by peterf View Post
        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.

        Comment

        • DBMandrake
          Automated Home Legend
          • Sep 2014
          • 2361

          Originally posted by gordonb3 View Post
          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.
          Last edited by DBMandrake; 5 February 2019, 11:27 PM.

          Comment

          • gordonb3
            Automated Home Ninja
            • Dec 2016
            • 273

            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.

            Comment

            • FullBore
              Automated Home Guru
              • Jan 2016
              • 140

              Resideo admits that its cloud infrastructure fails to keep up !

              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

              Comment

              • DBMandrake
                Automated Home Legend
                • Sep 2014
                • 2361

                Originally posted by gordonb3 View Post
                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.
                Last edited by DBMandrake; 6 February 2019, 12:09 PM.

                Comment

                • gordonb3
                  Automated Home Ninja
                  • Dec 2016
                  • 273

                  Originally posted by DBMandrake View Post
                  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.
                  Last edited by gordonb3; 6 February 2019, 11:11 PM.

                  Comment

                  • peterf
                    Automated Home Guru
                    • Jan 2015
                    • 116

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

                    Perhaps their upgrade is bearing fruit.

                    Comment

                    • G4RHL
                      Automated Home Legend
                      • Jan 2015
                      • 1580

                      Originally posted by peterf View Post
                      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.

                      Comment

                      • DBMandrake
                        Automated Home Legend
                        • Sep 2014
                        • 2361

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

                        Comment

                        • DBMandrake
                          Automated Home Legend
                          • Sep 2014
                          • 2361

                          Originally posted by gordonb3 View Post
                          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.

                          Comment

                          • gordonb3
                            Automated Home Ninja
                            • Dec 2016
                            • 273

                            Originally posted by DBMandrake View Post
                            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.

                            Comment

                            • DBMandrake
                              Automated Home Legend
                              • Sep 2014
                              • 2361

                              Originally posted by gordonb3 View Post
                              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)

                              Comment

                              • gordonb3
                                Automated Home Ninja
                                • Dec 2016
                                • 273

                                Originally posted by DBMandrake View Post
                                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.

                                Comment

                                Working...
                                X