Skip to main content

Troubleshooting our Buderus Logamatic 4000 based heating system, part II (manifolds)

In the last part of this series, I've outlined the heating system in our newly acquired house, which had some issues: namely it was not warm enough.

As a  software engineer I was trying to find the problem by modeling the components in the system, then by coming up with a theory that could be the root cause, then either prove or disprove it by doing measurements. Even if the theory is wrong, I learn something about how the stuff works. If I am right I get closer to solving the problem.

The first theory I had was about water flow. I was kind of sure that the boiler produces enough heat, but if the hot water is not flowing through the pipes in sufficient quantities our rooms will remain cold.

So I was trying to find how I can find the flow information. The answer lies  in the heating manifolds:


I have one of these on all floors of the house, their role is to distribute the incoming hot water into multiple downstream pipes (under the floor heating or wall heating) and then collect them back. You can see the red one which is the hot side, and the blue one is the cold side.

As you can see, I have 8 circles in this manifold, each of which can be opened/shut using an electronic motor (driven by temperature control). The flows of the circles are shown on the cold (blue) side.

Those plastic thingies on the top of the collection  side show how much water per minute is flowing though a specific circle.


There's a yellow plate in these that move up as water flows, but there are versions that move down. You will find a scale there to show the amount proportional to the movement of the plate.

The water that needs to cross is measured in litres/minute, but I have seen the use of cubic meters per hour as well.

The minimum you need depends on how much wattage you need in a room to heat it. This is typically specified in the heating designs of your house. I needed somewhere between 2-5 litres per minute. This is important as the wattage depends on how much water you pump in a room and how much degrees it cools down while in there.

If you need 2kW per hour, water cooling down 4 degrees, you will need roughly 120 liters per hour, eg 2 liters every minute. (Basic physics).

I actually had much less than that 2-5 litres (in some cases 1-1.5), especially when more rooms were heated, that  was one issue that needed fixing, so at this point I decided to eventually check out the pump that drives the water flow in the pipes.

Interestingly, the flow measurements weren't entirely conclusive as one of the bathrooms was pretty warm even though it's flow was only a trickle, and I had to find out why.

So next, I decided to check out the thermostats, as I suspected their settings were customized by the previous owner. Since the house has a KNX based smart home infrastructure,  to check out these adjustments I needed to set up access to the KNX bus as well as install the software needed (ETS). But more on these in the next episode.


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