Boiler Pump/Fan cycling at random? Evohome at fault?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • g6ejd
    Automated Home Guru
    • Oct 2016
    • 153

    #16
    I have deliberately waited for 2 (random) cycles to complete before I intervene, these occur over an approximate 20-min period. The system worked normally and follows the schedule exactly during the day and I did walk around all 14 HR92's to check their display read what the controllers was saying, in cases 15°C as per the schedule, the house was warm throughout and last night the outside temperature here was 12.6°C and I know from experience that differential (15-12.6) will not create a heating demand, for this property it needs to be more like 6-8°C to do that.

    What I can't reconcile is why a heating demand should continue beyond the schedule end-time and left unchecked keep doing that.

    I'm still puzzled when I did the full system reset that I took the Controller off the wall-mount, did the system reset, then removed the batteries and was stood in-front of the BDR just about to reset them, well clear the bindings, when to my surprise the heating BDR came on. It could not have been the Controller, so there has to be some autonomy between HR92's and the BDR or the BDR just keeps switching on and following its last known command.

    Thinking there are RF problems (range) yesterday I did a range check and get 5-bars/maximum signal for each HR and the CS92 and BDR's. The Controller to BDR and CS92 range is about 2M, the Controller to furthest HR (line-of-sight) is 5M.

    I'm using Optimum Stop as a method to stop the cycling which was derived randomly, but I have found the Eco Quick action or Away does the same, albeit I have to switch those modes off for the following morning's schedule to resume.

    My neighbour has a Evohome and I recall him saying he has a similar problem, that's before I purchased my system, but now I think I realise what he was referring to, he told me he had set-up his many zones to just two in a bid to isolate the problem, hopefully I'll see him today and can ask him as this is more than a coincidence and his system is about 3-months old, so it's likely his system is the latest firmware too.

    For now I know that switching on Optimum Stop prevents this unwanted operation, but today I think I will call Honeywell again and report a problem rather than discuss things to try.

    Comment

    • paulockenden
      Automated Home Legend
      • Apr 2015
      • 1719

      #17
      Originally posted by g6ejd View Post
      so there has to be some autonomy between HR92's and the BDR
      Nope.
      Originally posted by g6ejd View Post
      or the BDR just keeps switching on and following its last known command.
      I believe that's how it works. The controller doesn't manage every on and off, it sends a "keep switching on and off at this rate" to the BDR.

      P.

      Comment

      • g6ejd
        Automated Home Guru
        • Oct 2016
        • 153

        #18
        OK, thanks for that confirmation, so in my case and assuming the Controller sends an Off command when the schedule ends, it looks like that command is never received, except if I send the same via Eco or Away it is or Optimum Stop it sends a defined off and that is received and heating stops near instantly.

        I'm still thinking this is a BDR fault, but it works normally all day long or most likely firmware issue.

        It would be neat if RAMESES could look at my system to see what's going on if Honeywell can see more detail than I can surmise.

        Comment

        • paulockenden
          Automated Home Legend
          • Apr 2015
          • 1719

          #19
          Originally posted by DBMandrake View Post
          Changes in heat demand from HR92's are sent almost immediately and forwarded on by the controller almost immediately as well.
          But the demand value passed to the BDR isn't just from a single HR92 is it. The controller aggregates the demand from a number of different HR92s (and possibly other devices). Averaging them out to a single value.

          I suspect it might be THIS process which can be laggy at times.

          When I first had Evohome I'd obsess about the boiler firing for a few seconds when it shouldn't. But these days I'm more "so what?". My house is comfortable and controllable. That's really all that matters. I've learnt to ignore the quirks.

          P.

          Comment

          • DBMandrake
            Automated Home Legend
            • Sep 2014
            • 2361

            #20
            Originally posted by paulockenden View Post
            But the demand value passed to the BDR isn't just from a single HR92 is it. The controller aggregates the demand from a number of different HR92s (and possibly other devices). Averaging them out to a single value.

            I suspect it might be THIS process which can be laggy at times.
            I've done quite a bit of testing of the behaviour of heat demand changes in the past trying to figure the system out and I have not seen any evidence of significant processing or transmission delays here.

            HR92's don't send an updated heat demand until they have finished adjusting their valve position, which depending on how far they have to turn can add a delay as the motor turns, but other than that a new aggregate heat demand is forwarded on to the BDR91's from the controller in mere seconds, and it seems very reliable and consistent.
            When I first had Evohome I'd obsess about the boiler firing for a few seconds when it shouldn't. But these days I'm more "so what?". My house is comfortable and controllable. That's really all that matters. I've learnt to ignore the quirks.
            I know what you mean - the nature of the wireless communications and infrequent wireless transmissions can lead to some behaviour that looks quirky at first glance but which is actually easy explained once you understand the system.

            The classic example is "I've turned the heating off but 3 minutes later the boiler relay just came on again". Perfectly normal behaviour when you understand that it can take up to 4 1/2 minutes for set points to be sent to and acted upon by HR92's, and that in the meantime the BDR91's will to continue to follow their existing heat demand TPI schedule, which by chance might bring the relay back on for a bit after you turned the heating "off". But a few minutes later it should go off again and stay off.

            But I have definitely seen times like g6ejd where even my understanding of how the system works cannot explain why the boiler relay is continuing to cycle on and off when all HR92's are set to 5 degrees and have been for at least 20 minutes. I had this happen to me when I converted from heating only with one BDR91 to S-Plan with 3x BDR91, and during that process various combinations of removing/clearing bindings and reconfiguring / making new bindings was performed, and to the best of my knowledge, correctly.

            But for some reason the relays kept cycling when there was no demand until a controller reboot, and things are OK now. So I think there are a few bugs/quirks in the software that can be hit when major configuration changes are made to the system like moving from no hot water to hot water control.

            Comment

            • DBMandrake
              Automated Home Legend
              • Sep 2014
              • 2361

              #21
              Originally posted by paulockenden View Post
              Nope.

              I believe that's how it works. The controller doesn't manage every on and off, it sends a "keep switching on and off at this rate" to the BDR.

              P.
              Although I've done some anecdotal testing before I thought I'd do a thorough test of this to confirm once and for all whether BDR91's do in fact autonomously continue their last known TPI cycle and for how long, and whether HR92's can send heat demands directly to the relays or not.

              The answer is an equivocal yes on the first point, and no on the second point, as I had already believed. Here was the test that I did this morning which took a couple of hours, and which is interesting as it gives some insight into details of how the system works that Honeywell doesn't go into.

              The system is configured with FAILSAFE OFF.

              I started with a system that was running with a moderate heat demand on a few zones - boiler and heating relays on about 3 minutes out of every 10 minutes, no hot water demand. I deliberately held the controller in my hands for a few minutes to warm it up so that the system thought the hallway was 28 degrees (as the evotouch is the sensor for the hallway) to see whether HR92's will fall back to their built in sensors if comms is lost - the large discrepancy in temperature would make it obvious when the switch to internal sensor happened, if it did happen.

              I waited until about 2 minutes after the boiler relay turned off in its TPI cycle then ripped the batteries out of the controller to shut it down then waited and observed the behaviour of the rest of the system.

              As far as boiler and heating relays were concerned, they did indeed continue to run at a 30% TPI duty cycle for a full hour - 3 minutes on, 7 minutes off in every 10 minute cycle.

              During this time making manual adjustments to an HR92 (very low or very high set point) did not have any effect on the relay duty cycle which stayed at 30%. So HR92's definitely cannot communicate heat demand without the controller.

              After exactly one hour the red LED on all three BDR91's lit and stayed on solid. From this point the relays stopped firing altogether, and after my pump overrun timer expired the pump stopped and remained off. After the fault light was on and the relays had stop cycling on I again tried to induce demand by turning up an HR92 but there was no response from the relays, as expected.

              I would expect that if I had failsafe turned on that after this one hour period the relay's (hopefully only boiler and heating relays not the hot water one) would start cycling at the 20% failsafe duty cycle, probably with the red LED also lit. I intend to perform a followup test with failsafe enabled to confirm the exact operation of failsafe mode and when it kicks in.

              30 minutes after the controller was powered down all the HR92's in the house started cycling between SYNC and NO SYNC every few minutes, but still appeared to be "waiting" for temperature updates from the controller as the room temperature displayed on the HR92's were still stuck on the last known temperatures sent from the controller. This lead to the living room getting uncomfortably warm because it wasn't aware that the room was still warming up as it couldn't receive updates from the DTS92 in the room - evidence that a remote sensor is relayed through the controller to the HR92.

              (I also believe that even local HR92 measurements are relayed via the controller back to the HR92 in single room zone configurations - but I didn't set out to specifically test this on this occasion)

              After exactly 60 minutes of no comms the HR92's all appeared to revert back to using their internal temperature sensors directly - the hallway HR92 which had been stuck on a reading of 28 degrees for an hour (last known temperature from the Evotouch held in my hand) suddenly started displaying 18.5 degrees, which would have been correct temperature near the floor in the room after the heating had been off in that room for an hour.

              The living room HR92 which uses a DTS92 also suddenly went from 21 (last known temperature from the DTS92 relayed via the controller) to 23 degrees - measured beside the radiator after the room had got a bit too hot because it wasn't getting temperature feedback. The DTS92 by this time still only said 21.5 so I know the reading wasn't coming from there.

              This is conclusive proof that after an hours worth of lost comms HR92's will revert to an autonomous mode of operation where they use their internal temperature sensor even if the zone was configured to use a remote sensor. And they will use their internal sensor to try to maintain the last known set point.

              I then re-inserted the batteries and didn't touch anything else to see how quickly the system recovers from power loss without being manually "poked".

              Within a minute of booting the controller the red LED's on the BDR91's all started flashing for about a minute then went out.

              After 3 minutes three zones had already reported in, had some demand and the boiler and heating relays came on. As each HR92 reported in the NO SYNC disappeared on the HR92.

              After 15 minutes the hallway radiator that is supposed to use the evotouch as its sensor updated its temperature reading from the locally measured 18.5 degrees to the 19.5 measured by the evotouch.

              After 23 minutes the DTS92 in the living room reported to the evotouch - about 5 minutes after that the reading on the HR92 in the living room updated from a local reading to match the DTS92 reading.

              After 26 minutes all straggling heating zones had reported in and were functioning normally.

              After exactly one hour the hot water temperature sensor finally reported in. It appears that if the hot water temperature is not crossing the hot water set points and is also not changing the transmissions are very infrequent indeed. So it appears that hot water sensor transmissions are more frequent when the temperature is changing than when it is sitting idle.

              One further thing - by the time I rebooted the controller some of the zone scheduled temperatures were different, it appears that the set points of the HR92's were not "refreshed" after the controller first re-made contact with them - as two of the zones were still running at their last known set points rather than what the set point should be now, at the time the controller was booted.

              However I'm sure that the set points would get back into sync again at the next scheduled or manual set point change.

              So there you have it. I intend to repeat the test with failesafe enabled to see if that works how I expect it will, I also want to perform some tests with the heating off with batteries removed from an HR92 for a long time in both failsafe off and failsafe on modes, to see if there is any failsafe protection for loss of comms with an HR92, or whether failsafe only protects loss of comms between controller and relays.

              Also it would be interesting to see if loss of comms with a DTS92 automatically reverts to using the HR92's own sensor after an hour.
              Last edited by DBMandrake; 28 October 2016, 01:39 PM.

              Comment

              • g6ejd
                Automated Home Guru
                • Oct 2016
                • 153

                #22
                As ever a very thorough and detailed analysis which has now proved beyond doubt how the system operates, I wonder if they tell installers all this on training courses - I must go through the free on-line training myself too.

                I have reset my system again, it's a bit time consuming but I'm getting very adept at setting the up from a NOOB configuration, it takes a while to rest all the HR92's, probably the longest job of all.

                If would be good if a backup and restore for the schedule existed.

                We'll see tonight if the default everything settings results in the heating BDR91 cycling again. It could be a faulty BDR in my system or still the application software (1.03).

                Out of interest does anyone know if the Evohome copes with DST this weekend, I'm sure it does, there is no mention of it in the manual.

                Comment

                • paulockenden
                  Automated Home Legend
                  • Apr 2015
                  • 1719

                  #23
                  There are some scripts on GitHub for backup and restore of schedules.

                  Gimme a shout if you can't find them as I'm sure I'll have them bookmarked somewhere.

                  Comment

                  • DBMandrake
                    Automated Home Legend
                    • Sep 2014
                    • 2361

                    #24
                    Originally posted by g6ejd View Post
                    Out of interest does anyone know if the Evohome copes with DST this weekend, I'm sure it does, there is no mention of it in the manual.
                    Yes it does, at least if you have the time set to Auto Update over Wifi. I haven't tried it with that turned off.

                    There is no country setting in the device, (unless it makes an assumption based on the language setting, which would be naughty) so I'm assuming that when you link the device to a total connect comfort account that it gets your country/timezone from there.

                    Comment

                    • g6ejd
                      Automated Home Guru
                      • Oct 2016
                      • 153

                      #25
                      I think your right, it must be based on language and as they sell Evohome in the US, perhaps there was a country suffix during the account setup and I missed English, UK. I think DST programming is one of the hardest problems to solve, I completed it recently for an Arduino project and decided to only do it for UK, USA and Australia on the basis that catering for all the countries is too difficult.

                      I've found the scripts for schedule backup, thanks for the prompt.

                      Comment

                      • HenGus
                        Automated Home Legend
                        • May 2014
                        • 1001

                        #26
                        My location is set up in my router.

                        Comment

                        • paulockenden
                          Automated Home Legend
                          • Apr 2015
                          • 1719

                          #27
                          The location is set in the web interface when you create the account, isn't it?

                          Having said that, for some reason I can't seem to get in to check right now - can't get past the login screen.

                          Comment

                          • HenGus
                            Automated Home Legend
                            • May 2014
                            • 1001

                            #28
                            Originally posted by paulockenden View Post
                            The location is set in the web interface when you create the account, isn't it?

                            Having said that, for some reason I can't seem to get in to check right now - can't get past the login screen.
                            Absolutely correct. My TCC account shows United Kingdom and the address of my device. Does time come from the Honeywell server though?

                            Comment

                            • g6ejd
                              Automated Home Guru
                              • Oct 2016
                              • 153

                              #29
                              Probably, few networks (LAN with a WAN access) have accurate time and Honeywell's time is slightly out, if it was coming from an NTP service it would be locked to UTC (Unix time) but it's not on mine which is 35-secs fast, which bothers me because I have OCD tendencies

                              Comment

                              • paulockenden
                                Automated Home Legend
                                • Apr 2015
                                • 1719

                                #30
                                Just double checked (and noticed that I'm able to log in to TCC from a desktop browser, but not from either Chrome or Safari on an iPad), and not only does the TCC web interface have the full location details there's also a field for timezone.

                                P.

                                Comment

                                Working...
                                X