Sorry, I think I was unclear. I have had to use a combination of the old version and new version of the webclient because just using the new version and the new version of Evohomeclient causes the crash on exiting user_account.
Decoded - EvoHome API access to control remotely.
Collapse
X
-
Originally posted by RichardP View PostSorry, I think I was unclear. I have had to use a combination of the old version and new version of the webclient because just using the new version and the new version of Evohomeclient causes the crash on exiting user_account.
Comment
-
-
Figured that would be it. Must mean you are somehow triggering an exception though. Possibly overkill, but I'll repeat that for all the other exception throwing instances.
Also changed the get_zone_temperature() method in the EvohomeOldClient Class to use locationId instead of a sequence number. Thanks for pointing that out.
Comment
-
-
Yes, spotted that (had to change the code to pass the zone id so could hardly miss it!).
Memory leaks are back though.
Edit :
Looks like the leaks are in evohomeoldclient. If I don't create the evohomeoldclient object and revert to 0.5 C resolution, I don't get any leaks.Last edited by RichardP; 26 June 2017, 04:27 PM.
Comment
-
-
I think the leaks were my fault! I was not calling cleanup on the evohomeoldclient object I spun up before it went out of scope.
Maybe create a destructor and call the cleanup in that, then cleanup could be a private method and it would all take care of itself.
Comment
-
-
Originally posted by RichardP View PostSorry, I was ambiguous in what I said was not displayed. Window Open, Optimisation, Override from the App (presumably override from the API) and override from manual adjustment of a thermostat of from the controller are displayed as an icon in the zone. What's not displayed is if you adjust one of the radiator valves manually.
I've also noticed that when in Optimisation mode at the end of a scheduled on period you get a set point of 5 degrees too, so there are quite a few states that are not individually distinguishable.
Interesting, and that does seem to correspond with what I'm seeing. Updates are about 1 an hour even if the temperature has changed by 5 degrees or so. If the temperature changes by 10 degrees (for example if the bath has been run and the temperature drops quickly) then you usually get an update within 5-10 minutes.
Out of interest, why does the CS92A need to have such power saving algorithms when devices like the radiator valves don't?
I agree though that the power saving does seem excessive on the CS92A - to the point where it causes issues with temperature overshoots or occasional bogus "comms errors".
Originally posted by RichardP View Post@Gordon
I've just tried the mechanism for getting more accurate temperatures from the V1 API. After some modifications. it's now working.
I had to make some modifications because the V1 API is returning the locations in a different order to the V2 API, so either you have to look at all the locations for the Zone ID or first look through the locations for the location ID and then find the Zone ID in that location.
The way I matched the zones via API's in the Domoticz script was like this:
Code:# Fetch the measured temperature from the V1 API for increased resolution. Match zones between both API's via id/zoneId. temp=zone['temperatureStatus']['temperature'] for zonetemp in client1.temperatures(): if int(zonetemp['id'])==int(zone['zoneId']): temp=zonetemp['temp'] break
Last edited by DBMandrake; 26 June 2017, 05:19 PM.
Comment
-
-
Originally posted by DBMandrake View PostYes, you can't take the order of the zones for granted, they not only differ between API's, when you add an additional zone it seems to reshuffle the order of existing zones in the API results.
The way I matched the zones via API's in the Domoticz script was like this:
Code:# Fetch the measured temperature from the V1 API for increased resolution. Match zones between both API's via id/zoneId. temp=zone['temperatureStatus']['temperature'] for zonetemp in client1.temperatures(): if int(zonetemp['id'])==int(zone['zoneId']): temp=zonetemp['temp'] break
Comment
-
-
Originally posted by DBMandrake View PostYou must have an older non-Wifi controller then. Display of local override was added in the first firmware update released for the Wifi model. If I adjust my HR92's directly I get a timed override displayed on the controller and iPhone app.
Originally posted by DBMandrake View PostThe way I matched the zones via API's in the Domoticz script was like this:
Code:# Fetch the measured temperature from the V1 API for increased resolution. Match zones between both API's via id/zoneId. temp=zone['temperatureStatus']['temperature'] for zonetemp in client1.temperatures(): if int(zonetemp['id'])==int(zone['zoneId']): temp=zonetemp['temp'] break
Now that I've got the more accurate temps, the hot water plot shows some slightly odd behaviour. Here's a full screen image of the hot water plot today, the V1 temps were implemented at about 13:15. The power input from the solar was reasonably constant between 11:00 and 14:00, then the sun went in and very little further power was supplied.
Although the reported temperature varies by a few 1/10ths of a degree almost every minute, the approximate value remains constant over the one hour period until the next update while the temperature of the water is not within the sensitive region. I find that difficult to explain, except that the small variation are being artificially applied to the reading supplied by the sensor.
Comment
-
-
Originally posted by RichardP View PostI think the leaks were my fault! I was not calling cleanup on the evohomeoldclient object I spun up before it went out of scope.
Maybe create a destructor and call the cleanup in that, then cleanup could be a private method and it would all take care of itself.
Comment
-
-
Originally posted by RichardP View PostAlthough the reported temperature varies by a few 1/10ths of a degree almost every minute, the approximate value remains constant over the one hour period until the next update while the temperature of the water is not within the sensitive region. I find that difficult to explain, except that the small variation are being artificially applied to the reading supplied by the sensor.
Are you sure that your graphing engine isn't interpolating ?
Comment
-
-
BTW you can clearly see how much more frequently the CS92A sends updates when the temperature is in the 49-54 degree differential band I have configured... updates are very infrequent below 45 degrees despite the hot water most likely heating up at a fairly steady initial rate. (The blue line shows when the hot water demand was switched on after 4 days away from home)
The graph also illustrates a minor overshoot and you can see how the update frequency is very slow above the set point as well..Last edited by DBMandrake; 26 June 2017, 10:05 PM.
Comment
-
-
Originally posted by DBMandrake View PostAre you sure that your graphing engine isn't interpolating ?
13:47:02 505 0
13:48:02 510 0
13:49:02 512 0
13:50:03 510 0
13:51:03 512 0
13:52:02 510 0
13:53:02 512 0
13:58:03 515 0
13:59:02 510 0
14:03:03 515 0
14:04:02 510 0
14:05:03 515 0
14:06:02 510 0
14:07:03 515 0
14:08:03 517 0
14:09:02 510 0
14:10:03 517 1
14:15:14 510 0
14:17:02 517 0
14:18:02 510 0
14:19:03 517 0
14:20:03 510 0
14:23:02 517 0
14:24:02 510 0
14:26:03 517 0
14:28:03 515 0
14:31:02 510 0
14:35:03 515 1
14:37:02 510 0
14:39:03 515 0
14:41:02 510 0
14:42:03 515 2
14:54:55 515 0
14:55:02 510 0
14:58:02 515 0
15:00:03 510 0
15:01:03 515 0
15:04:02 510 1
Comment
-
-
Originally posted by RichardP View PostYes, 100% sure. This is a sample of the raw data, temperature values are multiplied by 10, ignore the column on the right.
It may well be that there really are small up and down fluctuations in the cylinder temperature in response to changes in solar panel illumination - which would not happen on my system without solar where when the tap is not running the temperature would be falling steadily but VERY slowly.
Within the differential band the CS92A will report very small changes in temperature.
Comment
-
Comment