Decoded - EvoHome API access to control remotely.

[paulockenden]

Shame you can't register an event handler and get things pushed to you in real-time, rather than having to poll.

[gordonb3]

Yes, but that would require a totally different type of connection. Yet as you can see it is possible to largely reduce the number of requests and it is probably easier on the server if you do not concentrate the full number of requests once every ten minutes but do a single request (ask for status update) once a minute. The additional problem being that people that run the script version are mostly doing this using cron from a machine that is time synced using ntp and thus all do these bursts of requests at exactly the same time. Meaning that this server will likely be mostly idling for some 58 seconds every minute and then needs to go into overdrive for the remaining two seconds.

[RichardP]

I'd imagine this is why they changed the V2 API so that the status information is relatively light weight. I have actually set my request to be at 35 seconds past the minute to avoid hitting a request peak on the minute.

[RichardP]

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

[gordonb3]

I'll look into it. Probably not in zones though because the format of the dhw data is different and that would complicate (and maybe crash) procedures iterating through the zones.

[DBMandrake]

Looking at the output after setting a temporary override, the reported temperature changed every minute while around the override set point (red line). However, the temperature was updated as infrequently as every hour over night while it was well above the set temp. It would appear that the TRVs have similar optimisations to the DHW regarding the frequency of updates.

What was the sensor for the zone ? An HR92, a wall stat like a DTS92 or the Evotouch itself ?

As far as I was aware, HR92's only sample the temprature every 3-4 minutes, however its quite possible that the dedicated wall stats report in more frequently if the temperature is changing quickly, as they wouldn't need to do as much battery saving as a device also containing a motor, and I know the evotouch's built in sensor updates constantly. (Thus pushes frequent updates to the API)

[DBMandrake]

The additional problem being that people that run the script version are mostly doing this using cron from a machine that is time synced using ntp and thus all do these bursts of requests at exactly the same time. Meaning that this server will likely be mostly idling for some 58 seconds every minute and then needs to go into overdrive for the remaining two seconds.

Which is one reason why my cron script for domoticz runs at 2 minutes past every 5 minute interval. (2, 7, 12, 17 minutes etc)

[RichardP]

I was just thinking a zone as the current get_zone_schedule method could then be used. But maybe it needs a specific routine to get the dhw schedule.

[RichardP]

What was the sensor for the zone ? An HR92, a wall stat like a DTS92 or the Evotouch itself ?

As far as I was aware, HR92's only sample the temprature every 3-4 minutes, however its quite possible that the dedicated wall stats report in more frequently if the temperature is changing quickly, as they wouldn't need to do as much battery saving as a device also containing a motor, and I know the evotouch's built in sensor updates constantly. (Thus pushes frequent updates to the API)

It's an HR92.

[DBMandrake]

It's an HR92.

Hmm, I wonder if there is some sort of interpolation of data being done by the API...

Because it wouldn't make sense for the HR92 to wake up and send temperature readings to the controller every minute, when the controller only sends a temperature reading to the HR92 about every 4 minutes, and the HR92 will only make a valve position adjustment on those 4 minute intervals as well. It seems like wasting battery for no real benefit.

I think somebody with an HGI80 install needs to log the temperature sensor transmissions from an HR92 to see how often they really are as I'm highly doubtful that they are every minute, as it would defeat the battery saving sleep mode of the device. Perhaps DanD already has some captures that would clarify this.

By the way an HR92 used as the sensor in a zone does not actually use its temperature reading directly unless the zone is in "multi-room" mode. In the default "single room" mode the sensor HR92 sends its temperature reading to the controller, the controller then re-sends the temperature reading to all HR92's in the same zone including back to the one that the reading originally came from, and this relaying by the controller only happens about every 4 minutes as the receiver (and probably CPU) in the HR92 sleep for about 4 minutes. So its not until the temperature measurement has completed this round trip that the actuator on an HR92 can act on any change.

It's easy to prove this, turn up your room temperature by about a degree at the HR92 so that the radiator starts heating up then take the batteries out of the main controller - the room will continue to heat for nearly an hour without any temperature increase indicated on the HR92 display and the actual room temperature will have overshot as measured by another thermometer. Because the controller is AWOL there is nothing to relay the temperature reading back to the HR92. After about an hour the HR92 reverts to standalone fallback mode and will suddenly indicate the true, much higher temperature and close its valve, and start using its own temperature sensor directly.

[RichardP]

Well, that zone is relatively simple, there is one radiator with an HR92 and it's bound to the newer WiFi controller which is in another room. I can't see how the temperature reading could be coming from anywhere but the HR92.

[gordonb3]

Which is one reason why my cron script for domoticz runs at 2 minutes past every 5 minute interval. (2, 7, 12, 17 minutes etc)

That still places you in the same :00 second range where all these other scripts from other users are running.

I was just thinking a zone as the current get_zone_schedule method could then be used. But maybe it needs a specific routine to get the dhw schedule.

It has to be a different routine anyway because the URI to get the schedule is different.

[DBMandrake]

That still places you in the same :00 second range where all these other scripts from other users are running.

I don't follow what you're saying - you were saying that everyone using cron would be running at the same time - most graphing solutions graph every 5 minutes, EG 0,5,10,15 and so on. If they're polling every minute they're already contributing to overloading the server.

Delaying by say 10-20 seconds doesn't really help you much as it can take over 30 seconds for a full API query to be done anyway (at least with the python bindings) so your query would still overlap others.

[RichardP]

I don't follow what you're saying - you were saying that everyone using cron would be running at the same time - most graphing solutions graph every 5 minutes, EG 0,5,10,15 and so on. If they're polling every minute they're already contributing to overloading the server.

Delaying by say 10-20 seconds doesn't really help you much as it can take over 30 seconds for a full API query to be done anyway (at least with the python bindings) so your query would still overlap others.

I think what Gordon is saying is that, because most computers these days have their time synchronised with a time server, there will be a flood of requests exactly on the minute. There may be requests from different sources on different minutes, but they will still be on the minute change. That's why my requests are done at 35 seconds past the minute.

[gordonb3]

I think what Gordon is saying is that, because most computers these days have their time synchronised with a time server, there will be a flood of requests exactly on the minute. There may be requests from different sources on different minutes, but they will still be on the minute change. That's why my requests are done at 35 seconds past the minute.

Exactly.

But yes, the python bindings can take quite long on some machines so the actual load on the web portal may show a bit more spreading than I hinted earlier.