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 OSE 2.1 released

I have just uploaded the first release in the syslog-ng Open Source Edition 2.1 branch to our website. It is currently only available in source format at this location: http://www.balabit.com/downloads/files/syslog-ng/sources/2.1/src This release synchronizes the core of syslog-ng to the latest PE version and adds the SQL destination driver. This is an alpha release and thus might be rough around the edges, but it basically only contains code already tested in the context of the Premium Edition. The SQL functionality requires a patched libdbi package, which is available at the same link. We're going to work on integrating all our libdbi related patches to the upstream package. If you want to know how the SQL logging works, please see the Administrator's Guide or our latest white paper Collecting syslog messages into an SQL database with syslog-ng. The latter describes the Premium Edition, but it applies to the Open Source one equally well.

syslog-ng 3.2 changes

I've just pushed a round of updates to the syslog-ng 3.2 repository, featuring some interesting stuff, such as: SQL reorganization: Patrick Hemmer sent in a patch to implement explicit transaction support instead of the previous auto-commit mode used by syslog-ng. I threw in some fixes and refactored the code somewhat. Configuration parser changes: the syntax errors produced by syslog-ng became much more user-friendly: not only the column is displayed, but also the erroneous line is printed and the error location is also highlighted. Additional plugin modules were created: afsql for the SQL destination, and afstreams for Solaris STREAMS devices. Creating a new plugin from core code takes about 15 minutes. I'm quite satisfied. With the addition of these two modules, it is now possible to use syslog-ng without any kind of runtime dependency except libc. The already existing afsocket module (providing tcp/udp sources & destinations) is compiled twice: once with and once withou...