No news is... no news

I am occasionally emailed by people who have come across this blog, asking for any further news about resolving problems with repeated cycling of Vaillant 400 series boilers. In summary, the situation is this:

1. The prototype circuit board that I described in my posts of September 2012 is still in place, and is functioning exactly as it should. I have noticed no further microfiring since it was fitted. I haven't actually done much detailed monitoring, since the boiler was decommissioned over the winter of 2012-3 during building work, and during that time my vrDialog kit went missing so I now do not have the hardware to take recordings from the boiler. However, I'm sure I would have noticed if microfiring had been occurring, and it hasn't.
2. Vaillant has told me nothing whatsoever further about what happened with the board. You might think that they would use this blog, via me, as a way of informing people about whether and how they can get hold of the new board (and indeed whether new 400-series boilers have the fix built into them or not), but they haven't. So I can't tell you anything more than that my prototype board worked. Maybe they can supply one to someone else, maybe they can't. If you want one, you'll have to do battle yourself with the deafening lack of communication that emanates from Vaillant.

I'm not planning to add to this blog further. If you experience the cycling problem with your Vaillant boiler, my commiserations. I hope you find the historical entries on this blog useful, and I hope you get some satisfaction from Vaillant.

Anti-Legionella behaviour improved

The new circuit board continues to behave well, with no microfiring seen so far.

I have found that its software has also been improved in another respect. I noted in the post here that the anti-Legionella programme (which was supposed to heat the hot water cylinder to 70C) did not work correctly, with heavy microfiring apparent. This has changed, with the behaviour now looking like this:

It's not perhaps perfect, but it's certainly a vast improvement. Now the target flow temperature used is 70C (rather than about 84C), and more importantly there is no microfiring because the boiler stops trying to heat the cylinder when it reaches a temperature above about 65C. So I shall be content to use this programme, whereas I certainly wasn't before.

First day of full data collected from new circuit board

The new circuit board is progressing well. I have now found a way to persuade vrDialog to collect comprehensive data from it, which reveals no microfiring on the first day I did so, despite a flow temperature in the thirties or low forties:

This is a very considerable advance over how it would have behaved with the old circuit board, which I'm sure would have given microfiring throughout a day such as this. However, I've noticed that there is a bit of a tendency for the house to overheat. The heating curve is already down at a lowly 1.3, and room temperature control is set to "modulating" (which is where I'd like to keep it if I can, rather than going to "thermostat", but I may have to stick to "thermostat" until winter is upon us).

Those with a sharp eye will note that this graph looks a bit different from ones that I have posted previously. That's because I now have an external temperature probe at the top of the low loss header (where the 'flow' pipe leaves), which gives a more realistic measure of the flow temperature than the temperature of the water leaving the boiler. The two can differ because of mixing in the low loss header. The boiler now modulates so as to achieve the desired flow temperature in the low loss header.

Previously, the "Flowsetpoint_DK" (i.e. the target flow temperature) tracked very closely the "BMU_FlowTempOrVF_1.Temperature" (which is the flow temperature as measured in the boiler). Now, however, Flowsetpoint_DK is the target not in the boiler but in the low loss header (LLH). You can see for instance in the long, continuous burn at the start of the day (when Statenumber is 4) that a flow of 36C or 35C is being successfully maintained in the LLH. Presumably the return temperature is gradually increasing over this period, so mixing results in less of a temperature drop of the flow in the LLH, with the observed result that the boiler flow temperature (blue) required to maintain the desired LLH flow temperature (red) gradually decreases until the two coincide, which is roughly the point at which the flame switches off.

I should note for completeness that the LLH temperature probe has nothing to do with the disappearance of microfiring; it was fitted in April, and I was still seeing microfiring when it was there. It is definitely the new circuit board that has alleviated - or hopefully removed - the problem of microfiring.

As to the strange pump-on-all-day behaviour that I mentioned in my last post, I am told that this is a normal and deliberate feature under some circumstances, rather than a problem peculiar to the new circuit board. I can't see the point of it, though, so I'd be glad if someone could point me to a parameter that will stop unheated water from being needlessly pumped around the radiators (beyond the pump overrun time) - I can't see one on either the boiler or the VRC430f that sounds as though it might control this.

Promising signs

On a couple of mornings so far, since fitting of the prototype board, there has been a call for heat. Unfortunately vrDialog does not recognise the new board, so will only collect a small subset of the data that it used to collect. This makes it much harder to monitor the behaviour of the boiler, but yesterday I made manual observations during the 40 minutes or so when there was a call for heat. The signs are good:

There was a continuous burn throughout this period. Thus the boiler was able to sustain a flow temperature at the boiler of 35C or 36C, which I've never seen it do before - typically before it would microfire below about 42C. One slight oddity, though, is that the flow target temperature throughout this period was 28.5C, which doesn't bear any relation the the actual flow temperature (whether at the boiler or at the low loss header, from where a probe is now also wired in to the boiler).

Pending further data, the new board therefore looks as though it may be an improvement over the standard one. All is not quite right, though, since the central heating pump now sometimes stays on all day, even if there has been no heating demand at all, circulating unheated water through the radiators.

Prototype circuit board

Having given Vaillant over six months, in which time - as expected - I heard absolutely nothing from them, last week I sent a letter before action, with the intention of issuing a claim if matters were not speedily resolved.

As if by magic, yesterday I received a call from Vaillant's Product Manager (whom I emailed in November, December and January without ever receiving a response). Today he and the Senior Engineer visited and fitted a new circuit board to my boiler (and gave a welcome apology for Vaillant's failures of communication). He also today fitted such a board to one other person who has been suffering the same sort of problem.

It is a prototype that has been developed in France with the intention of ameliorating the difficulties that I have described on this blog. It has apparently so far only undergone testing within Vaillant, and they now want to try it on the two 'real life' systems on which they fitted it today to see how it performs. I was told that if it is successful, it will become a standard part available for purchase. I have no information about when (or indeed if) that may come to pass, not least because it will take a little while to assess how well it works. For the time being, it is not otherwise being made available.

As to what has changed, the information was a bit vague, which is not a criticism since it may be hard to describe at a high level. I gathered, though, that the focus has been on the ignition sequence and timing.

As the weather cools down over the coming month and the heating starts to kick in, it should become clear whether microfiring is still an issue.

Problem allegedly under investigation by Vaillant

Last week I sent a short email to Vaillant asking for the contact details of its legal department, indicating that I intended to write a letter before action as a prelude to a claim for breach of warranty, since they have not only failed to attempt to fix the problem, but have not even managed to communicate with me about it.

As if by magic, today I received a call from its customer care department - the first contact that I have had from them without chasing. The person I spoke to went away to seek an update on the situation, and came back to say that the problem is under investigation by Vaillant in France (which is a little curious if the 400 series is only sold in the UK). I was told that the timescale for any resolution is unknown.

The fact that it took a reference to legal action to elicit this information (or indeed any information) reflects poorly on Vaillant's customer service. However, it is promising that they are supposedly investigating. Nevertheless, if (as I suspect will be the case) no resolution is forthcoming and I continue to hear nothing from them, I shall start a claim

A different sort of cycling - faulty Legionella protection programme

On a slightly different topic, I've discovered a completely different sort of rapid cycling.

The VRC430f includes an anti-Legionella programme. Legionella can lead to the fatal Legionnaire's disease, and is a problem that can arise when water is kept within the bacteria's growth range of about 20-50C. I set my hot water temperature to 48C, since that's as hot as it needs to be for our hot water needs. But that means that the system is at risk of a Legionella infection, so I decided to try a once-weekly anti-Legionella programme.

It's supposed to heat the cylinder to 70C for one hour to kill the bacteria. However, it doesn't work as advertised. It uses a flow temperature of 85C and just tries to keep going at that temperature, despite the cylinder temperature (green) exceeding 70C:

As soon as the cylinder temperature is above about 70C, the difference between flow and return is not high enough for continuous firing. The result is that the boiler cycles rapidly for about two hours, with the cylinder temperature gradually rising to 85C. The jagged lines in flow temperature (red) and state number (light blue) represent cycling. Just as with microfiring, the boiler does not stay ignited for more than a few seconds before it turns off again, and then it tries again shortly afterwards. I'm not convinced that it's doing my pumps a whole lot of good to be too hot to touch, and it's definitely not a good thing for fuel efficiency or boiler longevity to be short cycling like this.

This is all with the boiler's flow temperature for cylinder charging (parameter d.78) set at 70C (orange), so the VRC430f must be over-riding that. The central heating demand in the graph starts at 6am (as you can see from the HC1_QuickVetoTemp), and is not affecting matters.

So not even the Legionella programme works correctly. Another software problem with the VRC430f, it seems.

Effect of d.2 on microfiring

Recent posts have described the d.2 parameter and the d.67 parameter, and the relationship they have to the period that the boiler waits before it tries to re-start.

One of the commenters (MikeH) reports having obtained good results with preventing microfiring by increasing d.2. Although my data suggested that this would not work in my case, I had not tried it. I now have, and indeed it does not help. Given my data, I'm not sure how it manages to make any difference for Mike.

Here are two graphs that show the period when I increased d.2. The first is just to show what was going in - the first two thirds or so, until about 5pm, shows a period of microfiring. There is then a transition to continuous burn when the target flow temperature goes up to 42C.

Now the same period, showing when d.2 was increased (from the default value of 20min to 60min) and what the countdown timer (d.67, in purple) was doing.

As expected, d.67 now starts at a much higher value - see the table in a previous post for how the actual starting value relates to the new maximum of 60min. But this has no discernible effect on microfiring, and certainly does not seem to have been the trigger for switching to continuous firing.

d.2 (via d.67) can be seen having its intended effect later in the day, at the end of the continuous burn. Then there is enough heat in the house, so the system needs to cool before the boiler can try again to maintain the desired flow. You can see in the following graph that d.67 does a full countdown from about 38min. This is what it should do, with these settings. But when the boiler tries to re-fire, it goes into an extended period of microfiring. This is what is should not do, and the high value of d.2 has not stopped it.

New owner's info provided

Many thanks to MikeH, who has filled out the form giving information on his set-up. It can be accessed on the "Info from owners with the problem" page.

Let's get some more examples up there - at the moment, combing through various posts and comments here and on diynot.com can reveal some detail about people's systems, but it would be much more convenient (and forceful, with respect to Vaillant) to have it all in one place.

Mike says that he made a formal complaint to Vaillant, with no useful outcome. As to what he thinks of their customer service:

"Poor.  I believe they know the issues and are "managing" the problem with minimum transparency.  Clearly they are modifying the boiler in the background but saying nothing to minimise costs and hassle.  No useful information provided."

Vaillant, must do better. Much better.

d.67 - the countdown to boiler re-start

Here's an example of what I take to be d.67, which is the countdown referred to in the last post. In my vrDialog data, I think it must be the parameter called RemainingBurnerblocktime_DK, which is in red in the graph below.

The graph shows a transition (at about 17:00) from micro firing to short firing. Note that the micro firing period does not show all the detail of what happens on a timescale of less than about a minute, so it is missing many periods of boiler status S.4 (i.e. ignited) and many of the short-lived peaks in flow temperature.

This begins to answer some of my questions from the last post. In particular, note that d.67 starts to count down when the boiler goes to state S.7, not when it goes to state S.8. However, I have noticed that it only does so when it is going to go to S.8 next (unless it decides it can re-fire first, as in the micro firing region). Somehow it must already know when it goes to S.7 that it is going to go to S.8 (which it certainly does not always do). The only example in this particular graph is at about 18:44, when it goes to S.7 but not then to S.8 - it did not start the d.67 countdown when it went to S.7, so it must have known it was going to do something different next.

As for which row of the d.2 table my boiler is using (a 438 installed in March 2011), it seems to be as shown in the table - at least when there is a requested flow temperature. See e.g. the second peak in each of the saw tooths, at about 17:30 and 18:12. The target flow temperature is 43C. If we're supposed to round down to the nearest multiple of 5, we should be using the 40C row. My d.2 is the default max of 20min, so the table gives a blocking time of 13min, which is what we see on the graph.

However, I do not understand what is happening on the first peak of each of the saw tooths (i.e. at about 17:16 and 17:58). This is at the end of a period of firing, when the requested flow temperature drops to zero (although there's no need for it to do so, which is why this is short firing rather than normal cycling). In both cases d.67 goes to 19min. This may be entirely unrelated to d.2. It was at a time when my Pump Delay Time on the VRC430f was set to the default of 15min - if had been set to OFF, I'm sure I would have seen a continuous burn here, without any short firing. But why did d.67 go to 19min? Is it related to the 15min setting of Pump Delay Time? I don't know.

What is happening in the micro firing region? The boiler very rapidly tries refiring, despite the d.67 countdown having barely begun. This is presumably because (once the tiny spurt of heat from the few seconds of firing has dissipated) the flow temperature is back at 27C, which must be low enough for the boiler to think it can have another go. But when it does, it immediately exceeds the target flow temperature and cuts off. I'm therefore still not convinced that increasing d.2 will help at all with micro firing, but I shall certainly try when the weather warms up again and micro firing reappears.

Frustratingly my vrDialog data does not appear to include the parameter that corresponds to d.41 (i.e. return temperature), which would enable me to see what the difference is between d.40 and d.41, despite the boiler being capable of displaying d.41 on its screen. The only candidate appears to be ReturnTemperature_DK.Temperature, but it always returns a reading of -1.8 (indicating it is non-functional, which is presumably what is meant by the next parameter, ReturnTemperature_DK.SensorState, returning a value of "cutoff" - contrast e.g. BMU_FlowTempOrVF_1.SensorState, which returns a value of "Ok").

Anti-cycling mode and the d.2 parameter

Sometimes the boiler enters an anti-cycling mode, which is intended to prevent it from trying to re-start inappropriately quickly. Here I gratefully reproduce UpgradeME's explanation of the d.2 boiler code, which determines how long it waits before re-starting:

"This may also be of some use, which explains how the 'anti-cycle' operates. 

Vaillant d.2 code - Example of operation  

Let's assume d.2 is set at 60, the modulating controller is currently requesting a flow temperature of 40C and the burner has already fired. The boiler upon entering anti-cycle mode starts a timer, counting up from zero, with an initial 'goal' of waiting 38.5 minutes, from the following table:

[Caution - MikeH has recorded in the comments below that for his 415, installed in about 2008, the values he gets are as in the table, except in the row above the one indicated. In other words, for a target flow temperature of 70C, his boiler is using the values that the table gives in the 65C row. A 418 boiler fitted in about late 2010 uses the figures given by table without adjustment.]

If after waiting 20 mins, the room temperature drops, the controller then changes its flow temperature request from 40C to say 60C. The anti-cycle time for 60C is 17 mins, but as the timer has already reached 20 mins, there is no anti-cycle time remaining (it's actually now -3mins) so the boiler then fires the burner again.

[anti-cycle time from table] - [timer] = [time remaining before boiler is allowed to re-start]

Initially that would have been be 38.5-0 = 38.5 min then changed to 17-20=-3mins 

The above example is assuming a modulating controller set in 'analog' mode where the flow temperature demand is dynamic. If set to 'two-point' mode (or using a.n.other room stat), the flow temperature is static and set via the dial on the front of the boiler. As an example for a static flow temperature demand, if the boiler was set at 65C, after it enters anti-cycle mode the boiler will wait 11.5 minutes before firing again with d.2 set at 60, or 4.5mins with d.2 set at its default of 20. Pump is off and zone valve(s) are closed during anti-cycling period."

I've edited this description slightly from UpgradeME's text to make it clearer (and in particular have altered the equation, which seemed to have the two parameters the wrong way round). Let me know if I've got the wrong end of the stick here.

I suspect that the way the timer is described as working (counting up) is not strictly accurate, since parameter d.67 is "remaining burner anti cycling time" (i.e. a count down). I had already noticed what appeared to be a countdown as one of the vrDialog-recorded bits of data on my system, but had not worked out exactly where it came from or what it was doing. I shall post some graphs of how d.67 looks when I have time.

The way the ecoTEC manual describes this process is:

"The burner is electronically locked for a specific time after each time it is switched off ("re-start interlock") to avoid frequent switching on and off of the burner (energy losses).
The burner anti-cycle time is only activated for the heating operation. Hot water operation during a burner anti-cycle time does not affect the timer.
The individual anti-cycle time can be matched to the hydraulic and thermal properties of the heating installation. In the factory the burner anti-cycle time is set to a value of 20 minutes. It can be varied under diagnosis point "d.02" within the range 2 minutes to 60 minutes. The individual effective anti-cycle time is calculated from the momentary target feed temperature and the set maximum burner anti-cycle time.
The timer can be reset or cancelled by actuating the appliance main switch. The remaining burner anti-cycle time left after switching off by the controller in heating operation can be called up under diagnosis point "d.67". The individually effective burner anti-cycle times with respect to the feed temperature and the maximum set burner anti-cycle time can be taken from Table 7.2"

It does sound from this as though d.2 could be relevant to micro firing, since "avoid[ing] frequent switching on and off of the burner" is exactly what we aim to do. However, I cannot presently see that the d.2 setting can be the (sole) cause of micro firing in my system, for instance. I have not changed it from the factory setting of 20 min. I routinely see micro firing at a target flow temperature of 40C, which the table indicates as corresponding to an anti cycling time of 13 min. But the boiler often tries to re-start immediately (within seconds), rather than waiting anything like 13 min. The sorts of timescales indicated by the table look more like what is controlling the interval between periods of short firing.

Can anyone explain to me when the boiler does enter anti cycling mode? That is status code S.8. Sometimes when the boiler switches off, it goes to S.7 (pump over run, which presumably means that it keeps pumping for a period determined by parameter d.1)  but not to S.8. But sometimes it goes to S.8. For instance, see the status code graph during a few minutes of micro firing that is on the page called "The problem" - there it never enters S.8, so can d.2 be relevant at all during this period? Perhaps it ought to be going to S.8, since it would then wait a respectable length of time before re-firing instead of doing so straight away.

Return sensing

A commenter on this blog has helpfully noted that he has found a way to avoid cycling, by setting the controls to "return regulation". He has a 392 controller rather than a VRC430:

"The 392 is also missing a "minimum flow temp" setting which makes masking the short/micro cycling all the more difficult. The only way I found was to set d.17 to return regulation which has the effect of increasing the minimum flow temperature and stopping the micro cycling."

In our hands, this change - on its own at least, and in the context of a VRC430f - does not help our systems, but perhaps it will help others.

To explain, the default state of the boiler is flow sensing, which is to say that the boiler (and the controls) monitor the temperature of the water leaving the boiler (the 'flow'), and uses this as the basis for controlling the boiler. This can be changed so that instead the temperature of the returning water (the 'return', unsurprisingly) is used. The change can be made by altering parameter d.17 on the boiler from its default state of zero to one.

This change was made on Vaillant's first visit to the other author of this blog, who has a 428 boiler, in June 2011. The Vaillant employee (Mick Shorter, who is the relevant product manager - presumably for the weather compensation controls) did not explain why he thought that might improve things. Anyway, he changed d.17 from 0 (flow sensing) to 1 (return sensing) and left it that way. Subsequent charts showed no difference.

I also tried this change on my boiler (a 438), with the help of my installer. The result is shown in this graph, where the behaviour both before and after the change is short firing (ignore the >70C peak, which is hot water demand) (pdf of graph here):

I left it on return sensing for about three days, and the behaviour stayed the same. I did not observe micro firing in this period, but that is not to say that micro firing was abolished, since it is not always observed.

However, the effect on short firing - as shown in the graph - was decidedly detrimental. Instead of the boiler staying ignited for maybe 20min at a time, it only stayed on for about 3-5min before going into anti-cycling mode. I therefore reverted to flow sensing.

Another poster on diynot.com also found that return sensing did not help: "I'd be seriously miffed if there was a magic fix. I had hopes for d17 but experiments showed it to be unhelpful."

However, the graph described above was before I knew how to rid myself of short firing by using the Pump Delay Time setting (see page entitled "What works and what doesn't"). I shall therefore repeat the d.17 experiment when the opportunity presents itself.

Introduction to the blog

This is the beginning of a blog devoted to a problem experienced by some owners of Vaillant 400-series boilers in the UK, whereby the boiler cycles on and off rapidly and repeatedly under certain circumstances when used with weather compensation controls.

Please explore the pages on the tabs above entitled "The problem" etc for more details, and to see what we know already and what we don't. We're particularly keen to make contact with others who are experiencing the problem, and for them to add details of their systems to the area accessible through the page called "Info from owners with the problem".