Page 43 of 47 FirstFirst ... 3338394041424344454647 LastLast
Results 421 to 430 of 461

Thread: Decoded - EvoHome API access to control remotely.

  1. #421
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    Quote 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]

  2. #422
    Automated Home Jr Member
    Join Date
    Jun 2017
    Posts
    48

    Default

    @gordonb3 - Excellent, works a treat!

  3. #423
    Automated Home Jr Member
    Join Date
    Jun 2017
    Posts
    48

    Default

    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.

  4. #424
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    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.

  5. #425
    Automated Home Jr Member
    Join Date
    Jun 2017
    Posts
    48

    Default

    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.

  6. #426
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    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.

  7. #427
    Automated Home Jr Member
    Join Date
    Jun 2017
    Posts
    48

    Default

    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.

  8. #428
    Automated Home Ninja
    Join Date
    Aug 2016
    Posts
    489

    Default

    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).

  9. #429
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    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.

  10. #430
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    142

    Default

    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •