Results 1 to 3 of 3

Thread: Problem with EvohomeClient

  1. #1
    Automated Home Jr Member
    Join Date
    Jun 2016
    Location
    Colchester
    Posts
    12

    Question Problem with EvohomeClient

    I have encountered a problem with EvohomeClient where the 'until time' for remote temperature changes appears 1 hour too late on the evotouch controller.

    For example, when I ran the script below, the evotouch controller showed an override of 15 degrees until 19:00 hours.

    The evotouch controller is correctly localised for the UK. I am running the script on a Raspberry Pi which is also correctly localised. Both display the correct local date and time.

    Has anyone else seen this problem? I am wondering if it is a DST issue or a UTC vs local time issue? Any help would be appreciated.

    #! /usr/bin/python3
    #
    # test program to demonstrate evohomeclient until time issue

    user='*********' # fill in your Honeywell TCCN username
    pw='*********' # fill in your Honeywell TCCN password
    z = 'Lounge' # fill in a valid zone name for your system

    from datetime import datetime
    from evohomeclient2 import EvohomeClient

    ec = EvohomeClient(user, pw)
    zone = ec.locations[0]._gateways[0]._control_systems[0].zones[z]
    dt = datetime(2108, 9, 1, 18, 0, 0) # Note: change date & time to suit
    zone.set_temperature(15, dt)

  2. #2
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,928

    Default

    Perhaps the API expects the time in UTC not GMT ?

    I haven't used datetime() on python before but was having a read over it here:

    https://docs.python.org/2/library/datetime.html

    As you're not specifying any timezone in your datetime call it will be a "naive" datetime object that is unaware of timezones - having your Linux installation set to the correct timezone doesn't help if your code is not written to actually use timezones.

    So I suspect that is your problem.

    Also see here for more info:

    https://stackoverflow.com/questions/...ware-in-python

  3. #3
    Automated Home Jr Member
    Join Date
    Jun 2016
    Location
    Colchester
    Posts
    12

    Default

    Yes, I think you are right. The last time I played with this was back in early March, i.e. before summertime started, which explains why I did not see the problem then.

    I delved into the sources on GitHub. In the file zone.py, on line 63, the data for the server is assembled with:

    data = {"HeatSetpointValue":temperature,"SetpointMode":"T emporaryOverride","TimeUntil":until.strftime('%Y-%m-%dT%H:%M:%SZ')}

    The server seems to require a time in ISO 8601 format and the final Z in the format string signifies zero time offset from UTC.

    Thanks also for pointing me to the article on Stack Overflow. It seems this topic is full of gotcha's!

    I think I can solve my problem by using now() and utcnow() to make a time delta of the difference between my local time and UTC. This seems to work on my RPi:

    Python 3.4.2 (default, Oct 19 2014, 13:31:11)
    [GCC 4.9.1] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from datetime import datetime
    >>> dt = datetime.now() - datetime.utcnow()
    >>> print(dt)
    0:59:59.999649
    >>>
    >>> print(datetime.now()-dt)
    2018-09-02 08:30:38.264860
    >>>

    Thanks again for your help

Posting Permissions

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