Alexa and Evohome

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • gordonb3
    Automated Home Ninja
    • Dec 2016
    • 273

    #16
    Originally posted by philchillbill View Post
    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.
    Last edited by gordonb3; 20 September 2020, 07:51 PM.

    Comment

    • DBMandrake
      Automated Home Legend
      • Sep 2014
      • 2361

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

      Comment

      • gordonb3
        Automated Home Ninja
        • Dec 2016
        • 273

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


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

        Comment

        • DBMandrake
          Automated Home Legend
          • Sep 2014
          • 2361

          #19
          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

          Comment

          • gordonb3
            Automated Home Ninja
            • Dec 2016
            • 273

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

            Comment

            • philchillbill
              Automated Home Legend
              • Jan 2017
              • 591

              #21
              Originally posted by gordonb3
              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.
              Thanks for the offer, much appreciated. I already have two skills for Alexa running in my personal account for about 2 years now. One is a custom skill written in nodejs and using my own nodejs bindings to the TCC API. The other is a Smart Home skill written in Python that interfaces with Domoticz through JSON calls and controls my Evohome setup through the HGI-80 integration in Domoticz. I wrote those Python bindings myself as they talk to Domoticz and not TCC.

              I originally planned on releasing the custom one as it allows changing and querying schedules by voice and supports scenes. However, the lack of my own API key from Resideo to date has stopped me as I'm not investing more time into a dead end. Also, the 'worry' that a spoken command might not make it to the TCC cloud because of some token or comms glitch always looms and a skill only has 8 sec by definition to do its thing and die, so there's no hanging around to retry. Downside of custom skills is also that the whole voice model has to be handcrafted so it would have been en-US and en-GB only.

              The advantage of having Domoticz in the loop is that there is a command buffer between Alexa and TCC as it were. Domoticz can do the TCC comms retrying if need be. When I originally did the Smart Home skill via Domoticz the potential commands were more limited compared to my custom skill (but still MUCH better than the Resideo skill) but some time back Amazon introduced the Toggle, Mode and Range Controller Interfaces and they are actually quite versatile so I've added per-zone mode controls and also scenes. With the advantage that Smart Home skills support any spoken language that I write up an Amazon store-description for (which is a *lot* less work than translating a voice model).

              I already have a live account-linking oauth flow that I wrote myself for my 2 published skills MediaServer and LMS-lite (for Logitech Media Server) so that concept can be hijacked for an Evohome skill too. By targeting the Domoticz interface to Evohome I avoid TCC altogether when a HGI-80 or one of the homebrew RF equivalents is used. That's a smaller user base but at least it removes depending on the whims of Resideo. I'll put it together in the next few weeks and then ask here for a few beta testers.

              Cheers again!

              Comment

              • gordonb3
                Automated Home Ninja
                • Dec 2016
                • 273

                #22
                That was kind of why I wrote dzEvo. Originally I had something offering the same functions directly targetting TCC but as they introduced the login limits I found that my commands started to be (partially) rejected and the better idea was to run the commands through Domoticz as that used a continuous session. As I have part of my infrastructure running on low power CPU I try to avoid using programming languages that implement runtime interpretation, especially python that generates a ridiculous amount of overhead (e.g. watchforstock's implementation adds 40+ seconds to my own C++ based ELF binary running on my 24/7 system).

                Either way, out of the added functions in dzEvo there's one that I use practically every day during Winter:
                set temperature Collin to 20 degrees for 15 minutes

                This creates a cozy temperature in my son's bedroom at bed time and once he's tucked in it's okay for the temperature to drop again to as low as the set default of 15C that rarely requires the heater to turn on in this house. If you haven't implemented such a thing, I'd definitely give it a thought.

                Comment

                • philchillbill
                  Automated Home Legend
                  • Jan 2017
                  • 591

                  #23
                  Originally posted by gordonb3 View Post
                  That was kind of why I wrote dzEvo. Originally I had something offering the same functions directly targetting TCC but as they introduced the login limits I found that my commands started to be (partially) rejected and the better idea was to run the commands through Domoticz as that used a continuous session. As I have part of my infrastructure running on low power CPU I try to avoid using programming languages that implement runtime interpretation, especially python that generates a ridiculous amount of overhead (e.g. watchforstock's implementation adds 40+ seconds to my own C++ based ELF binary running on my 24/7 system).

                  Either way, out of the added functions in dzEvo there's one that I use practically every day during Winter:
                  set temperature Collin to 20 degrees for 15 minutes

                  This creates a cozy temperature in my son's bedroom at bed time and once he's tucked in it's okay for the temperature to drop again to as low as the set default of 15C that rarely requires the heater to turn on in this house. If you haven't implemented such a thing, I'd definitely give it a thought.
                  I use nodejs and Python because Alexa skills use Amazon's Lambda compute environment and all the example code snippets are for those 2 languages. Plus, Lambda has resources aplenty.

                  Implementing timed overrides was the reason I decided to write my own skill in the first place. The European version of the Resideo TCC skill does not support this (see the first post in this thread) while the Alexa.ThermostatController Interface does have the voice model for it so it was a no-brainer to implement. And as you point out, a hugely useful function. That a product manager at Resideo could skip specifying this when both Alexa and Evohome have the base capability is beyond me. It's what happens in big corporations when somebody with no actual affiliation with the end-product is put in charge. Sigh.

                  A feature I also find very useful is a link to Google Calendar. My better half has a Pilates Studio at home. If any entries in her calendar start with 'Client:' then the Studio is automatically set to be at 22 deg at that time. I have a cron job running that polls her calendar and continually edits the TCC schedule for that zone based on what it finds. This also overcomes the max 6 switchpoints per zone per day that Resideo limit us to.

                  @DanD figured out a while back how to modify schedules via the HGI-80 and he kindly sent me a script a while back to do this without having to use TCC at all. But I find it sometimes conflicts with Domoticz accessing the HGI-80 so it's a big pity this code never made its way into Domoticz itself.

                  Comment

                  • gordonb3
                    Automated Home Ninja
                    • Dec 2016
                    • 273

                    #24
                    See? Good ideas rarely pop up in just one mind.

                    Shame about Amazon focussing on those 2 languages. In my experience the only interpreted language that works decent on every platform is Perl.

                    Comment

                    • bruce_miranda
                      Automated Home Legend
                      • Jul 2014
                      • 2307

                      #25
                      Originally posted by philchillbill View Post
                      @DanD figured out a while back how to modify schedules via the HGI-80 and he kindly sent me a script a while back to do this without having to use TCC at all. But I find it sometimes conflicts with Domoticz accessing the HGI-80 so it's a big pity this code never made its way into Domoticz itself.
                      Both Dan and I couldn't work out how to integrate the schedule features of the HGI-80 with the rigid code base structure of Domoticz. So we just abandoned the idea. Javascript wasn't either of our strength.

                      Comment

                      • gordonb3
                        Automated Home Ninja
                        • Dec 2016
                        • 273

                        #26
                        Originally posted by bruce_miranda View Post
                        Both Dan and I couldn't work out how to integrate the schedule features of the HGI-80 with the rigid code base structure of Domoticz. So we just abandoned the idea. Javascript wasn't either of our strength.
                        Same applies to the integrated Web API method. The code to manipulate schedules is all in there but there is no user interface that targets it and neither has the API been extended to allow this through some other front-end. The Web API method does use the schedules however to provide direct feedback on (cancellations of) overrides and preload `until` times to the next switch point. I think Dan commented on finding that a useful feature, didn't he implement it for the HGI80?

                        Comment

                        • philchillbill
                          Automated Home Legend
                          • Jan 2017
                          • 591

                          #27
                          Originally posted by bruce_miranda View Post
                          Both Dan and I couldn't work out how to integrate the schedule features of the HGI-80 with the rigid code base structure of Domoticz. So we just abandoned the idea. Javascript wasn't either of our strength.
                          I wonder if it would be possible to support schedule save/retrieve at least via the JSON API if not graphically? Or are the GUI and JSON in Domoticz too interwoven? I have it the other way around, unfortunately - strong with JS but not with CPP.

                          Comment

                          • philchillbill
                            Automated Home Legend
                            • Jan 2017
                            • 591

                            #28
                            By the way, Amazon announced a boatload of new smart home features for Alexa yesterday. In this blog https://developer.amazon.com/en-US/b...ome-with-Alexa the name Resideo is mentioned several times as working on integrating the new features. But, it's the Home stuff and not TCC so it will happen for Lyric and such and not for Evohome is my guess. Sigh.

                            Comment

                            • gordonb3
                              Automated Home Ninja
                              • Dec 2016
                              • 273

                              #29
                              Originally posted by philchillbill View Post
                              I wonder if it would be possible to support schedule save/retrieve at least via the JSON API if not graphically? Or are the GUI and JSON in Domoticz too interwoven? I have it the other way around, unfortunately - strong with JS but not with CPP.
                              In theory, yes. The so-called JSON API in Domoticz is in fact not JSON at all, it just returns JSON in response to a string of URI GET parameters. Trying to pass complex data like a JSON string as a parameter value will prove to be very ugly. And of course you need to convince the Domoticz project owner that such a feature is desirable. One of the most feasible options that I came up myself is to let the Evohome worker thread itself inspect a queue directory for uploads of such more complex inputs. Never implemented it though as I get by just fine with normal overrides and on the rare occasions that I do want to update schedules I just use my own backup-restore app for that.

                              Comment

                              • philchillbill
                                Automated Home Legend
                                • Jan 2017
                                • 591

                                #30
                                Originally posted by gordonb3
                                In theory, yes. The so-called JSON API in Domoticz is in fact not JSON at all, it just returns JSON in response to a string of URI GET parameters. Trying to pass complex data like a JSON string as a parameter value will prove to be very ugly. And of course you need to convince the Domoticz project owner that such a feature is desirable. One of the most feasible options that I came up myself is to let the Evohome worker thread itself inspect a queue directory for uploads of such more complex inputs. Never implemented it though as I get by just fine with normal overrides and on the rare occasions that I do want to update schedules I just use my own backup-restore app for that.
                                Where I would envisage using it is with schedule pull-forward or delay. For example, "Alexa, delay bedtime by 30 mins" would move all the scheduled switchpoints to a later time if e.g. I wanted to stay up to finish a movie. Similarly, "Alexa, early start tomorrow by 45 mins" would be useful if I need to go somewhere early in the morning. I like the idea of having a simple/compact Alexa command do things that otherwise need several steps if using the Evotouch or the phone App (or even Domoticz).

                                Comment

                                Working...
                                X