Evohome firmware 02.00.19.31 Beta Trial - Exclusive for Automated Home Members

[DBMandrake]

Not quite. You will see this with OpenTherm and no heating valve when the low load algorithm comes into play. (I seem to keep repeating myself on this).

The algorithm sends a >10C flow temperature request (on) followed by a 10C request (off).

Which "low load algorithm" is this ? Is this something new in the Betas ? I can't see any reason why OpenTherm would keep switching the boiler off and on in a partial load situation. The whole point of OpenTherm is to just ask for a specific flow temperature and not cycle on and off at all. The boiler may have to cycle of course if it can't modulate low enough but that's a separate issue.

Typically the boiler in these low load situations will reach 5C above the flow temperature request and cut ignition. It will start to anti-cycle but the 10C off request followed by another flow temp request can interrupt this and result in further heating if the flow temp has dropped.

The OpenTherm Monitor plots clearly show this behaviour.

Are you certain the OpenTherm signal from the Evohome is causing this ? Because it sounds like the boiler is just cycling due to the load being too low. Perhaps the Evohome's OpenTherm implementation monitors the reported flow temperature and if it goes too far above what it is requesting it cuts the request ? Effectively duplicating what the boiler should already be doing itself ?

[kevinsmart]

Which "low load algorithm" is this ? Is this something new in the Betas ? I can't see any reason why OpenTherm would keep switching the boiler off and on in a partial load situation. The whole point of OpenTherm is to just ask for a specific flow temperature and not cycle on and off at all. The boiler may have to cycle of course if it can't modulate low enough but that's a separate issue.

Are you certain the OpenTherm signal from the Evohome is causing this ? Because it sounds like the boiler is just cycling due to the load being too low. Perhaps the Evohome's OpenTherm implementation monitors the reported flow temperature and if it goes too far above what it is requesting it cuts the request ? Effectively duplicating what the boiler should already be doing itself ?

It's not new, it's described as "When an appliance is no longer able to modulate lower the control switches from modulating control to low/off control.". The T6 thermostats have a more sophisticated version described here:
https://ensupport.getconnected.honey...language=en_US

The OpenTherm bridge sends a flow temperature request for a few minutes, followed by a 10C request (off), then a flow temperature request again. It's not the best picture but you can see the behaviour here:

IMG_3540.jpg

You'll see Flame Status at the top in red, then modulation levels in black. At the bottom the red line is the actual flow temperature and the grey is the requested flow temperature. Note the periods of about a minute where the requested flow temperature is 10C. You'll also see that despite the boiler having a 5min anti-cycle time, the mechanism results in the boiler firing sooner when the new flow temperature is sent and the actual flow temp is lower.

[DBMandrake]

From what you describe the root cause of the problem is still that the boiler can't modulate sufficiently low in output power to prevent the flow temperature overshooting and when it does, the Evohome takes matters into its own hands and shuts off the heat demand signal for a while.

I don't see a problem with that. If it didn't the boiler would have to do it itself anyway, as cycling the burner off and on is the only way to deal with a situation where the flow temperature can't be controlled in a low load condition.

If this causes the boiler to reset its anti-cycle timer prematurely then surely that is a bug in the boiler control logic ? I don't see this as a fault of the Evohome either. It just sounds like yet another buggy boiler OpenTherm implementation, like those which don't allow the maximum flow temperature to be adjusted.

[kevinsmart]

From what you describe the root cause of the problem is still that the boiler can't modulate sufficiently low in output power to prevent the flow temperature overshooting and when it does, the Evohome takes matters into its own hands and shuts off the heat demand signal for a while.

I don't see a problem with that. If it didn't the boiler would have to do it itself anyway, as cycling the burner off and on is the only way to deal with a situation where the flow temperature can't be controlled in a low load condition.

If this causes the boiler to reset its anti-cycle timer prematurely then surely that is a bug in the boiler control logic ? I don't see this as a fault of the Evohome either. It just sounds like yet another buggy boiler OpenTherm implementation, like those which don't allow the maximum flow temperature to be adjusted.

I never said it was a problem, I think you doubted that this mode of operation occurred, hence my explanation.

[DBMandrake]

I never said it was a problem, I think you doubted that this mode of operation occurred, hence my explanation.

Fair enough.

So if the boiler can modulate sufficiently low the Evohome doesn't cut the heat demand ? How far over the requested temperature does it have to go before the Evohome intervenes and cuts the heat demand ?

[kevinsmart]

Another way to look at OpenTherm low load low/off control is that Evohome has no idea what the lowest flow setpoint is. It can read the Max CH water setpoint (which is often wrong e.g. Intergas always reads 90C) but there is no minimum reading.

Furthermore, the boiler minimum supply temperature can be changed via boiler parameters (e.g. Intergas 10C-60C) and OT response (e.g. 0=Ignore OT demand if the setpoint for the flow temperature is below minimum, 1=Accept OT demand if the setpoint for the flow temperature is below the minimum).

So I think Evohome may try to determine a working minimum setpoint that actually heats by monitoring the boiler water temperature reading, flame status.

Theoretically if the minimum setpoint was high, or misconfigured to match the boiler's max CH flow temperature, I guess the behaviour becomes more like TPI with on/off periods to try to reduce the output.

With my setup Evohome is running as low as 26C flow setpoint when it starts employing low/off control.

[Mid112]

Another way to look at OpenTherm low load low/off control is that Evohome has no idea what the lowest flow setpoint is. It can read the Max CH water setpoint (which is often wrong e.g. Intergas always reads 90C) but there is no minimum reading.

So if the evohome doesnt know what is the Min CH on the boiler - why is this low load invoked at all?
In my opinion it should only start demending for heat - when there is a proper heat demand from evohome - not to come on ever 10 min just for sake of it.
if this is a opentherm technology "feature" - thats surley wrong - but i suspect we may need to live with it

Do we know exactly when Low Load Control kicks in? At what % of evohome demand?

Furthermore, the boiler minimum supply temperature can be changed via boiler parameters (e.g. Intergas 10C-60C) and OT response (e.g. 0=Ignore OT demand if the setpoint for the flow temperature is below minimum, 1=Accept OT demand if the setpoint for the flow temperature is below the minimum).

In my opinion these settings are ignored when opentherm is in play. I have the boiler set to 0, with Parameter 56 set to 25C and the boiler still comes on with 25/26C - while according to settings anything below 30 should be ignored.

Am I missing anything here.


Please find attached intergas service settings for reference its in pdf

https://gofile.io/d/1DR1sq

[kevinsmart]

Another way to look at OpenTherm low load low/off control is that Evohome has no idea what the lowest flow setpoint is. It can read the Max CH water setpoint (which is often wrong e.g. Intergas always reads 90C) but there is no minimum reading.

So if the evohome doesnt know what is the Min CH on the boiler - why is this low load invoked at all?
In my opinion it should only start demending for heat - when there is a proper heat demand from evohome - not to come on ever 10 min just for sake of it.
if this is a opentherm technology "feature" - thats surley wrong - but i suspect we may need to live with it

Do we know exactly when Low Load Control kicks in? At what % of evohome demand?

Furthermore, the boiler minimum supply temperature can be changed via boiler parameters (e.g. Intergas 10C-60C) and OT response (e.g. 0=Ignore OT demand if the setpoint for the flow temperature is below minimum, 1=Accept OT demand if the setpoint for the flow temperature is below the minimum).

In my opinion these settings are ignored when opentherm is in play. I have the boiler set to 0, with Parameter 56 set to 25C and the boiler still comes on with 25/26C - while according to settings anything below 30 should be ignored.

Am I missing anything here.


Please find attached intergas service settings for reference its in pdf

https://gofile.io/d/1DR1sq

That is the correct behaviour. You've set the minimum temperature for OT demand to 25C, so the minimum seen should be 25C and not any temperature less than this.

I'll try to find out by monitoring my system what the aggregated demand is when low load control comes into play.

[Mid112]

If I set the boiler to allow Opentherm to go as low as 25C then set up parameter "Ignore OT demand if the setpoint for the flow temperature is below minimum" (30C)"
The boiler comes on with 25/26C every couple of minutes - while according to the setting above anything below 30C should be ignored?

How come it could be correct?

Further to the 30C temperature setting - I think this parameter can be adjusted as well. If I set the temperature to ie ignore anything below 40C - boiler will come up with 40C every 10min - for 1 min or so any way. Tada...

I mentioned previously that boilers' settings whether its on 0 or 1 - are ignored by evo/opentherm.

Becouse when using O/T with evohome - the boiler will come on every 10 min for 1 min or so regardless of boiler settings.

When people use BDR91 at least they can specify number of cycles per hour in the evohome menu. When using OpenTherm - we can only accept how it works - and its definetely not how people think it should work by jugding numerous post.

What I can see - the boiler gives priority to Evohome/OT over most of the settings in the menu. I think only Min CH and Max CH can be adjusted on the boiler and they are above OT commands anything else by OT takes over the boiler setting.

[kevinsmart]

How come it could be correct?

If I set the boiler to allow Opentherm to go as low as 25C then set up parameter "Ignore OT demand if the setpoint for the flow temperature is below minimum" (30C) ?
And the boiler comes on with 25/26C every couple of minutes - while according to the setting above anything below 30C should be ignored?

Thats why I mentioned previously that boiler's setting whether its on 0 or 1 - are ignored by evo/opentherm. They only setting

What I can see - the boiler gives priority to Evohome/OT over most of the settings in the menu. I think only Min CH and Max CH can be adjusted on the boiler and they are above OT commands.

I think it is a mistake in the Xclusive's manual. If you look in other Intergas manuals, for instance my boiler, you'll see the following descriptions.

Parameter E: Min. Supply temperature during OT demand
Parameter E.: 0 = Ignore OT demand if the setpoint for the flow temperature (value send by controller) is below the value of par E
1 = Accept OT demand if the setpoint for the flow temperature is below the value of par E.
The setpoint for the flow temperature is the value of par. E

https://www.intergasheating.co.uk/ap...l-88287806.pdf

So I think the reference to 30C in your parameter 057 is wrong, it should state the minimum is the value of parameter P056, which defaults to 30C. When you change P056, this is the minimum temperature for the P057 operation, consistent with other Intergas boilers.