Page 3 of 3 FirstFirst 123
Results 21 to 28 of 28

Thread: Domoticz beta now has in core support for Evohome web API

  1. #21
    Automated Home Legend
    Join Date
    Jul 2014
    Posts
    1,001

    Default

    All the data in the menus aren't available on the Api. Even when you use a HGI80, you need to query them separately and then they sent on the airwaves.

  2. #22
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    134

    Default

    This probably requires an explanation.

    The thing I'm doing here is that when I push a button I want the individual zones to show the corresponding mode and matching values. The problem is that I cannot query the web portal for these values right after submitting a change, because if I do the portal returns the old values. As a result I need an offline method to be able to display these values as a direct response.

  3. #23
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    134

    Default

    Dead end. I figured I could do a request through the API for the next switchpoint but it turns out this gives me today's next switchpoint rather than the actual one from the Day Off system mode.

  4. #24
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,828

    Default

    Quote Originally Posted by gordonb3 View Post
    Dead end. I figured I could do a request through the API for the next switchpoint but it turns out this gives me today's next switchpoint rather than the actual one from the Day Off system mode.
    That's what I thought. Even the official iPhone app gets this wrong, for the same reason!

    What puzzles me is why when they designed the newer API (which was introduced to support remote viewing and editing of schedules, not supported by the original API) they didn't just throw every piece of useful data in that they could, in what the controller sends to the cloud. Why leave out things like the hotwater set point and differential, but include the current hot water temperature. Why leave out any information on what day the active day of schedule is using...(or add a virtual day to represent it) Why not send the heat demand figure for each zone ? (I believe there is a field in the API for heat demand but it is currently always zero)

    I know if I was designing an API I would include as much information as possible for future expansion, and send it up to the cloud, even if not all of it was surfaced in the current versions of the user interface or apps...

    A work College who uses Tado V3 showed me the latest beta version of the Tado iPhone app the other day - they have added not only detailed graphing of set point and measured temperature for each zone viewable natively in the iPhone app, they have also added graphing of the heat demand, (overlayed as a grey shadow on the temperature graph) and a 3 bar heat demand figure in the live zone stats next to the temperature to show whether a zone is demanding any heat right now, and whether it is a small, medium or large heat demand. Something that Evohome users have been asking for for a long time now.
    Last edited by DBMandrake; 19th June 2017 at 12:10 PM.

  5. #25
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    134

    Default

    Well, at least the setpoint is correct, so there should be a weekday value where all the reported setpoints match the ones from the schedule at any given time.

  6. #26
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    134

    Default

    Nailed it

    Next switchpoint times will now automatically adjust to display the correct value when in Day Off mode.

  7. #27
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,594

    Default

    How did you do it?

  8. #28
    Automated Home Guru
    Join Date
    Dec 2016
    Posts
    134

    Default

    My normal procedure for finding the next switchpoint is to reference a local copy of the schedule (renewed every hour). From this I know what the current setpoint should be (which is part of the data from the previous switchpoint) and if there is a mismatch with the one reported I find the next weekday where the match does exist.

    Obviously it will be wrong the first time if you changed the default weekday for Day Off in your controller, but once it detects that error it will adapt immediately and store the correct weekday for future reference.

Posting Permissions

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