Decoded - EvoHome API access to control remotely.

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

    There is no pump with the heating from the solar PV, excess power is diverted to the immersion heater.

    Regardless, I can't see any explenation for the small variations, then large step. If the small variations are correct, there is no way the water could jump by 10 degrees in a minute or two.

    Comment

    • DBMandrake
      Automated Home Legend
      • Sep 2014
      • 2361

      Originally posted by RichardP View Post
      There is no pump with the heating from the solar PV, excess power is diverted to the immersion heater.

      Regardless, I can't see any explenation for the small variations, then large step. If the small variations are correct, there is no way the water could jump by 10 degrees in a minute or two.
      I'm out of ideas then. I don't see any small oscillations in my hot water data, and I've looked over the data as a CSV.

      Comment

      • bruce_miranda
        Automated Home Legend
        • Jul 2014
        • 2307

        If it is any help, I see these variations as well when solar is heating the water using the immersion heater. I never see these fluctuations when the HW is heated by Evohome and the boiler.

        Comment

        • RichardP
          Automated Home Jr Member
          • Jun 2017
          • 48

          Originally posted by bruce_miranda View Post
          If it is any help, I see these variations as well when solar is heating the water using the immersion heater. I never see these fluctuations when the HW is heated by Evohome and the boiler.
          Interesting. I see the variations at night, when there is obviously no heat input so it can't be as simple as being related to an alternate heat source.

          The ImmerSUN that I have uses some sort of sin wave modulation to allow the immersion heater element to be fed variable amounts of power, up to its rated power, depending on how much excess solar energy there is that would otherwise be exported. I wonder if there is some sort of interference that's being picked up by the sensor in the cylinder? I'll try turning the ImmerSUN completely off and see if the variations still exist. I should say that I also get similar variations on the other zones, but these don't stand out as anomalies as the reporting interval is much shorter.

          Comment

          • RichardP
            Automated Home Jr Member
            • Jun 2017
            • 48

            Just to keep the thread updated, I've found the reason for the jitters on the recorded temperatures.

            It seems that the old Evohome client for the V1 API does not like being logged into too frequently. As I had two PCs running and my code was logging in for every query, that was too much for it and the login failed. Under those conditions the V2 API temperature was used which, unless the actual temperature was exactly on the degree or half degree caused a difference in the reading. On the next read the V1 API login succeeded and so another difference was logged. The V2 API login does not appear to have the same login limit, unless the two are linked as the V1 login was done after the V2 login.

            Comment

            • DBMandrake
              Automated Home Legend
              • Sep 2014
              • 2361

              Originally posted by RichardP View Post
              Just to keep the thread updated, I've found the reason for the jitters on the recorded temperatures.

              It seems that the old Evohome client for the V1 API does not like being logged into too frequently. As I had two PCs running and my code was logging in for every query, that was too much for it and the login failed. Under those conditions the V2 API temperature was used which, unless the actual temperature was exactly on the degree or half degree caused a difference in the reading. On the next read the V1 API login succeeded and so another difference was logged. The V2 API login does not appear to have the same login limit, unless the two are linked as the V1 login was done after the V2 login.
              Interesting.

              How often are you calling the API ? On my graphing I only poll for temperatures once every 5 minutes. (Well, twice every 5 minutes actually as I graph independently with both Munin and Domoticz)

              Also are you calling the API separately for every zone or just making a single API call for all zones ? The munin plugin I use uses local caching so that the first zone the plugin queries calls the API and saves the results in a cache for 4 minutes, the remaining zones that are queried a moment later read their data directly from the cache without additional API calls. I think Domoticz does something similar too.

              Ideally you should limit your API calls to each API to no more than one call every 5 minutes.

              Comment

              • gordonb3
                Automated Home Ninja
                • Dec 2016
                • 273

                Don't really understand. Why do you do a login for every request for information? How often do you do it?

                The python scripts that link to Domoticz prevent you from contacting the server within less than a minute from the previous contact. I've not heard anyone stating they had similar issues as you. As these scripts are single run instances, these users have no choice. You on the other hand are running some service like application and I'm just realizing you said something before about destroying the Class. Don't! Keep the Class loaded. You can re-use the session (and login) information for a full hour. All you need to do is refresh the changed information: in the UK/EMEA API that is get_status() and in the US 'v1' API full_information(). My suggestion is that you do not wait for Honeywell to tell you that the session ID is no longer valid though. Set a timer and rerun the login() method just before it ends.

                Comment

                • RichardP
                  Automated Home Jr Member
                  • Jun 2017
                  • 48

                  My initial implementation created the Evohome objects and destroyed them every minute, running on 2 devices that's 2 logins on each API every minute. I did it like that initially because the older version of the Evohomeclient object threw if you tried to get the status and the session had timed out. It was just easier at the time and not meant to stay that way.

                  I've now changed the code so it detects when the sessions have timed out and logs in again. Now I don't have the issue with the old API saying too many log in requests even with 2 devices running.

                  Just giving a bit of information that might help others.

                  Comment

                  • DBMandrake
                    Automated Home Legend
                    • Sep 2014
                    • 2361

                    Polling every minute still seems a bit excessive. How far do you think the temperatures will change in one minute ? I'm pretty sure I've seen a post on here before from a Honeywell employee asking for the API to not be queried more than every 5 minutes.

                    Keep in mind that temperature sensors in the system (apart from the built in sensor in the Evotouch) only report in to the controller once about every 4 minutes. So you won't see changes in temperature every minute even if the room is in the process of heating up or cooling down.
                    Last edited by DBMandrake; 1 July 2017, 07:27 PM.

                    Comment

                    • RichardP
                      Automated Home Jr Member
                      • Jun 2017
                      • 48

                      I agree that temperatures are unlikely to change much in a minute, but things like overrides can be set at any time. So to log the current state you have to poll frequently. That's the inherent problem with a polling system, to catch random events you have to poll far more frequently than might be desirable on the server end. Some sort of local multicast or targeted UDP would be more efficient for a local monitoring station.

                      However, remember I've only had the program successfully receiving data for about a week, there is bound to be plenty of fine tuning required.

                      Comment

                      • gordonb3
                        Automated Home Ninja
                        • Dec 2016
                        • 273

                        Granted. The original implementation did lean heavily on the idea of being able to create a single run application. Your safeguards should not be needed with the upgraded version any more though.

                        Comment

                        • RichardP
                          Automated Home Jr Member
                          • Jun 2017
                          • 48

                          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.



                          The plot also shows significant overshoot despite reduction in flow temperature over the summer, but that's a different issue.

                          Comment

                          • paulockenden
                            Automated Home Legend
                            • Apr 2015
                            • 1719

                            I seem to remember one of the Honeywell techie guys made a 'polite' request in the forums here asking people not to poll at more than 10 (or was it 5?) minute intervals.

                            Comment

                            • gordonb3
                              Automated Home Ninja
                              • Dec 2016
                              • 273

                              Originally posted by paulockenden View Post
                              I seem to remember one of the Honeywell techie guys made a 'polite' request in the forums here asking people not to poll at more than 10 (or was it 5?) minute intervals.
                              Seems reasonable. If you want to pick up system changes or overrides anywhere close to when they are initiated you're bound to poll more frequently though. Of course a normal session where you fetch all the data consists of:
                              1. login
                              2. get user info (user ID)
                              3. get installations registered to that user ID
                              4. get status (per installation)
                              5. for each zone and DHW: get next switchpoint if in FollowSchedule mode

                              Which in my case comes down to ten calls (sorry: unlike many of the castle owners here I only have one installation with six zones).

                              If you keep your client application resident you can skip many of these steps as the login will be valid for an hour, the user ID will never change, controller and zones will rarely change, as will schedules. This is how I created the internal client in Domoticz: while the login is still valid it will only do one call (two if US API is enabled for better temperature resolution), saving both me and Honeywell precious bandwidth.

                              Comment

                              • RichardP
                                Automated Home Jr Member
                                • Jun 2017
                                • 48

                                My installation is larger than Gordon's, 3 locations with 19 zones plus DHW. I'm currently doing the following:

                                1 - Initial logon to both APIs.
                                2 - Request user info for both APIs
                                3 - Request installation info

                                The above will only be re-requested if the session times out.

                                4 - Request schedule info for each zone once per day, 19 as I'm not getting the DHW schedule yet.

                                I can invalidate the info in the app to cause it to re-request manually if the schedule changes, not ideal, but saves an additional set regular requests.

                                5 - Request V1 API Installation info
                                6 - Request current status for each location (3).

                                Requests 5 and 6 are requested at regular intervals, currently set to once per minute.

                                If each session lasts 1 hour, then my total request frequency is :

                                19 schedule requests per day.
                                5 requests per hour.
                                4 requests per minute.

                                I could probably relatively easily reduce the requests per hour to 4 by caching the installation info and just refreshing it together with the schedule once per day, but I don't see how I can easily reduce the high frequency requests without loosing resolution on the temperature and, more importantly, the current set point data.

                                I could try an replicate the TRV and DHW characteristics by polling more frequently the closer the temperature is to the set point, but that would not help with logging overrides. This would have to be done on a location by location bases, so if any zone in a location was close to it's set point then the frequency would be increased. In winter I'd think that at least one zone per location would be within the high frequency area at almost all times.

                                Comment

                                Working...
                                X