Bazsi's Home Automation blog

In this series of blog posts I am revisiting the process of troubleshooting the heating system in our new house. In the past installments I've described the most important elements of the system (and the ones I fixed), since those didn't reveal the true issue with my heating, I needed to go on. This post is about my monitoring gear. Temperature sensing was a key element of finding the solution. First of all, I have a number of analogue temperature gauges around the boiler/furnace, each attached to a specific section of the system. What I had to learn was that these gauges are very slow to react, and thus were pretty much unusable for my goals. If your temperature has very low volatility, they might be fine, but if you want to understand how and why temperature changes, you will need something that gives you a reading every 10-30 seconds. To address this problem I used a dormant Raspberry Pi and a pair or Onewire sensors I had lying around. These were of the type DS18...

This post is a continuation of my last post about KNX thermostats , which is part of my series about the troubleshooting of our heating system. In the last post I gave a "software sided" intro on our smart thermostats, but I've found the control theory behind these devices even more fascinating. But first of all, let me introduce you to our thermostats: As you can see, there are some leds, a push button and a rotary control labeled from -3 ... +3. The leds indicate the current operating mode (comfort, standby & night mode), as well as frost and heat protection. The rotary control allows the user to customize the temperature in the room: the mid-point is set with KNX parameters and the user may subtract from or add to maximum 3 degrees to that value. I mentioned in the last article that the midpoints were not set to the same value, which could explain some of the temperature differences. I also mentioned that you can set an adjustment to the temperature measu...

As described in the previous incarnations of this series ( part I: introduction , part II: heating manifolds ), the heating in our new house wasn't working very well, and I was working on finding out the root cause, as someone without too much proficiency in mechanical engineering, but with a software engineer background. This installment is about our smart thermostats connected to a KNX (aka EIB) based backbone , that control the valves (turn on/off) on our heating manifolds for per-room temperature control. I described in the previous post, I was suspicious of the thermostats, as some of our rooms were set to the same temperature, and one was warm while the other was cold. These thermostats have a couple of parameters that can be adjusted that would significantly change their behavior. The most important ones from my perspective are the temperature adjustment: to offset to be added/substracted to the measured temperature to counter potential sensor errors the base setpoi...

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...

This story is about my journey as an IT professional into the realms of heating control systems, where I had basically zero experience. I was learning the guts of such a system at my own expense, and today I am confident in changing even major parameters of my pretty complicated setup (for a house anyway). My motivation for writing this story is 1) to document it for myself and 2) to make it useful for those who are fighting similar issues. I am an engineer, but not a mechanical engineer: I had no clue about pumps, valves and control systems. Yet, I was able to decompose and understand what I found and came up with solutions to my problem(s). So here it goes. How it all started We've recently moved into a new house with one nightmare scenario: it's not going to be warm enough. I was telling my wife that this was impossible: just look at the oversized boiler in the basement. 55kW, it's HUGE. No way, we'll have issues with temperature. But at the end she is a...

This was my personal blog that I abandoned ~10 years ago in favor of a corporate blog.  I am reviving it and continue where I left off. This blog has focused a lot on technology and syslog-ng particular and that is something I don't want to change. I work a lot on home automation these days so I expect that to creep in. It's difficult to explain a decade in a blog post but a few items follow that I consider noteworthy: * syslog-ng became pretty successful as a commercial offering while still keeping the open source version in shape. In this 10 years the project produced 23 major syslog-ng releases with lots of new stuff open source first. * Balabit a company has grown to 250+ employees EUR 20m+ revenue and was eventually sold to a US company called Quest/One Identity in 2018 * I left Balabit a year and a half later in 2019, the company behind syslog-ng, the one I was a founder of. syslog-ng is still thriving and is gaining momentum. This is true for both the open so...

This was first posted as a comment under an article on lwn.net, but I thought it was important enough to post it here for others not reading lwn. Please go ahead and read the original article which is about the "Open Core" business model and its problems from the Free Software community point of view. A commenter thought that syslog-ng was an example, which only exists as a marketing tool for the company's commercial offering. Anyway, here's my post: First of all, I want to make it clear that I'm biased on the syslog-ng case, but still wanted to express my opinion here. I'm biased as I'm the primary author of syslog-ng. I think syslog-ng is a completely different case from the one described by Neary. The GPL version is not crippleware, it was never published for marketing purposes only and for the majority of syslog-ng's existence only the Open Source stuff existed. The Premium Edition is only about 3 years old and syslog-ng started in 1998. W...

I've just uploaded syslog-ng 3.2alpha2 to the release directory . The last alpha release didn't compile on all supported platforms and the automatic test-suite was disabled, because it only worked if syslog-ng got installed first. These obstacles have been overcome and together with some fixes and a couple of new features, 3.2alpha2 is now available. I've also forward ported all bugfixes from syslog-ng 3.1.2. For those who are starting to experiment with the 3.2 branch, here's the list of new features compared to 3.1. Those who tried 3.2alpha1, the list of changes compared to 3.2alpha1 is at the end of this post. Since the documentation of syslog-ng is not yet up-to-date with the new features introduced, I've tried to also include URLs for the best known descriptions. The references may not be 100% accurate, but should give anyone interested an idea how to start experimenting. Also, please note that although this is an alpha release, the bulk of the changes are in t...

I was giving a lot of thought recently to the topic of naming name-value pairs in syslog-ng. Until now the only documented rule is stating somewhat vaguely that whenever you use a parser you should choose a name that has at least one dot in it, and this dot must not be the initial character. This means that names like MSG or .SDATA.meta.sequenceId are reserved for syslog-ng, and APACHE.CLIENT_IP is reserved for users. However things became more complex with syslog-ng OSE 3.2. Let's see what sources generate name-value pairs: traditional macros (e.g. $DATE); these are not name-value pairs per-se, but behave much like them, except that they are read-only syslog message fields (e.g. $MSG) if the message is coming from a syslog source filters whenever the 'store-matches' flag is set and the regexp contains groups rewrite rules, whenever the rewrite rule specifies a thus far unknown name-value pair, e.g. set("something" value("name-value.pair")); and of cour...

syslog-ng 1.6.x and 2.0.x versions had lived quite long. A lot of distributions used these versions and never upgraded to the newer ones. This has changed recently, Peter Czanik was busy to help maintainers get to the latest versions. Already available in the latest release: openSUSE FreeBSD ports Mandriva Gentoo portage OpenBSD ports In development branches: Debian Ubuntu Fedora These all carry 3.1.1, which is quite recent (and a successful release too). There are some fixes accumulated in the git tree though, so I hope to get 3.1.2 out of the door soon.

In one of my previous posts , I've mentioned that syslog-ng is not for syslog anymore, we aim to support other log formats too, preferably those that have some kind of structure. In fact syslog-ng is trying to convert all incoming messages (be them unstructured syslog messages, process accounting messages or SNMP traps) into the same, common format: name-value pairs tag or tags that connects the event to one of the patterndb schemas This information coming in from different sources can be stored and processed with the same infrastructure. Correllation between SNMP traps and syslog messages or netflow records should be possible. I probably don't need to mention, that we use patterndb to extract information from syslog messages. But structured information sources contain name-value pairs in the first place, so why not use them natively? This is what the experimental process accounting feature of syslog-ng demonstrates. With this module, syslog-ng is able to read the process accou...

I thought I'd post a quick update on the patterndb project status. Our first aim was to draft a basic policy which governs how patterns should be created. This is available in the patterndb git repository as a README.txt file. Although not completely finished, I feel the current description is enough for some basic work to start, to gather more experience. Here is the current version: http://git.balabit.hu/?p=bazsi/syslog-ng-patterndb.git;a=blob;f=README.txt;hb=HEAD Also, after discussing the policy we've set a target to cover login/logout events from all parts of a generic Linux system. Currently sshd is quite nicely covered, su is coming along and I still have some submitted log samples that need marking up. With the sshd/su patterns a quite nice percentage of my "auth.log" file is covered and using pdbtool " grep on steroids " feature, the marked up patterns are already quite useful. Further log samples and a hand in helping me out to mark up the patterns...

You may have heard of my last project to collect log samples from various applications, in order to convert log data from free-form human readable strings into structured information. The first round to collect login/logout messages from sshd is now complete. You could ask: ok, but what is the immediate benefit? You supposedly have a lot of unprocessed log files, and syslog-ng's db-parser() has not been used to process them, thus they are stored as good-old plain text files. I spent a couple of hours to add a "grep"-like functionality to pdbtool which makes it easy to process already existing log files, giving you immediate benefit for each and every sample added to patterndb. For example, if you are interested in login failure events, you could say: zcat logfile.gz | pdbtool match -p access/sshd.pdb \ --file - \ --filter 'tags("usracct") and match('REJECT' type(string) value("secevt.verdict"));' \ --template '${usracct...

Starting with syslog-ng OSE 3.2, syslog-ng became plugin based, which has some consequences that even experienced syslog-ng users may stumble into. The most obvious one, is that syslog-ng now produces a series of .so files loaded at runtime, instead of being a monolithic executable. If a given .so is not not or not loaded, some of the functionality may be missing. This usually manifests itself by a syntax error when parsing the configuration file. Second: if you compile syslog-ng from source, the unit/functional test programs also want to load plugins, and they try to do that from the install directory. This means that you first have to install syslog-ng using "make install" before running the testsuite. This is not an ideal solution, but should work for now. Plugins are loaded from $prefix/lib/syslog-ng by default, however this can be changed using the `module-path` global, which contains the list of directories where syslog-ng should look for modules. You can change this us...

syslog-ng has been around for about 12 years now, but I think the biggest change in the project's life is imminent: with the upcoming release of syslog-ng OSE 3.2, syslog-ng will become an independent entity. Until now, syslog-ng was primarily maintained & developed by BalaBit, copyrights needed to be reassigned in order to grant BalaBit special privileges. BalaBit used her privileges to create a dual-licensed fork of syslog-ng, named "syslog-ng Premium Edition". The value we offer over the Open Source Edition of syslog-ng are things that larger enterprises require: support on a large number of UNIX platforms (27 as of 3.1), smaller and larger feature differences (like the encrypted/digitally signed logfile feature) better test coverage and release management longer term support Although perfectly legal, this business model was not welcome in various Free Software communities, and has caused friction and harm, because BalaBit has enjoyed a privilege that no others cou...

By now probably most of you know about patterndb, a powerful framework in syslog-ng that lets you extract structured information from log messages and perform classification at a high speed: http://www.balabit.com/dl/html/syslog-ng-ose-v3.1-guide-admin-en.html/concepts_pattern_databases.html Until now, syslog-ng offered the feature, but no release-quality patterns were produced by the syslog-ng developers. Some samples based on the logcheck database were created, but otherwise every syslog-ng user had to create her samples manually, possibly repeating work performed by others. Since this calls out to be a community project, I'm hereby starting one. Goals Create release-quality pattern databases that can simply be deployed to an existing syslog-ng installation. The goal of the patterns is to extract structured information from the free-form syslog messages, e.g. create name-value pairs based on the syslog message. Since the key factor when doing something like this is the naming of ...

I've just commited a small incompatible change for syslog-ng 3.1, even though theoreticaly I shouldn't have. The change is not big, simply the 'store-legacy-msghdr' flag became default for all sources, whereas earlier you had to specify that explicitly. In order to understand why I did that, a short description of the flag follows below. syslog-ng processes all incoming messages into fields (things like $PROGRAM and $DATE) and then reconstructs the message based on this parsed information when it has to write the message to a file. Before syslog-ng 3.0 a message was split into the macros: "$DATE $HOST $MSG", which expanded to the actual log message. "$MSG" above was expanded to a line like: "program[pid]: message" With syslog-ng 3.0 and the integrated handling of RFC5424 and RFC3164 this format was changed and an $MSGHDR macro was created for the "program[pid]: " part and I got rid of this part from $MSG. (of course if you are run...

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...

The SQL destination in syslog-ng so far assumed that databases automatically start a new transaction for each INSERT statement that syslog-ng issues. This works fine, however there is a significant overhead of starting new transactions, with sqlite I've measured about 20 times performance increase on my development notebook and my debug build. With explicit-commits: bazsi@bzorp:~/.zwa/install/syslog-ng-ose-3.2$ loggen -x -r 1000000 -I 10 -S log average rate = 9377.28 msg/sec, count=93776, time=10.003, msg size=256, bandwidth=2344.32 kB/sec With per-statement (automatic) commits: bazsi@bzorp:~/.zwa/install/syslog-ng-ose-3.2$ loggen -x -r 1000000 -I 10 -S log average rate = 529.46 msg/sec, count=5299, time=10.083, msg size=256, bandwidth=132.36 kB/sec So this really seem to matter. In order to configure it you can use the following options in an SQL destination: flush_lines/flush_timeout controls how much messages get into the same transaction, similar to what these parameters mean f...

After last the stable syslog-ng 3.1.0 release last week, I've opened the 3.2 branch to receive the new stuff. The first bits are already in the repository: the basic plugin framework and the conversion of the socket related stuff (tcp, udp, unix-dgram, unix-stream, syslog drivers) into a separate plugin. The reason of the afsocket plugin conversion is to help moving the OpenSSL dependency to a separate package in distributions where this dependency cannot be associated with core packages like syslog-ng. But I see a lot of potential behind the plugin framework, and I still have a lot of ideas, just check my last blog post in the topic . Also, there's an even more experimental feature in the "blocks" branch right now, it is still incomplete, the naming and the syntax is still vague. The aim is there to provide syslog-ng.conf C++ template-like functionality in order to make the configuration easier by using pre-configured config snippets. For example: block source tomca...