Boiler with separate HW and CH max and OpenTherm

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • top brake
    Automated Home Legend
    • Feb 2015
    • 837

    #16
    indeed, outside of proportional band the controller wants to get the temperature up as soon as possible, then modulates within.
    this is normal
    I work for Resideo, posts are personal and my own views.

    Comment

    • Dan_Robinson
      Automated Home Ninja
      • Jun 2012
      • 347

      #17
      Originally posted by top brake View Post
      indeed, outside of proportional band the controller wants to get the temperature up as soon as possible, then modulates within.
      this is normal


      Yes, but it isn't very efficient with a condensing boiler. Notwithstanding the proportional band is too small for modern boilers anyway. Hammering the heating with 75 degree flow is not going to help the boiler condense. Most heating systems are perfectly well serviced with 65 degrees flow temperature even in the coldest winters.

      But this is where hot water priority and dual flow temperatures come into their own.

      Easy enough to achieve with Intergas and I think Ideal Vogues. Not possible with Viessmann and Vaillant without using their own proprietary controls, which, whilst work the boilers "perfectly", give most users an attack of the vapours when it comes to interacting with them.

      It would be nice for Bruce to clarify is intentions with this line of thought though.


      Going back to the proportional band of the OT - it really should be set to kick in at a lower threshold. 2 degrees, maybe even 2.5 degrees. Especially in modern buildings with decent insulation. The thermal inertia of the system will keep a closer rein on setpoint and ambient temperature levels.
      Kind Regards - Dan Robinson (Jennings Heating Ltd)

      Comment

      • top brake
        Automated Home Legend
        • Feb 2015
        • 837

        #18
        Originally posted by Dan_Robinson View Post
        Yes, but it isn't very efficient with a condensing boiler. Notwithstanding the proportional band is too small for modern boilers anyway. Hammering the heating with 75 degree flow is not going to help the boiler condense. Most heating systems are perfectly well serviced with 65 degrees flow temperature even in the coldest winters.

        But this is where hot water priority and dual flow temperatures come into their own.

        Easy enough to achieve with Intergas and I think Ideal Vogues. Not possible with Viessmann and Vaillant without using their own proprietary controls, which, whilst work the boilers "perfectly", give most users an attack of the vapours when it comes to interacting with them.

        It would be nice for Bruce to clarify is intentions with this line of thought though.


        Going back to the proportional band of the OT - it really should be set to kick in at a lower threshold. 2 degrees, maybe even 2.5 degrees. Especially in modern buildings with decent insulation. The thermal inertia of the system will keep a closer rein on setpoint and ambient temperature levels.
        flow temperature is only one element of the room temperature control remember, % opening of the HR92 is also a big factor in controlling zone temperatures.

        the third element is the optimum start algorithm.

        i think the concern about control band width is largely notional and given time the fuzzy logic control algorithm will adapt.
        an unscheduled large setpoint adjustment will naturally result in a higher flow temperature being required.
        I work for Resideo, posts are personal and my own views.

        Comment

        • Dan_Robinson
          Automated Home Ninja
          • Jun 2012
          • 347

          #19
          It's still akin to red lining the boiler when it isn't necessary. You wouldn't do it to a car... Well, unless you were having a bit of fun.
          Kind Regards - Dan Robinson (Jennings Heating Ltd)

          Comment

          • bruce_miranda
            Automated Home Legend
            • Jul 2014
            • 2307

            #20
            @Dan_Robinson said it well, thank goodness in a Vaillant you can limit the red line based on the boiler knob, Viesman OT implementation is quite dangerous IMHO.

            Also I am curious to know how you wired your combi to work as a system boiler. I thought in a combi there is normally no electrical input to trigger a HW demand, it's sensed by the boiler when HW is flowing through the boiler because someone opened a tap? So how have you wired your combi using the BDR to tell the boiler it is heating HW. Or are you just starting a pump on the HW cylinder loop, which the boiler is seeing as a tap open and firing up? Also just curious to know why you choose to use a combi as a system boiler instead of just buying a system, quite clever actually.

            Comment

            • Dan_Robinson
              Automated Home Ninja
              • Jun 2012
              • 347

              #21
              The mighty Intergas uses the same PCB for who variants (not unusual), and the terminals are there for the cylinder sensor and diverter valve control.

              It is a matter of pressing buttons to turn it into system boiler.
              Kind Regards - Dan Robinson (Jennings Heating Ltd)

              Comment

              • DBMandrake
                Automated Home Legend
                • Sep 2014
                • 2361

                #22
                Originally posted by top brake View Post
                i think the concern about control band width is largely notional and given time the fuzzy logic control algorithm will adapt.
                an unscheduled large setpoint adjustment will naturally result in a higher flow temperature being required.
                The problem is with the way things are now that can lead to significant overshoots of zones that are already in equilibrium.

                An example of this is our living room is scheduled for 20.5 degrees from 6pm to 11pm, in the early evening it does an admirable job of keeping the temperature steady, however our sons bedroom is scheduled to come on for 8pm and usually has several degrees to make up - which results in the boiler going full tilt (BDR91) as it is outside the proportional band, and this usually causes an uncomfortable rise in temperature in the living room to 21 or 21.5 degrees because the delicate balance between HR92 valve position and boiler duty cycle is upset by the large set point adjustment in another room.

                0.5-1 degree increase doesn't sound like much but the biggest effect is the sudden increase in radiator panel surface temperature in the living room, which shoots up due to the sudden increase in boiler duty cycle from say 30% to 100%, causing a lot of additional radiant heat that is not really reflected by the wall thermostat reading in the short term. By the time the thermostat reacts its too late and the room is uncomfortably hot after being just right for a couple of hours.

                I don't see OpenTherm helping over a BDR91 if OpenTherm would also just call for maximum flow temperature in the same circumstances. I'm not sure what the right answer is to this problem, there may not be a complete solution.

                Limiting maximum flow temperature to a seasonally sensible value is a partial mitigation - I still have my flow temp set to 65 (which is quite low for the old radiators I have) and still see up to a 1 degree overshoot. With a higher flow temperature I'd see an even bigger overshoot, so I try to keep the flow temperature limit to the lowest that I can get away with at a given time of year.

                A wider proportional band would help somewhat, but what might be more useful is that if a sudden change in set point happens in one zone (say a zone going from 5 to 20 degrees when the room temperature is 17 degrees - as in my bedroom example) that instead of instantly calling for maximum heat from the boiler (maximum flow temperature or 100% duty cycle for OpenTherm or BDR91 respectively) the call for heat should ramp up progressively over say 10 minutes to the new target heat demand. Apply some sensible low pass filtering to the changes in heat demand from the boiler instead of allowing instant changes...

                In any kind of negative feedback system avoiding unnecessary "step changes" will always make the overall feedback loop more stable.

                This would give thermostats in other rooms that are already in a nice equilibrium a chance to react to an increase in room temperature that will result from the unexpectedly increasing flow temperature. For example if the flow temperature was gradually ramped up in the living room as a result of the bedroom being scheduled on, the room temperature would overshoot much more slowly giving the wall thermostat time to notice the increase and start closing the valve and therefore minimise the overshoot.

                This kind of ramping may only work effectively with OpenTherm since the heat demand to the boiler can be controlled immediately unlike a BDR91 duty cycle which is already averaged over 10 minutes.

                As it stands now, with temperature readings only being processed by an HR92 about every 4 minutes, if the flow temperature on a radiator rapidly increases due to another zone coming online the panel will reach maximum surface temperature before the next temperature reading is even relayed to the HR92 - by then it is far too late for it to react and the thermal mass of the radiator causes a room temperature overshoot. The amount of overshoot you get is limited only by the radiator panel size and the flow temperature limit.

                Faster sampling rate of the HR92 during rapid temperature changes would also help so that it notices the increase and starts to close the valve sooner, but would reduce battery life of course, and it's not clear whether the sampling rate of the HR92 can be varied.

                It does look though from the reverse engineered over the air protocol that the controller can adjust the "sleep time" of the HR92's in each zone at the start of each sleep cycle, so it might be possible to have a variable sleep time that depends on the rate of temperature change - allowing more rapid sampling during faster temperature changes (especially increases) to allow better control and minimise overshoot, and less frequent sampling when the temperature is slowly changing or steady to maximise battery life.

                It could be even cleverer than this - in addition, when the controller knows that a large scheduled set point change is about to happen (or a manual override has just been made) it could temporarily reduce the sleep time of ALL HR92's so that they are all able to more quickly react to a potential overshoot induced by a large flow temperature change, then once the system has stabilized to the new set point conditions the sleep time could be increased again to conserve battery life where possible.

                A combination of ramping the heat demand instead of instant changes, and temporarily reducing the sleep time of HR92's to increase the sampling rate when sudden flow/room temperature changes are expected or anticipated could well solve the issue, at least for those with OpenTherm. Something for the Evohome engineers to consider perhaps ?
                Last edited by DBMandrake; 17 October 2017, 09:43 AM.

                Comment

                • paulockenden
                  Automated Home Legend
                  • Apr 2015
                  • 1719

                  #23
                  The "New zone calling for max heat when other zones are already in the proportional band" problems doesn't just affect O/T controlled boilers - it can and does cause overshoots with BDR91 switching too.

                  I suspect your alternative S-Plan wiring (which I must get round to doing) might help a little, as it'll 'smooth out' the rapid burst of energy inserted into the system when a cold zone suddenly calls for heat.

                  But without constant comms between the rad valves and the controller (so the latter could say "Watch out, the water is about to get a lot hotter") I don't think this is easy to solve, and there's always going to be a degree of overshoot on zones that are just bumbling along having reached optimum temp.

                  P.

                  Comment

                  • DBMandrake
                    Automated Home Legend
                    • Sep 2014
                    • 2361

                    #24
                    Originally posted by paulockenden View Post
                    The "New zone calling for max heat when other zones are already in the proportional band" problems doesn't just affect O/T controlled boilers - it can and does cause overshoots with BDR91 switching too.
                    Indeed - I use a BDR91 after all and the symptoms I'm describing are of my own system. (But I see people with OpenTherm describing the same issue)

                    However I think OpenTherm does in principle at least offer greater opportunity to solve the problem using a technique such as the one I described of using a progressive ramp up in flow temperature over time (of say 10 minutes) when a new high zone heat demand suddenly appears, rather than just instantly cranking the flow temperature demand to max, which doesn't give thermostats in other unrelated zones much if any time to react before they overshoot.

                    Duty cycle control of a BDR91 doesn't give the same finese either in terms of flow temperature control or response time that OpenTherm would - it would be difficult or impossible to ramp up the flow temperature smoothly over 10 minutes using duty cycle control when the cycles themselves are 10 minutes long...

                    I suspect your alternative S-Plan wiring (which I must get round to doing) might help a little, as it'll 'smooth out' the rapid burst of energy inserted into the system when a cold zone suddenly calls for heat.
                    Perhaps, but I'm not convinced about that. I think the fundamental problem is that the system is going from a BDR91 duty cycle of say 30% (with HR92 openings adjusted to be in balance with that) to suddenly a duty cycle of 100% for in excess of half an hour while the room warms up - in which case the heating zone valve would be commanded open full time anyway.
                    But without constant comms between the rad valves and the controller (so the latter could say "Watch out, the water is about to get a lot hotter") I don't think this is easy to solve, and there's always going to be a degree of overshoot on zones that are just bumbling along having reached optimum temp.
                    Yes - the theoretical ultimate solution would be some sort of reverse comms so the Evotouch could warn the HR92's "watch out, sudden increase in flow temperature incoming"...but I don't think either the over the air protocol or the HR92 firmware supports any such notification method, making it infeasible to add at this point.

                    What I think it does support (from browsing the reverse engineered protocol specs) is varying sleep times for HR92's that are under control of the Evotouch controller. Whether it's on an individual HR92 basis, individual zone basis or system wide I don't know.

                    I've long realized that a 4 minute sampling time is too slow to cope with rapid temperature changes and react quickly enough without overshoot, so a sudden change like a large flow temperature increase can lead to a big overshoot as the response to it is so delayed...its also the cause of some kinds of temperature oscillations for example with oversize radiators that heat up quickly and cool very slowly, which in well insulated rooms can result in a continuous oscillation of the temperature. (I'm sure we all have rooms like that...)

                    Interestingly the communication from temperature sensor (DTS92/HR92 etc) to evotouch is not a fixed interval but depends on the the rate of change - if temperature is increasing quickly a DTS92 will send updates a lot more frequently than every 4 minutes and those that graph their temperatures with Domoticz have proven this. The HR92 also seems to send temperature readings to the controller at a variable interval.

                    However the rebroadcast of this temperature back to the HR92 from the controller is (currently) on fixed ~4 minute communication intervals - the same ones where set point changes are sent. So even if the remote sensor sends more frequent updates to the controller they are effectively wasted. Only when the HR92 wakes on that 4 minute interval will it receive a new temperature reading, make a determination about what it needs to do to its valve position, turn the motor and then go back to sleep again.

                    But if the sleep interval is controlled by messages from the controller and can be adapted on the fly to changing conditions there is the potential to improve the situation a lot. In any situation where the system is about to become "unstable" such as a scheduled sudden large increase in heat demand in one zone, shorten the sleep interval of all the HR92's to lets say 1 minute for a period of 10 minutes, so that they are all able to quickly respond to any room overshoot rather that waiting until its too late.

                    When the system is back within the proportional band again increase the sleep time back to 4 minutes. Adapting the sleep time during system warmup based on rate of temperature change could also be helpful. Some rooms heat so quickly (our bedrooms are like this - massively over-sized radiators) that a 4 minute sample period is too long to avoid overshooting the target. If the system sees a rapid warm up in a zone it should reduce the sleep time of those HR92's until the zone nears equilibrium then stretch it out again.

                    If sleep time is controlled via controller messages this is something that could be implemented in software. Combine that faster response time with "ramping" the heat demand so that you avoid sudden large step increases in flow temperature to give the system a bit more time to adapt and I think over shoots of unrelated rooms could be minimized to a point where it is inconsequential. Although it would probably only work with OpenTherm, ramping the heat demand over time is something that is also trivially doable in a few lines of code in software.

                    Comment

                    • scw24489
                      Automated Home Lurker
                      • Jan 2008
                      • 1

                      #25
                      Bruce,
                      The vaillant ecotec 6xx boiler can be used as a dual stat boiler.
                      Use swithched live on terminal 4 for CH demand.
                      Use a volt free contact to short the C1C2 plug on the harness (24V side) to take priority HW demand. Fit a Vaillant VR10 sensor to the orange and black wires of boiler harness to sense cylinder temperature.
                      On the first gen ecotecs the temps are set with the dials. On the later models with DIA interface then HW temp is set in the diagnostic parameters.
                      Never tried this with a VR33 as well so don't know if the wheter the VR33 ebus input would trump the C1C2 demand.

                      We regularly used this setup for UFH based systems before the VRC700(5) facilitated demand contacts and/or more than three circuits/zones

                      Simon

                      Comment

                      • bruce_miranda
                        Automated Home Legend
                        • Jul 2014
                        • 2307

                        #26
                        You cannot add more than two thermostats on the eBUS. So if you have any of the Vaillant controls the VR33 is completely ignored.

                        Comment

                        • Simon Willett
                          Automated Home Lurker
                          • Nov 2017
                          • 2

                          #27
                          I think we are at cross purposes - VR33 is a OT to Ebus converter - might have been clearer to say not sure if converted OT input will overide C1C2 - gut feeling is it would not, and hardwired DHW request would take priority.

                          Incidentally the number of stats(zones) on ebus is dictated by the controller and hardware, iff you use the VRT350 and VR66 combo designed to drop into S/Y plan systems the max is indeed two but you can have up to 15 or 9 zones/circuits on ebus controls with either VRC630/VR60/VR90 (only first eight with VR90 room units) or VRC700-5/VR71/VR70/VR91 hardware respectively.
                          With the VRC700 hardware some configurations offer the possibility of a volt free input 'Demand Contact' for the heating circuits which facilitated connecting a favoured roomstat or the likes of Evo but this also has the effect of making an unlimited number of room controls possible but not necessarily desirable :-)
                          The demand contacts are useful for plant refits with legacy room controls but now Ambisense and the VR920 gateway have been released will probably not see so much use in domestic situations.
                          Last edited by Simon Willett; 17 January 2018, 12:11 AM.

                          Comment

                          • fergie
                            Automated Home Sr Member
                            • Mar 2017
                            • 92

                            #28
                            Surely the simplest solution is to be able to control the heat demand percentage in the Evohome itself?

                            Ie when HW is called for it tells the OT bridge to ask for 100% = 70deg.

                            When radiators ask for demand, it asks for say 80% max and therefore the boiler provides lower heat - say 60deg.

                            Surely it wouldn’t be hard to add settings to allow the CH behaviours to be calibrated within Evohome itself?

                            Comment

                            • dty
                              Automated Home Ninja
                              • Aug 2016
                              • 489

                              #29
                              OpenTherm requests specific temperatures from the boiler, not percentages, so it would be even easier! You’d just set two maximum temperatures in Evohome - one for hot water, one for heating. This would only work for OpenTherm controlled boilers, of course. Unfortunately, I doubt the OT bridge has this capability right now and I don’t believe it’s field-upgradable. So it would necessitate buying a new OT bridge (unless Honeywell were remarkably generous and offered a swap-out programme. I expect they can reprogram the bridges once they receive them back and send them out to another customer.)

                              Comment

                              • dty
                                Automated Home Ninja
                                • Aug 2016
                                • 489

                                #30
                                Actually, I’ve been wondering how some of this affects the learning algorithms. I have one or two particularly cold rooms in my house so at the moment Evohome is requesting the full 90C a lot of the time - even though the boiler modulates down to 6kW to achieve that with only those two rooms asking for any significant heat. However, the boiler limits the flow to 75C. But Evohome thinks it’s getting 90C. Then I see it step down to 85C, but of course nothing changes at the boiler - it’s still producing 75C. Then again at 80C. It’s not until it requests less than 75C that anything useful actually happens. This has surely got to confuse the learning algorithm?

                                Comment

                                Working...
                                X