Katastrophos.net Blog

FHEM, the amazing home-automation server software, already has support for several sensors, meters and switches produced by ELV. In October 2010 I bought two meters, ESA1000WZ and ESA1000GAS for my house in the hope that FHEM would support them. Unfortunately it did not (at the time). I quickly found some hints that somebody, namely Gerd K., was working on adding support. So I contacted him and a day later received his module for testing. In the meantime eager in anticipation I was hacking away, duplicating the existing EM1000 extension and customizing it to read the raw strings coming from my Busware.de CUL 868 MHz USB adapter. While I got the power meter’s values (ESA1000WZ) figured out pretty quickly, it was a bit more involving to get correct readings from the gas meter (ESA1000GAS). Unfortunately Gerd’s code did not include support for the gas meter, so I emailed him my changes, but sadly never received feedback.
So today I am releasing my code on a works-for-me basis:

Download

CUL_ESA.tar.gz Version: Oct 25th 2010

• Supports ESA1000WZ power meter (infrared version, possibly others as well)
• Supports ESA1000Z and ESA1000GAS gas meters (infrared version and version using impulse transducer for the Elster-Kromschroeder BK-G4)
• Features proper graph files to plot current and cumulated day/month consumption

Photos / Screenshots

Installation

Copy 19_CUL_ESA.pm and all .gplot files to your FHEM directories.
Sadly adding autocreate support and extending the CUL module to understand the raw message strings requires patching. Check cul_esa-for-fhem-5.0.patch to patch the files. This was diffed against the Debian package of FHEM 5.0. The very same version of FHEM as tar.gz has some differences in the sourcecode and some files missing. I contacted the author of FHEM about this issue but he has not updated the packages yet. So if you run into issues here it is probably due to these differences.

UPDATE: Here is a completely patched version based on the Debian package of FHEM 5.0: fhem-5.0-cul_esa.tar.gz Version: Oct 25th 2010

Here are some notes in German I made while developing the module, mostly concerning the different behavior of the ESA1000GAS compared to the ESA1000WZ:

Der ESA1000GAS mit dem ESA1000Z-Messgerät verhält sich leider anders als das ESA1000WZ, sodaß ich wieder die Korrektur-Faktoren einbinden mußte.
Ich konnte nicht herausfinden, wozu der übermittelte Tick beim ESA1000Z dient. Zwar ändert sich dieser mit geänderter Zählerkonstante, allerdings ergibt der Wert im Zusammenhang mit den von der Einheit übermittelten Werten keinen Sinn, sodaß ich hier direkt mit der Zählerkonstante multipliziere, um die Kubikmeter zu erhalten, und dann zusätzlich noch mit dem Umrechnungsfaktor (bei der EWE ergibt sich dieser aus der Zustandszahl * Brennwert Hs) multipliziere, um die Kilowattstunden aus der Gasmenge zu erhalten.
Leider ändern sich damit die Parameter bei der Definition:

Stromzähler:
define CUL_ESA_286 CUL_ESA 1925 286 1 1 23.086
also:
corr1 = corr2 = 1 (und damit wirkungslos)
CostPerUnit = 23.086 Cent/kWh

Gaszähler:
define CUL_ESA_798 CUL_ESA 1429 798 0.001 9.5154 4.5339
also:
corr1 = 0.001
corr2 = 9.5154 kWh/m3
CostPerUnit = 4.5339 Cent/kWh

Ich habe ebenfalls noch einen Durchschnittswert in Kilowatt implementiert, sodaß man die Durchschnittleistung einigermaßen sinnvoll in einem Diagramm darstellen kann. Hier gab es allerdings bei meinem Drehstromzähler Probleme mit Unterabtastung, weil sich die Drehscheibe bei geringem Verbrauch zu langsam dreht, sodaß das Meßgerät zwischendurch schon Nullwerte zurückmeldet, weil kein Impuls eingegangen ist. Dafür habe ich einen entsprechenden Schwellenwert bei der Berechnung des Durchschnittswertes implementiert. Nicht schön, funktioniert aber für meine Zwecke.

I’m currently setting up a nightly build system for Quasar on my Linux box which is running Debian. This system also cross-compiles Quasar for Windows.
The Windows version of Quasar is going to be available in two fashions: one self-contained, portable version and one version that can be installed.
I’m not a huge fan of installers. But when it comes to creating a setup program for a given Windows application I’m quite accustomed to Inno Setup having used it for years. Unfortunately there is no native Linux version of the Inno Setup compiler available for Linux. NSIS exists as package for Debian but I am not fond of using it, largely because I am a Delphi guy. :)
So, here is a small guide on how to get the Inno Setup compiler up and running on Debian:

First step is to install Wine either as super user or by using sudo:

sudo apt-get install wine

As normal user fire up your X server and your favourite terminal application and get the latest Inno Setup QuickStart pack:

mkdir /tmp/innosetup
cd /tmp/innosetup
wget http://files.jrsoftware.org/ispack/ispack-5.2.3.exe
wine ./ispack-5.2.3.exe

This will start the installer in Wine. Note, for the installation you will need a running X11 server since the installer obviously is graphical. If you have not set up Wine before, the default location C:\Program Files\Inno Setup 5 will install to ~/.wine/drive_c/Programme/Inno Setup 5.

Luckily the Inno Setup compiler offers a command line interface, ISCC.exe, which will run in Wine without the necessity of having a X server running. So it is ideally suited for automated runs.

Here is a simple wrapper shell script called iscc:

#!/bin/sh
unset DISPLAY
scriptname=$1
[ -f "$scriptname" ] && scriptname=$(winepath -w "$scriptname")
wine "C:\Program Files\Inno Setup 5\ISCC.exe" "$scriptname" "$2" "$3" "$4" "$5" "$6" "$7" "$8" "$9"

I installed this script in my local bin directory (~/bin) and added it to the PATH environment variable.
This will allow running the Inno Setup compiler from anywhere and it also makes it very easy to integrate into a build script. You can even feed a script via stdin, e.g. something like:

iscc - < ./myscript.iss

As a follow-up to my previous entry about greylisting, here is what I used for the setup: the greylisting patch at Bill Shupp’s wonderful qmail related site.

I’ve made some modifications to his patch to allow for sender address and sender domain based whitelisting.
You can get my patch here:

large-qmail-patch_greylisting-katastrophos.net-20061023.patch

The dbdef.sql file includes an example of how to set up a whitelist filter for a specific sender domain or sender address.

The patch is against Bill’s Large Qmail Patch 0.8.3.

Three weeks ago I’ve set up greylisting on our little qmail toaster. The technique works amazingly well on our setup:
The server used to get hit by round about 1600 mails each day. Roughly 70% of those were spam mails. Now, with greylisting activated, this amount has been reduced to just a dozen spam mails and around 350 – 400 legit emails:

The server load is also reduced because SpamAssassin and ClamAV are less busy filtering mails:

So, speaking for us, this experiment has been very successful. Exactly no real mails got lost, tons of spam was blocked at the SMTP level. Excellent. Now, let’s see how long the effects of this technique will last…

See http://projects.puremagic.com/greylisting/ to learn more about greylisting.

On our production mail server we’re using a so called qmail toaster setup. It’s essentially the same setup as described by shupp.org. However, instead of using SquirrelMail for webmail, we opted for SqWebMail and maildrop. The nice thing about SqWebMail is that it offers a web interface for configuring the maildrop mailfilters. That way, every user can configure their filtering rules individually.

The problem here is that vdelivermail (of vpopmail) doesn’t support those mailfilter files. For that to work we need vdelivermail to call maildrop to process those files on an individual basis. However, this requires to setup the processing instructions for every mail account manually. Of course, this is unbearable on a large setup.

We came up with a patch for vdelivermail that automatically chain-calls maildrop if it finds a mailfilter file in the domain’s account directory. Some parts are based on another patch which source I forgot. I mainly extended it to be less strict and to publish certain internal vpopmail/vdelivermail variables as environment variables that could be used inside the mailfilter – namely username, userdir, domainname, domaindir.

If it finds the file in the domain’s directory, it will delegate the mail to the domain-wide mailfilter.
The domain-wide mailfilter will delegate the mail to the users mailfilter if it exists. If not, it will simply do a standard mail delivery to the account’s INBOX.

If vdelivermail can’t find any domain-wide mailfilter it will simply default to standard mail delivery to the account’s INBOX.

Here is the patch against vpopmail 5.4.17:

vpopmail-5.4.17-vdelivermail.c-maildrop.patch

If you’re too lazy to patch the vpopmail sourcecode yourself, here is the already patched vdelivermail.c:

vdelivermail-5.4.17-maildrop.c

(Rename it to vdelivermail.c and place it in the vpopmail source directory and compile.)

› Continue reading