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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Andehh
    Automated Home Sr Member
    • Oct 2015
    • 52

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

    I have a full Evohome setup, controls UFH and individual room rads.

    During the night, the pump (or could be the fan?) activates for 30 odd seconds or so, then quickly dies off and repeats this every ??-20minutes or so. The boiler does not fire - or didn't on the 3-4 cycles of this.

    The system isn't calling for heat (BDR91s are unlit for hot water/ CH) but the pipes in the airing cupboard are warm from the system firing up earlier in the night (as per normal)

    My son's room is kept at 17 degrees, and last night the room temperature was reading 17 degrees throughout the hour I spent scratching my head trying to work out why the boiler was activating the pump(?) or fan(?).

    Sticking my head in the airing cupboard sounded like water was being circulated, but as I said the boiler wasn't firing. The pipes were slightly warm so the system had been on the last 30mins properly.

    It did this 3-4 times before I eventually gave up and put a pillow over my head.


    --> Now, could this be because the room temp was flicking above/below the room stat at 17 degrees? This causing the boiler to start the ''fire up'' sequence, then the temp would rise slightly, causing he boiler to start the ''shut down'' sequence....before the temp would flicker again and the boiler would fire back up....BUT...Evohome's controls preventing the boiler from cycling too often was ''regulating'' these on/offs?

    How can I prevent this? Any suggestions on what could be causing it? Due to the boiler being near the bedroom these unwarranted activations are really bugging me at night.
  • DBMandrake
    Automated Home Legend
    • Sep 2014
    • 2361

    #2
    Originally posted by Andehh View Post
    I have a full Evohome setup, controls UFH and individual room rads.

    During the night, the pump (or could be the fan?) activates for 30 odd seconds or so, then quickly dies off and repeats this every ??-20minutes or so. The boiler does not fire - or didn't on the 3-4 cycles of this.

    The system isn't calling for heat (BDR91s are unlit for hot water/ CH) but the pipes in the airing cupboard are warm from the system firing up earlier in the night (as per normal)
    Some more details about your system would help - I assume you use S Plan ? Do you have two BDR91's or three ? EG, is the boiler fired by a 3rd BDR91 or is it fired using the limit switches on the zone valves ?

    Is your pump powered directly from the boiler with an internal pump overrun or is your pump externally connected perhaps with its own overrun timer ?

    If the BDR91's are not turning on and the boiler is not firing I can't really see how the Evohome would be the cause - because if the relays came on the boiler would fire too. If the relays are definitely coming on it must be something else.

    Could it be frost protection of the boiler kicking in and circulating the pump ? In some systems air temperature below 5 degrees in the boiler is used to trigger frost protection and the return flow temperature is used as a shut off - so when the boiler gets too cold it fires and keeps running until the return pipe reaches typically 30 degrees then shuts off again. This would all happen without the BDR91's being involved.
    My son's room is kept at 17 degrees, and last night the room temperature was reading 17 degrees throughout the hour I spent scratching my head trying to work out why the boiler was activating the pump(?) or fan(?).

    Sticking my head in the airing cupboard sounded like water was being circulated, but as I said the boiler wasn't firing. The pipes were slightly warm so the system had been on the last 30mins properly.

    It did this 3-4 times before I eventually gave up and put a pillow over my head.

    --> Now, could this be because the room temp was flicking above/below the room stat at 17 degrees? This causing the boiler to start the ''fire up'' sequence, then the temp would rise slightly, causing he boiler to start the ''shut down'' sequence....before the temp would flicker again and the boiler would fire back up....BUT...Evohome's controls preventing the boiler from cycling too often was ''regulating'' these on/offs?

    Are you sure that the BDR91's weren't coming on for a short period ? In case you aren't aware, the BDR91's use TPI (time proportional integral) to control the boiler.

    This means that the boiler will be operated at a reduced duty cycle when heat demand is low, this lowers the average flow temperature. The default cycle time is 10 minutes (6 firings per hour in the installer menu setup) and a minimum on time of 1 minute. So depending on demand it could run for anything between 1 and 10 minutes per 10 minute cycle. (Or not at all)

    This means that if there is a small heat demand (such as keeping a bedroom at 17 degrees at night) the boiler may in fact be firing for about 1 minute in every 10 minute period, and you may have just not noticed this. For some of the remainder of the 10 minute cycle your pump may be running in pump overrun. You would have to watch the relay for a full 10 minutes to confirm whether this was the case.

    If this was happening then I'd say this is probably normal and it is doing its job to maintain 17 degrees in your sons room. Was the bedroom radiator warm to the touch by any chance ?

    The evohome system doesn't work on a simplistic "if the temperature is below 17 degrees turn on the radiator and if its above turn it off". It's a fully proportional and adaptive system that will make small adjustments to both the boiler duty cycle and the radiator valve opening to achieve a constant steady set point by warming the radiator up just enough, rather than cycling the temperature above and below the set point by turning the radiator full on and off as a conventional thermostat would.

    Just because the temperature is 17 degrees or even slightly above does not mean that the radiator does not need to be warm to maintain that 17 degrees - if there is heat loss from the room then a small amount of heat must constantly be put into the room to maintain a steady 17 degrees, and that is exactly what it will try to do.
    How can I prevent this? Any suggestions on what could be causing it? Due to the boiler being near the bedroom these unwarranted activations are really bugging me at night.
    But are the activation's really unwarranted if heat is required to keep your sons bedroom at 17 degrees ? Do they stop if you drop the set point in your sons room a few degrees ? (try this next time they happen) If they do, then the system is behaving as designed to maintain that 17 degree set point.

    Comment

    • Andehh
      Automated Home Sr Member
      • Oct 2015
      • 52

      #3
      Thank you very much for your detailed reply!

      It is a S plan, with 2 x BDR91s one for heating one for hot water. I believe these control the motorised valve that triggers the boiler - but I may be wrong on that!

      The system works as intended to be honest, it does a very good job.

      The Boiler has the system pump within it, and yes the radiator in Son's room was warm - and seemed to stay relatively warm for the entire duration of my nights ''investigation''.

      I think you are entirely right in the sense that I underestimated the Evohome system in how it manages a room temperature. I envisaged it sensing a room temp drop, turning on boiler, opening the rad valve and effectively ''nuking'' the rad in that one room to boost the temp and continue doing so until that room hit required temp & then it would shut off and let it overshoot & then slowly drop down.

      I didnt realise Evohome was quite so good with micromanaging the rad temperature to maintain an even/exact room temp. I did wonder why his room stayed firmly on 17 degree the entire time.


      edit to add; For the upstairs and downstairs hallway rads, and upstairs toilet rads, we keep these unregulated so that any demand for heat warms them up as well - just to keep a reasonable temp throughout the house on very cold nights. I presume this means that the boiler just adds a tiny bit more hot water into the system as it compensates for the fact that Son's radiator needs 'X amount of warmth', but the rest of the rads in the house are draining that 'X-1' warmth already? It therefore adds on +1 heat to compensate? If that makes any sense...
      Last edited by Andehh; 20 October 2016, 01:40 PM.

      Comment

      • DBMandrake
        Automated Home Legend
        • Sep 2014
        • 2361

        #4
        Originally posted by Andehh View Post
        Thank you very much for your detailed reply!

        It is a S plan, with 2 x BDR91s one for heating one for hot water. I believe these control the motorised valve that triggers the boiler - but I may be wrong on that!

        The system works as intended to be honest, it does a very good job.

        The Boiler has the system pump within it, and yes the radiator in Son's room was warm - and seemed to stay relatively warm for the entire duration of my nights ''investigation''.

        I think you are entirely right in the sense that I underestimated the Evohome system in how it manages a room temperature. I envisaged it sensing a room temp drop, turning on boiler, opening the rad valve and effectively ''nuking'' the rad in that one room to boost the temp and continue doing so until that room hit required temp & then it would shut off and let it overshoot & then slowly drop down.

        I didnt realise Evohome was quite so good with micromanaging the rad temperature to maintain an even/exact room temp. I did wonder why his room stayed firmly on 17 degree the entire time.
        Yes it's very good at making small adjustments to the heat output of the radiators to find a balance where the radiator heat equals the heat loss, thus the room stays at a constant temperature without the normal large up and down temperature swings of a thermostat that turns the system right off and fully on again. Even conventional manual TRV's which in theory are a proportional controller tend to over-react and thus cause the radiator to cycle between too cold and too hot.

        It can't always achieve this depending on the conditions, sometimes the temperature may cycle up and down slightly, this can happen if your flow temperature is too high or you have very low heat loss in your house, (or the weather just isn't properly cold yet) but more often than not it will find a stable balance where the temperature doesn't fluctuate significantly.

        When the overall system demand is high (many radiators requiring heat) it will tend to run the boiler at a high duty cycle (and thus high average flow temperatures in the pipes) and adjust the valves on the radiators of rooms that don't need much heat right down so they are only just flowing, to find the right balance, however when the total system demand is low due to only one or two radiators needing heat (like bedrooms at night time set to a low temperature) it instead opens the valve on that radiator fairly wide but cycles the boiler on infrequently so you get a very low average flow temperature. This is the most efficient way to get your boiler to produce only a small amount of heat for a single radiator, and also gives very fine control of temperature as the radiator panel is only warm.
        edit to add; For the upstairs and downstairs hallway rads, and upstairs toilet rads, we keep these unregulated so that any demand for heat warms them up as well - just to keep a reasonable temp throughout the house on very cold nights. I presume this means that the boiler just adds a tiny bit more hot water into the system as it compensates for the fact that Son's radiator needs 'X amount of warmth', but the rest of the rads in the house are draining that 'X-1' warmth already? It therefore adds on +1 heat to compensate? If that makes any sense...
        If you have some uncontrolled radiators that piggy back on any calls for heat they will also warm up a small amount.

        They will act as a "vampire" load that the Evohome is not aware of (since there are no HR92's on them) which means the boiler duty cycle would have to be greater to achieve the same radiator surface temperature in your sons room due to the additional radiators taking their share of the boilers heat.

        This will be compensated for automatically though - as the Evohome will just keep slowly increasing the boilers duty cycle until the bedroom can maintain the target temperature - it doesn't care what the specific duty cycle is, it only knows to increase or decrease it, so it will adapt to the vampire loads.

        If you use OpenTherm instead of a BDR91 it doesn't even have to adapt - it just asks the boiler for a specific flow temperature and it's the job of the boiler to deliver this, no matter whether there is one radiator or 4 drawing heat! So the same specific flow temperature would be correct for the bedroom regardless of how many other uncontrolled radiators are piggybacking on the heat demand.
        Last edited by DBMandrake; 20 October 2016, 11:14 PM.

        Comment

        • bruce_miranda
          Automated Home Legend
          • Jul 2014
          • 2307

          #5
          Originally posted by DBMandrake View Post
          If you use OpenTherm instead of a BDR91 it doesn't even have to adapt - it just asks the boiler for a specific flow temperature and it's the job of the boiler to deliver this, no matter whether there is one radiator or 4 drawing heat! So the same specific flow temperature would be correct for the bedroom regardless of how many other uncontrolled radiators are piggybacking on the heat demand.
          This is the system I have, deliberately. I kept the two towel rails in the bathrooms without any TRVs. We leave the bathroom windows open a lot. We have the HRxx on every other radiator. With the Opentherm the boiler is not bothered about the two towel rails. But that keeps the towels nice and dry whenever there is any other heat demand. The only downside is that the bathrooms cannot demand their own heat, but we have never ever found the bathrooms to be too cold. So this configuration works for us. I also didn't like ugly (there, I said it!) white plastic controllers on our shiny stainless steel towel rails.

          Comment

          • g6ejd
            Automated Home Guru
            • Oct 2016
            • 153

            #6
            I've got a problem:

            Well, I solved my repetitive communication faults that occurred every day at 17:19 (Fault) and then 20:39 (Restored), it appears to be because I had bound one boiler BDR also under Boiler Relay setup, having already used the guided configuration to add HW control where it asked me to bind the CS92, then HW BDR then finally boiler BDR. System appeared to work normally until last night!

            OK, so I did the full reset routine, factory reset, then batteries out, then reset all HR92 and cleared the BDR91 bindings, then started again and only adding the BDR's via the guided installation using HW, this added the CS92, then HW BDR then finally HTG BDR, all worked OK. But at 23:00 last night the HTG BDR continued to cycle on/off every 10-mins, coincident with the cycle setting of 6-cycles / hour, maybe.

            At 23:00 the schedule sets all the zones to 15°C and just prior to this all zones were at their set temperatures of about 20°C and until then all was working as expected. But, the cycling of the BDR kept going for (10-mins then on for about 1-min) for an hour or so that I let it, then I decided to see if the Quick Action function would stop it, yes it did using the Economy function. Having confirmed that by waiting more than 10-mins, I then switched it off (resumed the schedule) and everything was back to normal.

            So this morning thinking the HTG BDR was not being controlled correctly, I enabled Boiler Control and bound the HTG BDR to that function, previously it said disabled. But the communication errors had returned (at least I can now replicate that condition), so I have now disabled that again and normal operation resumed and no communication errors.

            I just called Honeywell and explained the problem with BDR cycling after the schedule has reduced all rooms to a night-time 15°C and they weren't that fussed, they said the system was working normally and it might take a couple of days for the system to normalise, but if I'm getting a lot of inefficiency by the system doing this, I should call them back and they will open a call-log and refer the problem to the second-line support, so that's what I'm going to do.
            Last edited by g6ejd; 25 October 2016, 02:20 PM.

            Comment

            • g6ejd
              Automated Home Guru
              • Oct 2016
              • 153

              #7
              Update: the system did not cycle last night when the scheduled temperatures reduced to 15°C, unlike the last two nights, what's different? Under Optimisation I enabled 'Optimum Stop'

              Comment

              • DBMandrake
                Automated Home Legend
                • Sep 2014
                • 2361

                #8
                Originally posted by g6ejd View Post
                I've got a problem:

                Well, I solved my repetitive communication faults that occurred every day at 17:19 (Fault) and then 20:39 (Restored), it appears to be because I had bound one boiler BDR also under Boiler Relay setup, having already used the guided configuration to add HW control where it asked me to bind the CS92, then HW BDR then finally boiler BDR. System appeared to work normally until last night!
                Double binding a BDR91 will inevitably cause comms faults to be reported, but interestingly, doesn't seem to affect the proper functioning of the system.

                Back when I first got the Evohome I only had one HR92 (the HR92 was actually fitted a few months before the Evotouch!) which was in the living room and the Evotouch was on the wall in the hallway. I was trying to be a smarty pants and had set up a "zone valve" zone for the hallway with the Evotouch as the temperature sensor.

                I bound the "zone valve" for this zone to the same BDR91 as the boiler relay function. BDR91's are designed to be able to bind up to four devices, presumably different room stats when you have a simple wireless room stat and BDR91 combination. You are not supposed to do these multiple bindings in an Evohome configuration though, and it seems to be the cause of a lot of people's problems.

                For the first 4-5 days it worked fine - the HR92 could call for heat, and so could the hallway with no HR92. However I then started getting comms faults every 3 hours complaining that the boiler relay was not functioning properly, despite the relay continuing to function just fine. No matter how many ways I tried to reconfigure and rebind things I could not get it to work without comms errors so I gave in and got an HR92 for the hallway - problem solved.

                I've recently been wondering why double binding a BDR91 can cause comms faults when the relay is actually designed to support up to 4 bindings and I have a theory of what may be happening, and that it's the way that the Evotouch is programmed to interact with a BDR91.

                I think it is part of the "2 way" communication that Honeywell talks about. When the Evotouch sends a heat demand change to the BDR91 configured as a boiler relay, I don't think that it gets an immediate acknowledgement like you would on say a TCP connection where everything must be acknowledged to confirm reception, however I think that a periodic "verification" of the state of the relay is performed by asking the relay to respond with its current TPI status.

                So for example maybe it sends a heat demand change every 4 minutes, then once say every 30 minutes asks the relay "what is your current status", and if it doesn't match the expected status enough times over a 3 hour period a comms fault is reported. So not every update sent is acknowledged on an individual basis but it does a periodic sanity check to see that the BDR91 is following orders over time.

                I can switch the power off to the BDR91 for nearly an hour then back on again (during boiler work) and not get any comms errors logged so the checks must be either fairly infrequent or fairly tolerant of incorrect or missing responses before a fault is logged.

                So what happens if we add another binding to the BDR91, such as a zone valve binding or accidental heating zone valve binding ? Now it will respond to two sets of heat demands, and operate TPI under some combination of those two heat demands. (Perhaps just the higher of the two)

                Now when the Evotouch asks for its periodic status check from the relay it doesn't get back the boiler demand that it is expecting, (maybe it gets back ON when it's expecting to see OFF for the boiler relay) because the other binding may have asked for a different heat demand that the relay is following, thus a comms error is flagged.

                This is just a theory, we'd need to look at HGI80 packet dumps to figure out what is really going on.


                OK, so I did the full reset routine, factory reset, then batteries out, then reset all HR92 and cleared the BDR91 bindings, then started again and only adding the BDR's via the guided installation using HW, this added the CS92, then HW BDR then finally HTG BDR, all worked OK. But at 23:00 last night the HTG BDR continued to cycle on/off every 10-mins, coincident with the cycle setting of 6-cycles / hour, maybe.
                Do you have failsafe mode enabled ?
                At 23:00 the schedule sets all the zones to 15°C and just prior to this all zones were at their set temperatures of about 20°C and until then all was working as expected. But, the cycling of the BDR kept going for (10-mins then on for about 1-min) for an hour or so that I let it, then I decided to see if the Quick Action function would stop it, yes it did using the Economy function. Having confirmed that by waiting more than 10-mins, I then switched it off (resumed the schedule) and everything was back to normal.

                So this morning thinking the HTG BDR was not being controlled correctly, I enabled Boiler Control and bound the HTG BDR to that function, previously it said disabled. But the communication errors had returned (at least I can now replicate that condition), so I have now disabled that again and normal operation resumed and no communication errors.
                Definitely don't bind boiler relay and heating relay functions to the same BDR91 - see above. It will cause problems.
                I just called Honeywell and explained the problem with BDR cycling after the schedule has reduced all rooms to a night-time 15°C and they weren't that fussed, they said the system was working normally and it might take a couple of days for the system to normalise, but if I'm getting a lot of inefficiency by the system doing this, I should call them back and they will open a call-log and refer the problem to the second-line support, so that's what I'm going to do.
                If all your set points are at least 2 degrees below the current room temperatures then after a few minutes the BDR91 should be off and stay off. If it keeps cycling on periodically you have either a configuration error or some sort of comms fault. There's nothing normal about what you describe.

                Originally posted by g6ejd View Post
                Update: the system did not cycle last night when the scheduled temperatures reduced to 15°C, unlike the last two nights, what's different? Under Optimisation I enabled 'Optimum Stop'
                I'm almost certain that is only a coincidence. All that Optimum stop does is when you have a lower set point scheduled after a higher set point it will switch to the lower set point earlier than the scheduled time. However this will be shown on the display.

                Optimum stop tries to go to the next (lower) set point as soon as possible without the temperature dropping more than 0.5 degrees below the current set point before the end of the current set point's time period. It will do this adaptively depending on the current temperature and how long it will take the temperature to drop.

                So say you go from 20 degress at 6pm to 18 degrees at 8pm, some time between 6pm and 8pm it will change the set point to 18 degrees early - as early as it can so that the room falls to 19.5 degrees at 8pm. If the current temperature is increasing or is above the set point it can drop the set point really early (I've seen up to an hour early) but if the current temperature is below the target it may not drop the set point early at all.
                Last edited by DBMandrake; 26 October 2016, 05:17 PM.

                Comment

                • g6ejd
                  Automated Home Guru
                  • Oct 2016
                  • 153

                  #9
                  Thanks for the detailed analysis and response.

                  Honeywell told me the cause of the cycling was the TPI function, that 'modulates' the boiler demand to a wide mark-space ratio of On/Off and at the end of the day when room temperatures are at demand temperature this is what the TPI algorithm normally does, makes sense. Then the schedule reduces the demand temperatures down, in my case from 20° to 15°C, actually some are 14°C, but what's different is all zones are sent a go to 15°C command sometime before their normal shut-off times and this seems to ensure there will be no residual demand, importantly though before the scheduled cut-off. Last night they were all at 15°C rather than some at 15 and some at 14. I was not expecting that, more that temperatures would be at the scheduled temperatures rather than the default 15.

                  Tonight will be a confirmation test. Also Honeywell said the cycling is part of the TPI learning processing and takes about 2-days to stabilise, well switching to the more normal (for me) PID analysis, I can see the Integral element having a very long time constant, perhaps days as it determines the thermal characteristics of the property and I expect the TPI method to be doing the same - that's my theory of operation anyway.

                  Yes, I have fail-safe off. What surprised me was when I reset the controller and during the time it took to walk downstairs, I heard a HR92 actuate and shortly thereafter the heating came on, that made me think the HR92's and BDR91 can operate autonomously from the Controller (I'd just reset it) , but again I think an explanation of these functions is missing to be really sure how it's supposed to work.
                  Last edited by g6ejd; 26 October 2016, 05:31 PM.

                  Comment

                  • DBMandrake
                    Automated Home Legend
                    • Sep 2014
                    • 2361

                    #10
                    Honeywell told me the cause of the cycling was the TPI function, that 'modulates' the boiler demand to a wide mark-space ratio of On/Off and at the end of the day when room temperatures are at demand temperature this is what the TPI algorithm normally does, makes sense.
                    The BDR91 uses TPI control of the boiler for low heat demands. The default 6 firings per hour setting gives you a 10 minute TPI cycle time. There is a minimum on-time setting which defaults to 1 minute.

                    In each 10 minute cycle with a 1 minute minimum on time the boiler can fire anywhere between 1 minute and a full 10 minutes. If the heat demand would be less than the minimum on time then the boiler is not fired at all for that 10 minute cycle.

                    When you do not use a boiler relay (eg you have an S-Plan system with only hot water and heating relays but no 3rd boiler relay) there is supposedly no minimum on time enforced. If you use a 2 relay config you also can't modify the cycles per hour or minimum on time as they're hidden in the UI.

                    HR92's have a +/- 1.5 degree proportional band. If a zone is at least 1.5 degrees above the set point the demand it sends will always be zero and it should not trigger any boiler demand. So if all zones are at least 1.5 degrees above their set points there should be no system demand and the boiler should go off completely.

                    Because the displayed temperature is rounded to 0.5 degrees and then biased up to 0.5 degrees towards the set point this complicates observations, so for rule of thumb I use 2 degrees. If the temperature of any zone is at least 1.5 degrees (2 degrees rule of thumb) below the set point that HR92 will send a 100% heat demand and the boiler will run continuously.

                    When all HR92's are either in their +/- 1.5 degree proportional band or the ones that are not are in the "off" region, (set point at least 1.5 degrees below current) then the boiler will fire intermittently using TPI.
                    Then the schedule reduces the demand temperatures down, in my case from 20° to 15°C, actually some are 14°C, but what's different is all zones are sent a go to 15°C command sometime before their normal shut-off times and this seems to ensure there will be no residual demand, importantly though before the scheduled cut-off.
                    What you describe there is optimal stop. It will drop the set points early if it thinks that the temperature won't drop more than half a degree below the current set point before the next set point is due to take effect.
                    Tonight will be a confirmation test. Also Honeywell said the cycling is part of the TPI learning processing and takes about 2-days to stabilise, well switching to the more normal (for me) PID analysis, I can see the Integral element having a very long time constant, perhaps days as it determines the thermal characteristics of the property and I expect the TPI method to be doing the same - that's my theory of operation anyway.
                    The HR92's are indeed at the very least a PI controller, and might be a full PID controller. It's hard to tell from observation whether there is a standard differential term in their control loop - they do seem to predicatively throttle back the radiator valve before the target if it would otherwise result in an overshoot. (Since radiators heat quickly but cool very slowly and thus keep radiating heat long after closed)

                    For example if I place a towel permanently over our bedroom radiator - which slows the rate of temperature rise in the room it will initially "undershoot" the target during a warm up phase, and will take a couple of days to adapt to this, and will then start hitting the target without overshoot on my graphs. If I then remove the towel it will overshoot a couple of degrees at the same set point the following day but then the day after that it will hit the target spot on without overshoot.

                    So it has some sort of predictive early closing of the valve, (I've seen it completely close the valve more than 1 degree before the set point in rooms that heat quickly) but it might not necessarily be a conventional PID differential term, as it seems to adapt much quicker to overshoot than undershoot. This differential adaption seems to take anywhere from a day to a few days to adapt to the thermal characteristics of the room.

                    The integral action is quite obvious to see on the graphs, and seems to adapt a lot quicker. Since the integral term corrects for offset error, if the heat loss changes dramatically (like a sudden swing in outside temperatures) the heat demand to maintain a specific temperature might be very different - you can see the temperature is consistently a bit above or below the target at first but after approximately 2 hours or so it adapts to a one degree offset error. So the integral learning period seems to be in the order of only a few hours for a significant shift.

                    It's also worth pointing out that the intelligence of the adaption and learning on the Evohome is actually distributed between the HR92's and the controller - there is actually two different sets of learning going on after initial setup and on an ongoing basis.

                    One is the HR92 itself is as described above, a standalone PID (or maybe PI) controller with self tuning heuristics, this allows it to both correct for offset error (by tuning the integral term) and tune out overshoot or undershoot during step changes in set point, especially increases in set point. (by tuning the differential term, or some other predictive factor)

                    It's important to make clear (because a lot of people make a wrong assumption about this) that this PID controller self tuning and learning is absolutely nothing to do with Optimal Start or Optimal Stop, and is not done by the controller. It takes place whether Optimal Start/Stop are enabled or not, or even if the HR92 is not bound to a controller.

                    All the controller does in relation to this is pass the HR92 regular room temperature readings from the room temperature sensor and pass it set point changes.

                    The other part of the learning process is the optional Optimal Start and Optimal Stop features, these are handled by the Evotouch controller itself.

                    Optimal Start applies when a low set point is followed by a high set point. The aim of it is to predict how early the set point must be changed to meet the target temperature at the target time. Two factors need to be known to do this - the temperature difference to be made up (for example heating from a current room temperature of 14 degrees to a set point of 20 degrees) and how quickly the room warms up.

                    The temperature difference it knows immediately - it will adapt to changes in starting temperature immediately and increase or decrease the lead time as required. Changes in warm up rate of the room take longer to adapt to, and can have many causes like doors being open instead of closed, outside temperatures, radiators being covered or not, furniture being moved and so on.

                    It seems to be fairly slow to adapt to large changes here - on the order of several days, and this is probably what most people are talking about when they say it takes up to a week or so for it to adapt to your house.

                    Observation suggest that it starts with an approximation of about 3 degrees rise per hour, and then tunes from there. It seems to make a change in the start time of at most about 15 minutes per day, so if it is consistently getting a room warm an hour early it will start later and later each day by about 15 minutes until it finds the right start time for a given set point.

                    This is all done by the controller and it does it simply by changing the time that it sends the set point change to the HR92's in the zone.
                    Yes, I have fail-safe off. What surprised me was when I reset the controller and during the time it took to walk downstairs, I heard a HR92 actuate and shortly thereafter the heating came on, that made me think the HR92's and BDR91 can operate autonomously from the Controller (I'd just reset it) , but again I think an explanation of these functions is missing to be really sure how it's supposed to work.
                    As far as I know (and I'm not 100% certain, but fairly sure) there is no direct communication between HR92's and BDR91's.

                    The wireless communication is a star configuration with the controller at the centre. All heat demands from HR92's are passed to the controller, aggregated and passed to the BDR relays.

                    Keep in mind that even if the controller goes offline HR92's will all still keep working autonomously - they will continue to adjust their radiator valves to maintain the room at their last set point.

                    I believe that after a period of time with no temperature readings being received from the controller each HR92 will fall back to using its own internal temperature sensor. I'm not sure how long this takes (probably at least 30 minutes) and have not done any scientific testing to verify this more than anecdotally, but I intend to at some point.

                    BDR91's will continue their existing TPI cycle for some period of time after the controller goes offline, again I'm not sure how long exactly. So what you observed was an HR92 continuing to make adjustments to the radiator valve and a BDR91 following its last known heat demand figure.

                    After some period of time with no communications the BDR91 will drop back to staying off (failsafe off) or start running at a 20% on duty cycle (failsafe on) even if prior to that there was zero heat demand. EG loss of communications would cause an already off boiler to start cycling on.

                    So in a failsafe on configuration if the controller died the boiler would run at 20% duty cycle and all HR92's would continue to regulate their last known set points, and thus provide frost protection even though there is no central controller to coordinate things. Room temperatures could still be manually controlled at HR92's, although you might have to switch the boiler to constant to actually meet the target set points.
                    Last edited by DBMandrake; 26 October 2016, 08:47 PM.

                    Comment

                    • g6ejd
                      Automated Home Guru
                      • Oct 2016
                      • 153

                      #11
                      No cycling tonight, I think it's now stable and tomorrow I will turn off Optimum Stop and then if the cycling does not return I have a near default system and it has stabilised as Honeywell said it would after about 2-days.

                      Comment

                      • g6ejd
                        Automated Home Guru
                        • Oct 2016
                        • 153

                        #12
                        No the cycling has returned because I switched off Optimum Stop. I checked the schedule versus the room and HR92 displayed temperatures and the minimum temperature difference was 4'C maximum 6'C at 23:00 when all zones go to 15'C.

                        The BDR91 continued to demand heat with no load/radiator/HR92 demanding heat, actually tonight is relatively mild here and the heating was not running at ~22:30.

                        I observed this behaviour for 2 random cycles then switched the Optimum Stop back on and it's stopped.

                        I'm running the 1.03 Firmware...and I now think there's a problem with this version.
                        Last edited by g6ejd; 27 October 2016, 11:24 PM.

                        Comment

                        • DBMandrake
                          Automated Home Legend
                          • Sep 2014
                          • 2361

                          #13
                          Hmm.

                          So when the boiler was still cycling you went around the house and manually checked the set point on each HR92 ?

                          If they were all set 4 degrees or more below current measured temperatures there should definitely be no demand.

                          I still can't see how it could be related to optimum stop because all optimum stop does is send the lower set point to the HR92's sooner than the scheduled time. There is no other "magic" involved and it has no impact on how HR92's send their heat demands...

                          Could be a bug I suppose. Have you tried a controller reboot ? Soon after switching to an S-Plan configuration with three relays I too noticed the boiler relay cycling on and off with no demand from HR92's (yes I ran around the house and checked - they were all set to 5 degrees) and it kept doing this until I did a reboot of the controller.

                          After that it was OK, so I'm going to suspect a bug in the firmware that perhaps causes it to get confused after BDR91 bindings are changed or reconfigured. Try turning Optimal Stop back off, give it a couple of minutes then reboot the controller - see if that helps.

                          There is some anecdotal evidence that certain types of system reconfiguration must be followed up by a controller reboot to ensure everything works correctly. In fact recommended advice from the evohomeshop when rebinding devices especially BDR's is to remove all the bindings first, reboot the controller then re-add them!
                          Last edited by DBMandrake; 27 October 2016, 11:56 PM.

                          Comment

                          • paulockenden
                            Automated Home Legend
                            • Apr 2015
                            • 1719

                            #14
                            It could also just be system delays.

                            At the set point the hr92 will change its demand on the boiler. But this is sent upstream to the controller first which aggregates the demand from the various actuators in the system, and that can take a few minutes as they all drop off.

                            I wonder whether that's what you are seeing?

                            Comment

                            • DBMandrake
                              Automated Home Legend
                              • Sep 2014
                              • 2361

                              #15
                              In my experience the only big delay in shutting down the system is the up to 4 minute delay in the controller sending a set point change to all the HR92's.

                              Changes in heat demand from HR92's are sent almost immediately and forwarded on by the controller almost immediately as well.

                              Typically it takes only about 3 seconds for a heat demand to be forwarded all the way through to the boiler relay, although the HR92 will not send the new heat demand until it has finished rotating its valve - so if the valve is turning from one extreme position to the other instead of an incremental movement there can be an extra delay of about 30 seconds while the valve turns before the new demand is sent. So 4 minutes 30 seconds is the longest it should ever take for the boiler to shut down after a heating off quick action or scheduled drop in all rooms.

                              When testing response time keep in mind TPI can cause an apparent delay in response for changes between partial heat demands of up to 10 minutes depending on where you are in the current TPI cycle. So if you just turn a room up by 1 degree it will still be a partial demand which means the relay may not react immediately to the different heat demand.

                              However if you go from zero demand to full demand or vica versa there is no TPI induced delay and you will observe that the response time is about 3 seconds after the HR92 finishes turning its valve.

                              Comment

                              Working...
                              X