Page 3 of 7 FirstFirst 1234567 LastLast
Results 21 to 30 of 67

Thread: Boiler with separate HW and CH max and OpenTherm

  1. #21
    Automated Home Ninja Dan_Robinson's Avatar
    Join Date
    Jun 2012
    Posts
    347

    Default

    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.

  2. #22
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,919

    Default

    Quote 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; 17th October 2017 at 10:43 AM.

  3. #23
    Automated Home Legend paulockenden's Avatar
    Join Date
    Apr 2015
    Location
    South Coast
    Posts
    1,633

    Default

    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.

  4. #24
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    1,919

    Default

    Quote 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.

  5. #25
    Automated Home Lurker
    Join Date
    Jan 2008
    Posts
    1

    Default

    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

  6. #26
    Automated Home Legend
    Join Date
    Jul 2014
    Posts
    1,086

    Default

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

  7. #27
    Automated Home Lurker
    Join Date
    Nov 2017
    Posts
    2

    Default

    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; 17th January 2018 at 12:11 AM.

  8. #28
    Automated Home Sr Member
    Join Date
    Mar 2017
    Posts
    92

    Default

    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?

  9. #29
    Automated Home Ninja
    Join Date
    Aug 2016
    Posts
    489

    Default

    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.)

  10. #30
    Automated Home Ninja
    Join Date
    Aug 2016
    Posts
    489

    Default

    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •