S-Plan vs Y-Plan for Evohome ?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • DBMandrake
    Automated Home Legend
    • Sep 2014
    • 2361

    #76
    Hmm, this sounds eerily familiar....



    Especially the part about frequent updates after rebooting the CS92 (by re-inserting the batteries) which then over time taper off to infrequent updates...

    Reading that thread I wonder if there is something to one of my previously expressed theories after all - the theory of deliberate power saving through less transmission when battery voltage is low. If that's the case it might be worth trying lithium batteries instead of Alkaline in the CS92 because not only do they start at a significantly higher terminal voltage than Alkaline, they maintain a much more constant voltage during discharge whereas an Alkaline tends to fall progressively with use.

    So even though the CS92 no doubt only uses a tiny amount of power, the higher and flatter terminal voltage of a lithium might be beneficial, as it would tend to avoid any such low voltage power saving mode from being entered.

    Come to think of it I haven't even checked the voltage of the batteries that were shipped, but will do so tonight. And I might put it back to its original wall location but with Lithium's installed to see what happens.
    Last edited by DBMandrake; 22 November 2016, 02:37 PM.

    Comment

    • DBMandrake
      Automated Home Legend
      • Sep 2014
      • 2361

      #77
      Time for an update - I left the CS92 in the new wall location with the original batteries and it has worked nearly flawlessly for the last month. I say nearly because there were very rare occasions (twice I think, in a whole month) where I got an overshoot to 62 degrees. I believe these occasions were probably due to lost transmissions (comms errors, interference etc) rather than the CS92 deciding not send anything. Unfortunately I now have a loop transmitter in the same closet as the CS92 which operates on the same frequency band so this muddies the waters slightly in the event of rare transmission errors as I can't prove that it's not the loop to blame. But overall I was satisfied that it was working at about 99% reliability.

      Until yesterday, when I decided to increase my hot water temperature from 50 to 55, when it immediately started playing up again.

      The current measured temperature was 51 degrees when I went into the installer menu and changed hot water from 50 to 55. I then ran the hot tap for a few minutes to get it to drop down to about 49, at which point (due to my 5 degree differential) it kicked into heating mode.

      I happened to notice the reading on the controller creeping up from 49->50->51 and then stop at 51. Quite some time later (probably at least 20 minutes) I glanced at it again and saw it reading 62. Grr...

      My first suspicion was that although the hot water temperature was changed on the controller it did not for some reason communicate this change to the CS92, at least not in a timely fashion - therefore the CS92 stopped sending frequent updates after the temperature went past the old set point of 50 degrees.

      I also have a suspicion that there is a "safety threshold" programmed into the CS92 that causes it to ALWAYS send an immediate temperature measurement to the controller any time the water temperature goes past 62 degrees, regardless of what the set point is. This would probably be to ensure that the hot water can't get to a dangerous temperature, and 62 is slightly above the default hot water temperature of 60 degrees, so that makes sense.

      It's too much of a coincidence for the hot water to overshoot to exactly 62 every time overshoot has occurred, regardless of whether the hot water is set to 50 or 55.

      About an hour later I decided to conduct a test - I scheduled hot water off and left the hot tap running to completely use the hot water, (the reading dropped to about 13) I then turned hot water back on again and waited. Once again once the temperature reached about 45 I saw frequent temperature reading updates 45->46->47->48->49->50->51 and then no more updates past 51 for a long time then eventually it jumped from 51 to 62, so again, another overshoot to 62.

      I then rebooted the controller, and then the CS92 in that order and repeated the same test of draining the hot water and letting it heat up again. This time I didn't start to see frequent temperature updates until nearly 50 degrees, and saw readings of 50->51->52->53->54->55 and then the hot water switched off as expected.

      Since yesterday it has reheated to 55 degrees in normal use probably a dozen times without any problems, stopping on 55 or 56 every time.

      So my conclusions are:

      1) The CS92 definitely is made aware by the controller of what the hot water set point and differential is, and uses this information to send much more frequent updates when the temperature is changing within this range, especially as the temperature increases and the shut off temperature is reached. This is to avoid overshoots.

      2) There appears to be a hard coded safety threshold of 62 degrees whereby the CS92 always sends a temperature update when 62 is passed regardless of what the hot water set point is. This is why all the overshoots end up at 62 degrees and not some random high temperature.

      3) For some reason changing the hot water set point on the controller did NOT immediately inform the CS92 of the change - it perhaps either sends it much later (once a day ?) or only sends it once such that a comms error could cause it not to be received and then never update. Even an hour after I changed the setting the CS92 appears not to have registered the change.

      4) Rebooting the controller or the CS92 (I don't know which) forced the new hot water set point to be updated in the CS92. After this the system performed as expected. I didn't bother rebooting only one then testing then rebooting the other to verify which reboot helped, but I could do that I suppose if there was interest.

      Conclusion - it looks like there is a bug in the Evotouch that causes the CS92 not to be informed in a timely and reliable fashion of a new hot water set point when you change it, which can lead to overshoots to 62 degrees due to the two devices not agreeing on what the hot water set point is. Even if you only raised your set point a couple of degrees this situation could be triggered.

      The workaround is to reboot both the controller then the CS92 after changing your hot water temperature!
      Last edited by DBMandrake; 29 December 2016, 06:36 PM.

      Comment

      • paulockenden
        Automated Home Legend
        • Apr 2015
        • 1719

        #78
        I wonder whether simply turning the hot water off for a minute or so, then on again would negate having to reboot the device? I unspectacular that an off - on cycle will re-send the setpoint and differential.

        Comment

        • HenGus
          Automated Home Legend
          • May 2014
          • 1001

          #79
          Originally posted by paulockenden View Post
          I wonder whether simply turning the hot water off for a minute or so, then on again would negate having to reboot the device? I unspectacular that an off - on cycle will re-send the setpoint and differential.
          I have changed the HW temperature a number of times over the past 3 years - and the differential - and never had an issue with temperature overshoots. My present tank temperature is set at 62C as I have a temperamental thermostatic shower.

          Comment

          • DBMandrake
            Automated Home Legend
            • Sep 2014
            • 2361

            #80
            Originally posted by paulockenden View Post
            I wonder whether simply turning the hot water off for a minute or so, then on again would negate having to reboot the device? I unspectacular that an off - on cycle will re-send the setpoint and differential.
            Nope - as I described in my first test I scheduled hot water off for the period of time that I ran the tap to use all the hot water, (about 20 minutes) mainly to avoid the boiler from trying to heat it back up while I was trying to use it. I then scheduled hot water back on and it overshot to 62 degrees.

            Originally posted by HenGus View Post
            I have changed the HW temperature a number of times over the past 3 years - and the differential - and never had an issue with temperature overshoots. My present tank temperature is set at 62C as I have a temperamental thermostatic shower.
            Set at 62 degrees you wouldn't have an issue, because it seems the CS92 always sends an update at 62 degrees anyway.

            I'm not saying that this problem always happens when the hot water temperature is changed, and maybe eventually it would have sorted itself out. But there is definitely a case where changing the hot water temperature can lead to the controller and CS92 getting their set points out of step with each other, and this can lead to overshoots.

            Comment

            • HenGus
              Automated Home Legend
              • May 2014
              • 1001

              #81
              Originally posted by DBMandrake View Post
              Nope - as I described in my first test I scheduled hot water off for the period of time that I ran the tap to use all the hot water, (about 20 minutes) mainly to avoid the boiler from trying to heat it back up while I was trying to use it. I then scheduled hot water back on and it overshot to 62 degrees.


              Set at 62 degrees you wouldn't have an issue, because it seems the CS92 always sends an update at 62 degrees anyway.

              I'm not saying that this problem always happens when the hot water temperature is changed, and maybe eventually it would have sorted itself out. But there is definitely a case where changing the hot water temperature can lead to the controller and CS92 getting their set points out of step with each other, and this can lead to overshoots.
              I am not suggesting that you are wrong but it has never been an issue for me. Something to watch out for in the future though.

              Comment

              • DBMandrake
                Automated Home Legend
                • Sep 2014
                • 2361

                #82
                I thought I'd share a wiring change I just made to my S-Plan conversion a few days ago.

                Something I noticed when going to S-Plan a few months ago was that previously the Evohome would TPI modulate the boiler relay under low demand, and because I deliberately have a long pump overrun time (about 12 mins) so that the pump doesn't keep stopping and starting during every 10 minute TPI cycle, the water would continue to circulate constantly while there was at least some heat demand but assume a lower average flow temperature depending on the TPI duty cycle. This worked quite well to moderate the heat output from the radiators under times of low demand.

                However when I upgraded to S-Plan I realised that even on a three relay S-Plan configuration the Evohome also TPI modulates the heating zone valve relay in time with the boiler relay. So for example if there was only a 30% heating demand (and no hot water demand) the boiler relay and heating zone valve relay would both switch on 3 minutes, off 7 minutes etc. During this off period all water flow through radiators would stop and the pump overrun would be forced through the automatic bypass valve.

                I was sceptical of this at first and although it does work a lot better than I had expected, monitoring the system over time I have drawn the conclusion that constantly TPI modulating the heating zone valve like this is not a good idea and brings with it some problems. Specifically:

                1) Extra wear and tear on the zone valve - it is opening and closing every 10 minutes all day long, except when there is 100% or zero demand. If you only have a two BDR91 S-Plan install then you have no choice because the switch on the zone valve fires the boiler, so the zone valve HAS to be TPI modulated to modulate the boiler, however if you have a THREE relay configuration as I do there is actually no reason for the zone valve to keep opening and closing when the boiler can be separately modulated by the boiler relay.

                2) It tends to cause flow temperature spikes in the boiler heat exchanger that could lead to kettling/steam production when the flow temperature is set high. (And does in mine) Imagine the flow temperature is set to 75 and the boiler is firing. By coincidence just as it is reaching 75 degrees and the flow stat is about to turn it off the Evohome turns the boiler and heating zone valve relays off - the boiler goes off but the flow through the radiators is also blocked by the closed zone valve, now the ABV carries the entire flow. Latent heat will continue to flow from the heat exchanger into a small loop of water, after a minute or so this can spike up to about 82 degrees or so - and start producing small steam bubbles. If this only happened once when you shut the whole system off it wouldn't be a big deal, however if you keep doing this in every 10 minute cycle a lot of small steam bubbles can be generated and start going around the system making noise. (Crackling, gurgling etc)

                3) It's wasteful of the latent heat in the boilers heat exchanger - instead of being pumped around the radiators during the boiler off period it just circulates in the ABV loop at a very high temperature. If the valve to the radiators remained open the average flow temperature for a 30% duty cycle might be say 45 degrees, in which case the boiler piping etc is running at a lower temperature where there is less heat loss, however with the valve to the radiators closing the flow temperature through the boiler may remain at 75-80 degrees even when there is minimal demand from the radiators, thus more heat loss from the piping and casing near the boiler.

                4) Uneven distribution of heat to different radiators under low demand conditions. When the valve remains open a low duty cycle of the boiler results in a low average flow temperature, but by being continually circulated through all radiators that are flowing the temperature supplied to each radiator is fairly similar. (With the individual radiator valves then able to reduce the flow as necessary for that radiator) Also even if your pump speed is relatively low, there is enough time for the heat put into the water during the boiler on time to flow around all the radiators during the boiler off time.

                However if you modulate the heating zone valve the output temperature of the boiler remains high but the flow is intermittent. This means that radiators with a short length of pipe work have an unfair advantage over those with long runs. If it only flows for say one minute at a time, hot water may not reach a far away radiator at all in the same time that a near radiator gets hot. You're adding "delay" rather than dropping the average flow temperature. This problem will get worse if your pump speed is on the low side. (Also you may find you keep pumping hot water in short bursts that don't reach a far away radiator before the pipes cool down again) Once hot water does reach a radiator it will then tend to get hot quite quickly rather than assuming a more consistent but lower temperature.

                So I decided I wanted the heating zone valve to remain open and not be TPI modulated - at least when there was no hot water demand, bringing back the behaviour of the system before the S-Plan conversion. So how to go about it ?

                Possible approaches:

                1) Wire the heating zone valve to pump live. The zone valve will remain open any time the pump is running but will close when the pump stops and the system is off.

                Problem 1: When there is hot water demand the boiler relay will switch on constantly. If the boiler relay had previously been modulating at say 30% and the HR92's had all adjusted to account for this low average flow temperature it would result in a major room temperature overshoot for all active rooms during hot water demand as their effective flow temperature would jump way up without the HR92's expecting it.

                Problem 2: Hot water demand would cause any bypass radiators (towel rails etc) or radiators on manual TRV's to heat up, even if heating was scheduled off.

                2) Wire the heating zone valve to the hot water relay in a "hot water priority" configuration. This would close the heating zone valve every time there was hot water demand and basically turn your two 2 port zone valves into a diverter valve.

                Problem: OK perhaps if you have a fast re-heat cylinder, but for me if I run a bath and empty the cylinder the re-heat time is 25 minutes, or about 35 minutes including the bath running time, during which no radiators will get heat. Not a massive issue if they are already hot but if I were for example to turn the bathroom radiator on after I started running the bath it would be 35 minutes before it would start to heat...

                So what is needed is a hybrid approach. If you look at the behaviour of a three relay system you notice the following properties:

                If there is NO hot water demand the hot water relay stays off (naturally) and the boiler relay and heating relay's both modulate on and off together using TPI.

                If there is hot water demand the hot water relay AND the boiler relay stays on while the heating relay continues to TPI modulate based on heating demand.

                So what we want is the heating zone valve to stay open when there is no hot water demand, but TPI modulate when there is hot water demand.

                Originally I was going to do this with yet another MRT16-REM timer - but the volt free contact version would be required and I couldn't find one to buy anywhere as no-one stocks that variant.

                I was sure that it should be possible just by re-wiring the existing relays, by wiring the normally closed contact in the hot water relay to power the heating zone valve (as you do in a hot water priority configuration) but the sticking point was always how do I get the heating zone valve to close when the system is completely off, as it would always be on when the hot water relay was off....

                And then I had a Eureka moment - one of those where you can't believe you've been mulling a problem over in your head for months and didn't see the obvious answer Below is a simplified diagram of what I now have:



                (Continued)
                Last edited by DBMandrake; 27 November 2018, 09:46 PM. Reason: Fixed broken image link

                Comment

                • DBMandrake
                  Automated Home Legend
                  • Sep 2014
                  • 2361

                  #83
                  The insight that solved the problem was to obtain power for the relay contacts from the pump overrun timer - in other words tap into the pumps power supply. This solves the issue of how to turn off the heating zone valve when the system is completely off - after the pump overrun timer expires and the pump turns off there is no power to the relay contacts for heating or hot water relays, thus the two zone valves will close regardless of the state of the hot water or heating relays. There is absolutely no need for them to open when the pump is not running anyway so that is absolutely fine.

                  When the pump IS running, so long as the hot water relay is off, the heating zone valve will remain on, regardless of whether the heating relay is in the on or off position - thus TPI modulation of the heating zone valve is defeated. The system behaves like a heating only system with the boiler TPI modulated but the water always able to flow to the radiators.

                  However when the hot water relay is on, now the heating relay can modulate the heating zone valve on and off with TPI, as it normally does in an S-Plan configuration. This means that if there is no heating demand, hot water demand will not cause uncontrolled radiators to get hot, if there is 100% heating demand it will remain open and heat radiators and hot water together, and if there is a partial heating demand the TPI modulation of the heating zone valve will maintain some control over the heat transfer to the radiators to prevent an overshoot.

                  And it works beautifully. The average boiler flow temperature is now way down during low demand periods and rooms are overshooting a lot less frequently. The boiler casing and the boiler closet are now both a lot cooler on average. I now notice that during low demand periods radiators maintain a fairly consistent warm to the touch temperature (as they used to before the S-Plan conversion) instead of cycling between hotter and cold.

                  It should be obvious that this configuration is not possible with a two relay system, however I think it would work with an OpenTherm system with both heating and hot water relays and zone valves, as the OpenTherm interface only replaces the boiler relay.

                  Of course on some boilers the pump may be internally controlled - but it should still be possible to tap the power connection to the pump to supply the relay contacts. Another possible benefit of this wiring approach is reducing pump overrun time on systems where the pump overrun is temperature controlled instead of timed.

                  When the heating zone valve keeps closing the ABV loop will get very hot and stay hot for a long time - thus a long overrun time. However if the water continues to flow through the radiators the flow temperature will drop much more quickly when the boiler cycles off, thus a shorter pump overrun.

                  This modification in heating zone valve behaviour is also something that Honeywell could easily do in software - it would be really good if on a three relay (or OpenTherm + 2 relay) system there was an option to disable TPI modulation of the heating zone valve when there is no hot water demand. There seem to be many benefits and no drawbacks as far as I can see.
                  Last edited by DBMandrake; 16 January 2017, 01:29 PM.

                  Comment

                  • paulockenden
                    Automated Home Legend
                    • Apr 2015
                    • 1719

                    #84
                    Nice work.

                    And like you say, Honeywell could easily do this in software.

                    I've noticed the problems you write about when heating demand stops just as the boiler reaches a high flow temp. It's especially noticeable at schedule change points, but also happens as zones start to hit the proportional band.

                    Comment

                    • dty
                      Automated Home Ninja
                      • Aug 2016
                      • 489

                      #85
                      I'll be honest and say I didn't read your whole post(s)! Therefore I can't be sure if this is useful information...

                      I don't have a CH valve at all. I have EvoHome with DHW control. I have a DHW value, and every radiator (bar one) has a TRV on it (either HR92 or mechanical). Imagine an electrical circuit with +V at the top and GND at the bottom. The boiler is the battery. Between the +ve and -ve there are a bunch of bulbs (radiators) each with their own switches (TRVs), AND one slightly different bulb (DHW cylinder) with it's own slightly different switch (BDR91 controlled two-port valve).

                      So, if the pump is on, there is potential for the water to flow through the CH circuit if at least one TRV is open. Except in my case where I have an uncontrolled radiator which effectively acts as a heat-dump.

                      This does give me one problem - that rad is going to come on in the summer even when there's just DHW demand.

                      The reason for this setup? It's an old 1950s cottage with (literally) 6 or 7 extensions. Nobody is entirely sure where all the pipes go. Hence nobody can point at one single place where the DHW and the CH separate. I strongly doubt there is such a place.

                      Honeywell document this as in figure 4 on page 43 of the installation guide here: http://www.honeywelluk.com/Documents...on%20Guide.pdf

                      Now I've written all that, it probably doesn't help :-)

                      Comment

                      • dty
                        Automated Home Ninja
                        • Aug 2016
                        • 489

                        #86
                        Now I've read and thought a bit more, I think I've essentially got the same setup as you. Here's why...

                        Your system behaves as follows (when the pump is ON):

                        Code:
                        CH on  DHW on  CH valve  DHW valve
                        0      0       open                    <--- This being the clever bit
                        0      1                 open
                        1      0       open
                        1      1       open      open
                        Mine is the same, except my CH valve is also open on the second line (i.e. always, because I don't actually have one!). But the flow to the actual rads is controlled by the TRVs, so if there is DHW demand only then the TRVs will be closed and there will be no flow.

                        Comment

                        • paulockenden
                          Automated Home Legend
                          • Apr 2015
                          • 1719

                          #87
                          The clever bit of Simon's work is that the pump (partly) controls the valves, rather that the (usual) other way round. So the over-run gets used properly.

                          Comment

                          • dty
                            Automated Home Ninja
                            • Aug 2016
                            • 489

                            #88
                            I don't see the difference. During my pump overrun, water will be going around the CH provided TRVs are open. DBMandrake's setup is the same. His CH valve will be open, which is actually meaningless because there will be flow unless there are open TRVs.

                            Comment

                            • DBMandrake
                              Automated Home Legend
                              • Sep 2014
                              • 2361

                              #89
                              Originally posted by dty View Post
                              Now I've read and thought a bit more, I think I've essentially got the same setup as you. Here's why...

                              Your system behaves as follows (when the pump is ON):

                              Code:
                              CH on  DHW on  CH valve  DHW valve
                              0      0       open                    <--- This being the clever bit
                              0      1                 open
                              1      0       open
                              1      1       open      open
                              Mine is the same, except my CH valve is also open on the second line (i.e. always, because I don't actually have one!). But the flow to the actual rads is controlled by the TRVs, so if there is DHW demand only then the TRVs will be closed and there will be no flow.
                              Only if all your radiators have HR92's - not all mine do, and a lot of people have uncontrolled towel rails or a bypass radiator. Your system also won't cope as well when a hot water demand starts when there is a small heating demand - with no CH zone valve you'll get overshoot of the room temperatures because the HR92's will already be open quite wide and relying on a low flow temperature to get the right balance.

                              Originally posted by dty View Post
                              I don't see the difference. During my pump overrun, water will be going around the CH provided TRVs are open. DBMandrake's setup is the same. His CH valve will be open, which is actually meaningless because there will be flow unless there are open TRVs.
                              It's not meaningless at all - you've overlooked TPI modulation, which is the whole reason why I did the modification.

                              Radiator valves aren't just open or closed, they are most often in a partially open state. When there is a low system demand it works out that HR92 valves are most of the way open but the boiler is run at a low duty cycle to reduce total heat input to the radiators. In this condition the heating zone valve will be opening and closing every 10 minutes with a "standard" S-Plan configuration. This gives very different results than the heating zone valve remaining open constantly, or not having a heating zone valve.

                              The approach I've taken gives the best of both worlds - you get to avoid room temperature overshoot when hot water demand comes on and uncontrolled radiators heating up where there is only hot water demand, but on the other hand you get the lower average flow temperature and continuous flow of a system with no heating zone valve when there is no hot water demand.

                              Not only does this give better temperature control under light loads, it should in theory improve efficiency a bit when the system is running at minimum output - such as keeping one bedroom warm at night, as it allows the flow temperature to stay really low and continuously pumped to the radiator rather than the boiler flow temperature always staying near the high limit but only intermittently pumped to the radiators, and spending the rest of each cycle pumping around the automatic bypass loop dissipating energy in the boiler closet.
                              Last edited by DBMandrake; 16 January 2017, 11:08 PM.

                              Comment

                              • paulockenden
                                Automated Home Legend
                                • Apr 2015
                                • 1719

                                #90
                                The more I think about this the more I think it's brilliant.

                                Yes, part of it could be done in the controller firmware, but not tying it in to the boiler overrun like that.

                                The only downside I can see is that it's a more complicated install for a sparky. With the standard wiring the BDRs effectively just replace normal boiler controls. This now goes way beyond "connect the green wire to the brown wire".

                                Comment

                                Working...
                                X