If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Domoticz beta now has in core support for Evohome web API
Maybe that's a good thing, though. The rooms with very low set points will usually be kept at > mildew temps by absorbing warmth from your heated rooms. But if the other rooms are all cool then your zones with extremely low setpoints will get colder than they normally do.
Perhaps.
If the default away temperature was 10 degrees I would agree with you, but it's 15 degrees. I have a spare room set to 10 degrees on permanent override at the moment, (yes it does draw heat from other rooms when the door is sometimes open for a while) if the away action was on it's default 15 degrees it would actually cause that room to come on when I leave the house and all other rooms go off.
After changing the away temperature to 10 degrees its a bit more reasonable though.
Moving forward. Baby steps. Referencing the 'old' US API is now a selectable option in the hardware page where you can choose between 'controller compatible' (i.e UK/EMEA API only - 0,5 degree resolution) or enable the secondary API with a choice of displaying one or two decimals. There are also some (minor) improvements to the feedback when you trigger a change to the Evohome system from Domoticz. Still need to figure out a method to discover what day is referenced when 'Day Off' is selected.
Moving forward. Baby steps. Referencing the 'old' US API is now a selectable option in the hardware page where you can choose between 'controller compatible' (i.e UK/EMEA API only - 0,5 degree resolution) or enable the secondary API with a choice of displaying one or two decimals.
Looks good, and nice to have the option to choose.
Still need to figure out a method to discover what day is referenced when 'Day Off' is selected.
I'd have to look at the raw data returned via the API again to be sure, but I don't think the day which Day off mode uses is made available via the API. Just like the hot water set point and differential is not made available.
One thing that tends to support this theory is that if you use the official Honeywell iPhone App to set a timed override, it normally defaults to the override lasting until the next scheduled set point change, showing that the app knows today's schedule for the zone. However when you do a timed override using the iPhone app when the system is in day off mode the override lasts until the next set point of the actual day (eg today) not the schedule that is currently running - your day off schedule, by default Saturday.
So it seems that even the official iPhone app doesn't know what day's schedule is in use for day off mode, only that day off mode is active...
Last edited by DBMandrake; 15 June 2017, 01:25 PM.
No, it's not there. The 'Away' setpoint isn't as well, but of course you can easily grab that with the next request to the server so it should only be wrong the first time and only if the setpoint is different from the default 15.
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.
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.
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.
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; 19 June 2017, 11:10 AM.
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.
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.
Comment