Boiler with separate HW and CH max and OpenTherm

[blowlamp]

Thanks for your reply, DBMandrake.

I’m giving details of my setup that you may already be aware of in the hope they might be of use to you & others

My system is an Intergas boiler with Remeha iSense controller-thermostat. The sytem uses OpenTherm and weather compensation control together, the weather compensation sensor being wired directly to the boiler.

If no additional OpenTherm boiler controller-thermostat is connected, then the user adjustable weather compensation curve programmed into the boiler is utilised, provided it is sensed that an outdoor sensor is in-circuit.

However, when an additional OpenTherm boiler controller-thermostat is used, the weather compensation curve programmed into the boiler is ignored and instead, the one within the connected controller-thermostat is used, if available and it is sensed that an outdoor sensor is present.

The boiler passively sends the iSense the outside temperature value and from it, the iSense calculates a flow temperature to suit the current indoor temperature & weather conditions, which it returns back to the boiler. The boiler now only has to maintain that temperature according to its inbuilt logic and until the next request from iSense.

The iSense has a definable maximum flow temperature. There is also a Room Temperature Effect (RT Effect) setting, which deviates flow temperature from the programmed weather compensation curve, depending on how far away the measured room temperature is from set point. This effect is user adjustable and governs how high the boiler must fire to achieve set point.

The weather compensation curve of iSense is usually based on a set point of about 20C and is raised or lowered in relation to the actual requested set point. The default curve might be programmed to give a room temperature of 20C when it’s 6C outside with a flow temperature of 50C, whereas a room temperature of 22C whilst at 6C outside might dictate a 60C flow temperature. The RT Effect setting will also combine to shift the curve higher or lower along its temperature scale.

So iSense is quite unlike Evohome in many ways, but a major difference to me is that there is no ongoing learning required. In effect iSense is taught about the property it inhabits when the weather compensation curve is adjusted and other parameters are set. Also, because of the weather compensation curve, higher than necessary flow temperatures are very, very much reduced.


Martin.

[Simon Willett]

You guys are looking for full load/weather/optimisation to be implemented in a product that is in fact a glorified S-plan +

Why try and jury rig Evo? If that is what you want(need?) then why not start with a control family that is designed for purpose?

Most of the better northern European boiler manufacturers already offer 'domestic' optimiser/compensator controls, one of them has even added TRV motors to their range.
The trouble is weather/load compensation (in the real world) is not really suited to the rapid demand change of many small loads that is representative of a domestic installation, a situation that is agravated by systems such as Evo. The two are differing control philosophies from the outset - feed forward vs feed back - continuous flow variable temp vs variable flow continuous temperature.
To my mind Evo already does an exceptional job of keeping stable under challenging unknown circumstances.

Simon

[DBMandrake]

The trouble is weather/load compensation (in the real world) is not really suited to the rapid demand change of many small loads that is representative of a domestic installation, a situation that is agravated by systems such as Evo. The two are differing control philosophies from the outset - feed forward vs feed back - continuous flow variable temp vs variable flow continuous temperature.

Like so many people you seem to be laboring under the illusion that OpenTherm control and Weather Compensation are two competing systems that try to do the same thing and can't work together, purely because they both attempt to control the flow temperature. This is simply not true.

You are right that Weather compensation is feed forward and OpenTherm control is feedback - but feedforward and feedback systems can and frequently are combined into composite control systems.

They are both measuring different things and their resultant can be used to control the flow temperature in a way that provides better control than either system on its own, but it has to be done right and it is not being done right (or at all) in most cases right now.

Evohome using OpenTherm varies the flow temperature based on the instantaneous heat demand from individual rooms. The idea is that the flow temperature should be no higher than that required by the most demanding room. Rooms that are less demanding modulate their radiator flow down further to achieve the heat output they need.

This works well on it's own but it still has some drawbacks. The main one is that if any zones are below their proportional band then it simply demands maximum flow temperature, which may or may not be limited by a boiler control!

This will happen both during initial warmup when you turn the system on, and also when a zone is newly scheduled to come on. This can lead to large overshoots in other rooms that were already at a stable temperature. This excessive flow temperature may cause some zones to dramatically overshoot and never stabilize (they keep oscillating) and it's certainly not very efficient to run the boiler at full tilt so often. It's also not comfortable in warmer weather to have excessive panel surface temperatures.

A partial solution is to manually turn down the maximum flow temperature to something that is appropriate for the radiators, house (heat loss properties etc) and outside weather. You want flow temperature set so that it's just a few degrees higher than what is needed to reach your target set points in a reasonable amount of time. Doing so will minimise or perhaps even avoid overshoots and oscillations if the speccing of the radiators between different rooms was well chosen and balanced. (No weak radiators and/or massively oversized radiators in relation to other rooms)

There are two problems with this. The first is that some boilers simply don't let you set the maximum flow temperature when controlled by Evohome OpenTherm, and the Evohome itself also currently has no way to set a maximum flow temperature. This has been discussed to death on this forum and it is a MAJOR problem, to the point that it makes the system practically unusable as achieving stable room temperatures and good comfort can be nearly impossible, especially if the boiler is trying to run at 90 degrees. I'm sure you've read those threads.

But even on boilers where you can manually set the maximum flow temperature - what do you set it to ? There is no one temperature you can set it to that will be optimal year round, or even across the span of a week if weather is shifting dramatically.

In the winter you need high flow temperatures or your house will take far too long to warm up and some rooms will never achieve their set points. In warmer weather you need a lower flow temperature otherwise the rooms will all overshoot and keep oscillating, panel temperatures will be uncomfortably high when radiators come on (too much direct IR) and there will be a large amount of interaction between rooms where a single room coming on can cause several other previously stable rooms to overshoot a degree or two. (Due to the sudden massive increase in flow temperature) It's probably also less efficient and won't promote good condensing performance.

So in warmer weather you need to turn the maximum flow temperature down and turn it up again in winter. This should be the job of weather compensation, not you as the house owner to run around changing this all the time when the weather shifts from +6 to -6 in the space of a few days. (Or just put up with the poor performance of having the flow temperature too high most of the year - which is what I suspect most households do, especially if there is no-one particularly technical at the helm to turn it down when it would be a good idea)

Far from confusing Evohome it should reduce the amount of adaption it has to do as the outside conditions change - even during a single day. (Early morning vs early evening for example, where the outside temperature can be radically different)

Evohome has no knowledge of the outside weather, nor the heat loss through the walls that result from that. It is purely a negative feedback system that only measures the temperature in individual zones, and adjusts the heat demand and flow through the radiators using PID controllers in an attempt to meet that target. (Contrary to what you say above, Evohome controls both flow temperature and flow rates, it is not variable flow fixed flow temperature as you state)

The heat demand required to reach the same target temperature varies depending on the heat loss. If we consider a fixed maximum flow temperature for a moment say 80 degrees, to reach 20 degrees in winter it might require a "heat demand" of 60% but in the warmer months it might only require a heat demand of 20%. The way this is achieved is through the I (integral) term of the PID controller - over a period of time it will gradually adapt to a fixed offset and this will allow it to find the new heat demand that will give the target temperature.

The other adaption that has to take place with a change in weather is the tuning of the D (differential) term. This is the one that controls and tries to avoid temperature overshoots and allows the temperature to climb quickly to the target and settle with minimal overshoot. The hotter a radiator is (due to higher flow temperature) the more thermal mass and inertia it has and the more tendency there will be to the room overshooting the target as the amount of heat it puts into the room after the valve is closed off increases.

An HR92 will observe any overshoot and make adjustments to the D term to attempt to avoid this in the future, but this adaption takes time and many warm up cycles (a few days) to optimise. Essentially what the D term does is predictively starts to throttle the valve back well before the target set point is reached based on an assumption of how quickly the temperature is rising and how long it will keep rising as the valve closes. This is really hard to get right - close it too late and the temperature overshoots, close it too soon and the temperature levels out below the target and then will eventually start to rise again thanks to the I term.

The problem comes when outdoor temperatures shift suddenly like a cold snap. If it suddenly gets colder outside than yesterday the prediction for how soon to close the valve before the target is thrown out of kilter - it will close too soon and the target will be undershot. Conversely if you get an unexpected warm shift rooms that were hitting their targets perfectly will start to overshoot and it can take a few days for the system to adapt. It will get there eventually but there will be a messy adaption period. If the flow temperature is a lot too high - like set for the middle of winter and its late spring, it will not be able to adapt far enough and it will overshoot regardless.

Again this is where weather compensation could come in. If it is adjusted properly to model the heat loss of the house correctly you can arrange things so that the individual HR92's don't have to adapt very much to changing weather - they call for about the same "heat demand" whether it is cold or warm outside, but that heat demand is scaled down by the weather compensation based on outside temperature and implied changes to building heat loss... which means there is little if any adaption required so the system will respond quickly to shifts in the weather, even on a daily basis without going through re-learning cycles.

For example in our 80 degree example above requiring a 60% heat demand in winter, in the cold weather the weather compensation may allow that high flow temperature, then in the warm weather where previously the HR92's heat demand would have had to have fallen to 20%, the weather compensation may have scaled back a 100% heat demand to say 55 degrees so that when the HR92 calls for 60% heat demand it is getting about the same flow temperature as it would have got from a 20% call for heat had it not been for the weather compensation.

Now the HR92's only need to adapt to your radiator and room characteristics, but are relieved from having to constantly adapt to unknown (to them) changes in weather and therefore heat loss. Year round you should see optimal performance - fast warm up time and set points being reached in the winter, but avoiding overshooting, oscillating and unnecessarily high flow temperatures in warm weather, all without the owner lifting a finger to adjust the maximum flow temperature, or changing their set points. And it can adjust automatically on both a seasonal and daily/weekly basis.

Perhaps overkill, but that is my ideal system. The fact that I find I need to turn my flow temperature up in the winter and down in the summer for optimal results tells me that not all is well with the concept of a single fixed maximum flow temperature.

[fergie]

That has to be one of the longest posts for quite a while 😎

Rather than messing around with sensors, I’d be happy for evohome to use forecast temps (with option to vary it if your garden is normally hotter or colder than the station).

For me (in a modern well insolated property), being able to set independent max temps for heating and water is the biggest priority.

[blowlamp]

OpenTherm is a 2-way communication protocol/language, rather than a feedback system, as far as I am aware. OpenTherm's utility depends on how many words from its 'dictionary' are understood by the boiler & controller-thermostat and also how they are applied under any given set of circumstances. Once a message is delivered and acknowledged, it is down to the internal logic of the receiving device to act in a suitable fashion. Obviously, the smaller the vocabulary of any device, the less utility it will have and can be seen by Evohome not implementing things like a maximum flow temperature setting or using the outside temperature feature.



Martin.

[rvb99]

I think we need to remember that Honeywell is not here just to serve the UK. The UK has some of the worst insulated houses in Europe. It is really this that raises the question as to whether external weather compensation in the control system is necessary. If you are building a near passive house in Germany, then external weather compensation is not going to be much needed.

Unless I'm mistaken I thought I remembered an old Honeywell heating control system (CM5000) or perhaps it was a drayton that had an external temperature sensor . Clearly for some good reason this strategy is dropped for Evohome, as a guess probably based on the increasing efficiency of domestic properties.ey

Also remember that Opentherm was a standard initially created by Honeywell. Clearly they are not impressed if they have to update their systems to compensate for boiler manufactures not applying the correct/expected implementations.

https://www.theguardian.com/environment/damian-carrington-blog/2013/nov/29/uk-homes-most-expensive-heat-eu-fuel-poverty

[HenGus]

Interesting. I am yet to see a discrepancy between boiler demand and maximum zone demand, and I've kept tabs on it quite a bit.

This is typically what I see on my controller:IMG_0942.jpg

The rest of the zones (bar one which is at 5%) are all 0%.

[DBMandrake]

This is typically what I see on my controller:[ATTACH=CONFIG]1208[/ATTACH]

The rest of the zones (bar one which is at 5%) are all 0%.

I've never seen that happen. Do you have any zones with multiple HR92's ? I don't.

Perhaps only the "primary" HR92 in a zone has its heat demand reported on the new diagnostics screen ?

I had assumed that in a multiple HR92 zone the diagnostics screen would show the highest heat demand from the HR92's in that zone but maybe this is not the case and it is always the primary one!

[HenGus]

No multi zones. The hall sensor is the Evotouch controller.

[bruce_miranda]

I use a VR33 so my observations are based on the eBUS side. What I have seen is that the Flow requests vary from 10-90. Also there is constant feedback from the boiler to the device to tell it what the flow actually is. e.g. you asked for 90 but I can only go to 65. But the OT appears to be fixed in its way and ignores this. I could quite easily have done the mapping of OT % to flow temp requested, but the OT % implementation on Domoticz is wrong and the OT % is not on the web API yet! We have suspected this for a while but now its evident because the reported Heat Demand on Domoticz and the controller dont match.

[HenGus]

I use a VR33 so my observations are based on the eBUS side. What I have seen is that the Flow requests vary from 10-90. Also there is constant feedback from the boiler to the device to tell it what the flow actually is. e.g. you asked for 90 but I can only go to 65. But the OT appears to be fixed in its way and ignores this. I could quite easily have done the mapping of OT % to flow temp requested, but the OT % implementation on Domoticz is wrong and the OT % is not on the web API yet! We have suspected this for a while but now its evident because the reported Heat Demand on Domoticz and the controller dont match.

The problem, as noted before, is the inconsistency of boiler operation under OT control between manufacturers. As I have posted previously, the max HW and CW temperatures demanded by Evohome OT are limited on the Atag is boiler by the TMax Set temperature in the installation parameters. My boiler max flow temperature is limited to 70C, and I have never seen the TSet Calculated temperature demanded by Evohome rise above this setting. The 'downside' (I have yet to determine whether it actually is a downside) is the OT control renders the manual setting of CH maximum flow temperature inoperative.

[HenGus]

All zones are up to temperature and this is what OT is demanding:

IMG_0943.jpg

I am not bothered about it as the Evohome/Atag/OT combination is working well as far as I can tell.

I have just noticed that the difference is 14% on both images. Uhm?

[fergie]

I've been playing a wee bit with the settings on my Atag iS32 (HenGus has the 24). As HenGus says, if the boiler is set up at the 70deg preset, it never goes above that, but I have found that if I then manually drop the temp it will 'overshoot' by approximately 8 degrees. So for example if I set the boiler temp max at 57, it will generally max out about 65.

However though, I still saw the heating push it gradually over 65 and back up to 70deg when there was a lot of heating demand, but NOT when there was hot water demand.

As an experiment, I soft set the boiler at 50deg last night, but woke up to pretty cold house. Basically the Hot water tank only reached aprox 57deg which on my priority system stopped the heating valve from opening as it was constantly trying to heat the tank (set to 60 in Evohome).

My theory therefore is that with the HW kit, the Evohome is sending a lower temp than it does when demanding CH!

Any thoughts?

[bruce_miranda]

This doesn't match what I see. HW creates a 90C demand. Exactly the same as a CH max heat demand. This also matches what the Honeywell guys themselves said.

[fergie]

This doesn't match what I see. HW creates a 90C demand. Exactly the same as a CH max heat demand. This also matches what the Honeywell guys themselves said.

Fair enough, but something must be different in the other setting requests maybe? But at least the Atag seems to be further capping it (to an extent).