Skip to main content

Troubleshooting our Logamatic Logamatic 4000 based heating system, part VI., the solution

In the past installments of this post series, I was writing about how I, as a software engineer, started troubleshooting the heating system in our new house. This all started by acknowledging there was a problem (part I), understanding the basic heating components, such as manifolds (part II). Smart thermostats and PID controls (part III and part IV).

The solution needed in-depth monitoring/debugging so part V was about 7 pieces of DS18B20 sensors and a Raspberry Pi, I've installed in the boiler room.

The solution was a bit of a surprise and may I add, I was kind of shocked about the simplicity of the solution once I knew the issue.

Remember, that the original reason I started the whole exercise was to make comfortable temperatures in the house, as it was a bit cold.

After I've excluded all relevant problems (manifests, water-flow, thermostats, pump, etc), all I had left was to increase the boiler temperature, thereby increase the temperature of the water in the house as it was lingering at around 28-32C°.

To achieve higher water temperatures in the house, I started to increase boiler output (e.g. I set the temperature higher), which resulted in 36-38C° in the pipes. This seemed a win at first, as our house was finally getting warm :)

At this point however, I had to realise that from time-to-time the water became too hot, sometimes it reached up 48-50C°, which is definitely not in the right range and can damage your pipes/fittings.

Mixing valve


As explained in part I, the boiler is heating water to a specific setpoint, which is then circulated into the house using 3 interconnected heating circles:
  • inside the boiler (kesselkreiss): regulated by the Logamatic system based on heat needs in the various heating zones (which we have 5 of)
  • primary house heating circle: regulated by the Logamatic system to somewhere between 30-40 C°, depending on external temperature
  • secondary house heating circle: connected to the primary through a heat exchanger, producing warm (~30 C°) water for wall/ceiling/underfloor heating in the house.

The setpoint temperature of the boiler is derived from the outside temperature  and the target room temperature set using the MEC2 unit (basically a thermostat + programming console), using a very simple formula (basepoint characteristics, explained in the Logamatic manuals).

Without going into specifics, this formula usually sets the boiler to around ~50C°. However, due to how gas boilers operate, this is far from a constant, regulated temperature and would mean that the temperature of the boiler fluctuates somewhere between 43C° - 57C°.

To control this fluctuation and to permit multiple heating circles in parallel, the system uses a mixing valve between the boiler's hot water and the house's primary heating circle (e.g. this is the second of the circles explained above).

This is the mixing valve (the green one in the middle):


The role of the mixing valve is to mix hot and cold water. The position of the valve determines how much of each is used for mixing, thereby resulting in a more controlled temperature on the output side. The position is controlled using a stepping motor, for which it takes 120 seconds to fully open (e.g. hot water only) or fully close (e.g. cold water only) the valve. The picture above is with the motor removed, and this is the picture with the motor attached.



I could see the motor going in both directions: it has a pretty distinctive sound and the position can be read from the scale.

Heureka!


At one point I was standing in the boiler room and was looking at the boiler heating up to pretty high temperatures (hot water kicked in and that increases the setpoint to ~70C°) and as expected the boiler was shutting the mixing valve, so the extremely hot water would not be getting into the house primary (which had a setpoint of ~40C°).

What I saw however was that the temperature of the house primary was going through the roof (sic!) and I double-checked by grabbing the section of the pipe, right after the valve with my bare hands. It was HOT.

So, even though the motor is working properly, the boiler is shutting the valve and the valve in the completely shut position, hot water is still getting through. We are getting somewhere!

This was the culprit, with my "fix" already applied:


That piece of plastic is the axle of the motor, one that connects a turning rod and the valve. The plastic broke, therefore the boiler couldn't perform regulation of the house's heating zone properly.

My solution was to use a "bond" (not sure of the right term, directly translated from the Hungarian "bilincs", the metalic thing around the plastic with a screw to fasten it), so the broken plastic holds in place.

I've confirmed that the solution works, the motor now was able to turn the valve! I reported to my wife that a solution was found and was pretty happy.

Still not there...

I grew the habit of continuously checking the various temperatures, as reported by the sensors I've attached to the boiler. (my wife was joking about me being lost in the boiler room for 3 weeks...)

So, the motor was up, the boiler is controlling the valve, I can see it moving and... the same thing happens. The secondary heating zone is still getting hot, even when the valve is fully shut.

At this point I was quite unhappy, as I imagined that the mixing valve itself has gone awry and that it needs to be replaced.

I was googling for the symptoms of the valve to confirm this finding, when I eventually found the manual of the mixing valve. It is manufactured by Honeywell, and it is of the type DR20GMLA.

From reading the manuals, I noticed that depending on the mounting position, the zero point of the valve is different:


Mine was installed as the right-hand side illustrates. Also, I didn't pay too much attention into restoring the zero position when reinstalling the motor, as I didn't know it mattered.

In any case, I discovered that the valve had markings for "R" and "L" on its axle, so I made sure they are positioned as on the picture above.

... and the final piece of the puzzle

I am not trying to bore you, but it still didn't work. I did confirm that the valve itself is operational as I was manually opening/closing it, I could achieve a position where hot water was not getting through.

The last reason the valve was botched, was the motor's direction. If you look at the figure above on "Mounting", you will see that the left-hand side opens by turning clock-wise, whereas the right-hand side opens by turning anti-clock-wise.

And imagine that the valve control motor, installed roughly at the time the house was built (~20 years ago, I found a year of manufacturing in it) was installed in reverse!

This has _never_ worked correctly.

After believing I was right (and doubted myself a lot), I changed polarities and bang, everything fall into place and has worked ever since.

Conclusion

So someone built a house 20 years ago with an incorrectly installed heating system, and the owner did nothing to fix it or could not fix it.

I think the reason for this being covered for that time is that it "almost" worked. Issues and workarounds papered over one another hid the root cause so much that it took an effort to uncover it, just like in software, where developers often  use workarounds instead of fixing a bug properly.

Contractors would not spend the amount of time I did, they would probably replace part after part, which would become expensive without solving the problem.

It was this systematic approach that exposed the issues in their full depth. I think the fact I am regularly finding myself in scenarios where I have to debug complex issues in software helped me a lot.



Comments

Popular posts from this blog

syslog-ng fun with performance

I like christmas for a number of reasons: in addition to the traditional "meet and have fun with your family", eat lots of delicious food and so on, I like it because this is the season of the year when I have some time to do whatever I feel like. This year I felt like doing some syslog-ng performance analysis. After reading Ulrich Deppert's series about stuff "What every programmer should know about memory" on LWN, I thought I'm more than prepared to improve syslog-ng performance. Before going any further, I'd recommend this reading to any programmer, it's a bit long but every second reading it is worth it. As you need to measure performance in order to improve it, I wrote a tool called "loggen". This program generates messages messages at a user-specifyable rate. Apart from the git repository you can get this tool from the latest syslog-ng snapshots. Loggen supports TCP, UDP and UNIX domain sockets, so really almost everything can be me

syslog-ng roadmap 2.1 & 2.2

We had a meeting on the syslog-ng roadmap today where we decided some important things, and I thought I'd use this channel to tell you about it. The Open Source Edition will see a 2.1 release incorporating all core changes currently in the Premium Edition and additionally the SQL destination driver. We are going to start development on the 2.2 PE features, but some of those will also be incorporated in the open source version: support for the latest work of IETF syslog protocols unique sequence numbering for messages support for parsing message contents Previously syslog-ng followed the odd/even version numbering to denote development/stable releases. I'm going to abandon this numbering now: the next syslog-ng OSE release is going to have a 2.1 version number and will basically come out with tested code changes only. The current feature set in PE were developed in a closed manner and I don't want to repeat this mistake. The features that were decided to be part of the Open

syslog-ng 3.0 and SNMP traps

Last time I've written about how syslog-ng is able to change message contents. I thought it'd be useful to give you a more practical example, instead of a generic description. It is quite common to convert SNMP traps to syslog messages. The easiest implementation is to run snmptrapd and have it create a log message based on the trap. There's a small issue though: snmptrapd uses the UNIX syslog() API, and as such it is not able to propagate the originating host of the SNMP trap to the hostname portion of the syslog message. This means that all traps are logged as messages coming from the host running snmptrapd, and the hostname information is part of the message payload. Of course it'd be much easier to process syslog messages, if this were not the case. A solution would be to patch snmptrapd to send complete syslog frames, but that would require changing snmptrapd source. The alternative is to use the new parse and rewrite features of syslog-ng 3.0. First, you need to f