Decoded - EvoHome API access to control remotely.

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

    Originally posted by RichardP View Post
    @gordonb3, would it be possible to add a method to get the dhw schedule to Evohomeclient?

    Currently the schedule is saved together with the zone info, so you can't save the dhw schedule within Evohomeclient. Probably the easiest way would be for each temperaturecontrolsystem to have a dhw zone member, this member could then store the dhw id and zone schedule etc.. The current get_zone_by_ID method would then also have to look through each dhw to see if that contained the zone id that was being requested.
    Okay. I think I got it.
    • get_zone_by_ID() can now also be used to locate DHW by ID

    • DHW is now a zone() object that can be accessed through *tcs->dhw[0]

    • I've replaced all map<int, T> occurrences in the code to vector<T>
      If you used any map iterators like this:
      Code:
      for (std::map<int, EvohomeClient::zone>::iterator it=*tcs->zones.begin(); it!=*tcs->zones.end(); ++it)
          A = it->first
          B = it->second
      you should rewrite them to become
      Code:
      for (std::vector<EvohomeClient::zone>::size_type i = 0; i < *tcs->zones.size(); ++i)
          A = i
          B = tcs->zones[i]

    Comment

    • RichardP
      Automated Home Jr Member
      • Jun 2017
      • 48

      @gordonb3 - Excellent, works a treat!

      Comment

      • RichardP
        Automated Home Jr Member
        • Jun 2017
        • 48

        I'm noticing a slightly annoying difference between the newer WiFi controller I have and the two older non WiFi versions.

        With the newer version, although the terminating character on an override date/time string is Z, the time is actually local time.

        With the older version, the terminating character is still a Z, but the time is UTC.

        Apart from using the location names, there appears to be nothing to distinguish the controller type at a location in a generic way. There are various parameters in the location information that you'd hope would show the difference, but they don't!

        Location data from the older controller :

        Code:
            "locationInfo": {
              "locationId": "xxx",
              "name": "Ground Floor",
              "streetAddress": "xxx",
              "city": "xxx",
              "country": "UnitedKingdom",
              "postcode": "xxx",
              "locationType": "Residential",
              "useDaylightSaveSwitching": true,
              "timeZone": {
                "timeZoneId": "GMTStandardTime",
                "displayName": "(UTC) Dublin, Edinburgh, Lisbon, London",
                "offsetMinutes": 0,
                "currentOffsetMinutes": 60,
                "supportsDaylightSaving": true
              },
        
            "gateways": [
              {
                "gatewayInfo": {
                  "gatewayId": "xxx",
                  "mac": "xxx",
                  "crc": "BC31",
                  "isWiFi": false
                },
                "temperatureControlSystems": [
                  {
                    "systemId": "xxx",
                    "modelType": "EvoTouch",
        And from the newer WiFi controller

        Code:
            "locationInfo": {
              "locationId": "xxx",
              "name": "Kitchen",
              "streetAddress": "xxx",
              "city": "xxx",
              "country": "UnitedKingdom",
              "postcode": "xxx",
              "locationType": "Residential",
              "useDaylightSaveSwitching": true,
              "timeZone": {
                "timeZoneId": "GMTStandardTime",
                "displayName": "(UTC) Dublin, Edinburgh, Lisbon, London",
                "offsetMinutes": 0,
                "currentOffsetMinutes": 60,
                "supportsDaylightSaving": true
              },
        
            "gateways": [
              {
                "gatewayInfo": {
                  "gatewayId": "xxx",
                  "mac": "xxx",
                  "crc": "E05C",
                  "isWiFi": false
                },
                "temperatureControlSystems": [
                  {
                    "systemId": "xxx",
                    "modelType": "EvoTouch",
        Both say they are using DST, but say the current offset is 60 minutes and both say they DON'T have WiFi. It does not even make any difference if I turn off the auto dst setting on the older controllers.

        Comment

        • gordonb3
          Automated Home Ninja
          • Dec 2016
          • 273

          Thanks for the feedback. I'm kind of working in the dark with that device because I don't have any - wouldn't have any use also as I'm on city heating.

          That incorrect timezone indicator does sound annoying. I'm currently on CETD myself and as far as I know overrides are always UTC while schedules are in localtime (I do provide UTC versions of the get_next_schedule functions now as well). It will be hard to auto-correct that if it becomes unpredictable which timezone is actually used.

          Comment

          • RichardP
            Automated Home Jr Member
            • Jun 2017
            • 48

            I think I'm just going to have to match the use of daylight saving against the location ID or name, I've tried everything else I can think of.

            The WiFi version of the controller has a toggle for updating the time over WiFi, presumably synchronising with the Honeywell servers, so there is no need for it to know about DST. The older version has an 'Auto DST' option in the same place on the menu, as that version of the controller may not be connected to the internet I assume that uses some internal algorithm based on the market in which it's sold to determine if DST is active or not.

            On another, but related topic, the routine utc_to_local in Evohomeclient does not seem to work correctly with regard to DST. The TZ is obtained and then the DST, but the DST value is never applied to the tzoffset variable.

            Comment

            • gordonb3
              Automated Home Ninja
              • Dec 2016
              • 273

              utc_to_local() does not actually look at DST. It only registers the state to be able to pick up that it changed and it needs to recalculate the time difference between localtime and gmtime. It does not need to apply DST because its offset is already included in that time difference.

              Comment

              • RichardP
                Automated Home Jr Member
                • Jun 2017
                • 48

                Well, I would expect utc_to_local to take account of DST and it doesn't. UTC never has DST applied (quite why UTC was ever introduced I don't know, it's the same as GMT!), whereas the local time can (and does at the moment). Passing the override time from the WiFi Evohome controller through utl_to_local results in the same date/time, it just has an A at the end rather than Z. It's possible that this is a Windows only thing.

                Comment

                • dty
                  Automated Home Ninja
                  • Aug 2016
                  • 489

                  They're not the same thing. GMT is a timezone, UTC is a time standard. They are currently different (albeit by less than a second).

                  Comment

                  • gordonb3
                    Automated Home Ninja
                    • Dec 2016
                    • 273

                    I think GMT does have a DST state while UTC does not. It may actually be possible that Windows does in fact return current GMT time in gmtime_s() where linux returns UTC in gmtime_r(). It should be easy enough to verify this by dumping the value of utime.tm_isdst from #1304. If that is non zero the return is actually BST and the result will currently be an hour off.

                    The 'A' is just to differentiate from 'Z' btw. This is documented in the demo. I'm kind of in between whether I should keep it or lose it. In any case the code does not actually look up the military code related to the tzoffset.

                    Comment

                    • gordonb3
                      Automated Home Ninja
                      • Dec 2016
                      • 273

                      Oh, f... it

                      There's a line missing. utime.tm_isdst needs to be set to -1 between #1304 and #1305. Currently away from the dev machine, I'll push the fix tomorrow.

                      Comment

                      • RichardP
                        Automated Home Jr Member
                        • Jun 2017
                        • 48

                        I've implemented the fix in utc_to_local, that seems to do the job. Also, I now can't replicate the DST issue between the controllers! Must have just been a mental relapse to do with the utc_to_local not taking into account DST.

                        So, all is well.

                        Comment

                        • gordonb3
                          Automated Home Ninja
                          • Dec 2016
                          • 273

                          Originally posted by RichardP View Post
                          I've implemented the fix in utc_to_local, that seems to do the job. Also, I now can't replicate the DST issue between the controllers! Must have just been a mental relapse to do with the utc_to_local not taking into account DST.

                          So, all is well.
                          It's a bit different than that. The thing is that C++ does not have a UTC version of mktime(), but it does have a UTC version of localtime() that will break up time into its individual components. The trouble in this is that this function sets the DST flag to 0 because UTC does not have DST and this needs to be reset to 'auto' (-1) prior to feeding this struct into mktime(). Because this line was missing the DST flag was wrong for current local time and mktime() corrected this by applying (reverse) DST.

                          Anyway, it's fixed now.

                          Comment

                          • gordonb3
                            Automated Home Ninja
                            • Dec 2016
                            • 273

                            Important update to the C++ evohomeclient

                            I have been made aware that there was an issue with the on-empty automatic schedule retrieval if the object is a DHW, resulting in crashing the client application. If you do or did experience such crashes, please fetch the latest version of the library from the master branch on GitHub.

                            Comment

                            • dkleeman
                              Automated Home Jr Member
                              • Apr 2012
                              • 20

                              Originally posted by freeranger View Post
                              Standing on the shoulders of giants here, I have pulled together things I have learned in this thread and elsewhere and knocked up a python based app "evologger".
                              It is designed to be extensible and currently it supports the following:
                              Freeranger, this is awesome. It completely works and I had it up and running in about an hour or two. Thank you very much!

                              Comment

                              • clinkadink
                                Automated Home Jr Member
                                • Apr 2017
                                • 10

                                I have had this up and running on my Raspberry Pi now for a few months without issues. The client is great. Just wanted to say "thank you" for all your hard work. It is appreciated.

                                This is a standalone python script that creates a webserver on the pi, and renders any connected Evohome devices in a webpage, e.g.: http://192.168.1.123:9999/evopi

                                The page updates automatically every 5 minutes (adjustable in the head of the html). The zones are displayed in colour according to how close they are to their setpoint, allowing the user to quickly see what's hot and what's not.

                                All connection details remain in evoconfig.py (username, pw, url, port).

                                Photo: https://photos.app.goo.gl/WEbKFbucztaf7qIT2

                                Script: https://goo.gl/hVqi5a

                                Attached Files
                                Last edited by clinkadink; 1 December 2017, 09:16 AM. Reason: Updated links

                                Comment

                                Working...
                                X