Decoded - EvoHome API access to control remotely.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • RichardP
    Automated Home Jr Member
    • Jun 2017
    • 48

    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.

    Comment

    • gordonb3
      Automated Home Ninja
      • Dec 2016
      • 273

      Originally posted by RichardP View Post
      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.
      Ah, I see. Could there be something of a double exception maybe? Which class constructor are you currently using? The one with or without user credentials?

      Comment

      • RichardP
        Automated Home Jr Member
        • Jun 2017
        • 48

        I'm using the constructor with credentials. If you need any more detains on the exception I can easily reproduce it.

        Comment

        • RichardP
          Automated Home Jr Member
          • Jun 2017
          • 48

          Just updated to the latest code. Exception has now gone and for the first time, with my 'helper' layer, I've not had to make any changes to your evohomeclient or webclient files at all. Excellent!

          Comment

          • gordonb3
            Automated Home Ninja
            • Dec 2016
            • 273

            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

            • RichardP
              Automated Home Jr Member
              • Jun 2017
              • 48

              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

              • RichardP
                Automated Home Jr Member
                • Jun 2017
                • 48

                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

                • DBMandrake
                  Automated Home Legend
                  • Sep 2014
                  • 2361

                  Originally posted by RichardP View Post
                  Sorry, 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.
                  You 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.
                  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.
                  Yes I forgot about optimisation. That also changes the set point without any indicator (in the API) to say why it changed.
                  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?
                  Well actually the HR92's do have power saving algorithms - the main one being that the device sleeps in (approx) 4 minute cycles, during that time it will wake up prematurely if you press a button or turn the knob, but left alone it is "deaf" to anything the controller might send to it during that sleep period, which is why the controller has to wait for the next communication window before it can send a set point update or relay a remote temperature sensor reading. (The HR92 also only samples its built in sensor during each wake up period)

                  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.
                  Yes, 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
                  The outside loop (not shown in the above snippet) iterates through the V2 API zones, for each zone it retrieves the rounded V2 temperature (into "temp") then uses a loop to search all zones in the V1 API for a matching id/zoneId and if it finds a match it breaks the loop and replaces the value in temp with the more accurate value. The good thing about doing it this way is if a match isn't found you still get the less accurate value from the V2 API rather than a failure, bogus value or some other undefined behaviour.
                  Last edited by DBMandrake; 26 June 2017, 05:19 PM.

                  Comment

                  • gordonb3
                    Automated Home Ninja
                    • Dec 2016
                    • 273

                    Originally posted by DBMandrake View Post
                    Yes, 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
                    The outside loop (not shown in the above snippet) iterates through the V2 API zones, for each zone it retrieves the rounded V2 temperature (into "temp") then uses a loop to search all zones in the V1 API for a matching id/zoneId and if it finds a match it breaks the loop and replaces the value in temp with the more accurate value. The good thing about doing it this way is if a match isn't found you still get the less accurate value from the V2 API rather than a failure, bogus value or some other undefined behaviour.
                    The problem in this case was actually related to the location, which was an oversight on my behalf and slipped by because I only have one installation that I can use as a reference.

                    Comment

                    • RichardP
                      Automated Home Jr Member
                      • Jun 2017
                      • 48

                      Originally posted by DBMandrake View Post
                      You 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.
                      I have 2 non WiFi versions with the separate WiFi hub and one WiFi version. I've just checked the WiFi version and you are absolutely correct, it shows the temperature override and the older no WiFi versions don't.

                      Originally posted by DBMandrake View Post
                      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
                      The outside loop (not shown in the above snippet) iterates through the V2 API zones, for each zone it retrieves the rounded V2 temperature (into "temp") then uses a loop to search all zones in the V1 API for a matching id/zoneId and if it finds a match it breaks the loop and replaces the value in temp with the more accurate value. The good thing about doing it this way is if a match isn't found you still get the less accurate value from the V2 API rather than a failure, bogus value or some other undefined behaviour.
                      This is what I've done in my helper wrapper, it gets the V2 API temp, then tries to find the V1 API temp and if found updates the temp.

                      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

                      • gordonb3
                        Automated Home Ninja
                        • Dec 2016
                        • 273

                        Originally posted by RichardP View Post
                        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.
                        That's one way. The cleanup routine is about curl though and since I removed the curl dependencies from the (other) Classes I should probably rethink the webclient routine and not create separate instances for each consumer Class. Given the scope where they are created they probably have no knowledge of each other anyway.

                        Comment

                        • DBMandrake
                          Automated Home Legend
                          • Sep 2014
                          • 2361

                          Originally posted by RichardP View Post
                          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.
                          Not seeing anything like that here, although I don't have any solar heating of the water. My temperature graph is flat with step changes as the hot water is used or cools, no small minor fluctuations.

                          Are you sure that your graphing engine isn't interpolating ?

                          Comment

                          • DBMandrake
                            Automated Home Legend
                            • Sep 2014
                            • 2361



                            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

                            • RichardP
                              Automated Home Jr Member
                              • Jun 2017
                              • 48

                              Originally posted by DBMandrake View Post
                              Are you sure that your graphing engine isn't interpolating ?
                              Yes, 100% sure. This is a sample of the raw data, temperature values are multiplied by 10, ignore the column on the right.

                              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

                              • DBMandrake
                                Automated Home Legend
                                • Sep 2014
                                • 2361

                                Originally posted by RichardP View Post
                                Yes, 100% sure. This is a sample of the raw data, temperature values are multiplied by 10, ignore the column on the right.
                                And during this time is the pump to the solar system running ?

                                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

                                Working...
                                X