Heizungs-Monitoring an einer Buderus Logamatic 2107

Hier im Haus arbeitet eine schon etwas ältere Öl-Zentralheizung von Buderus mit einer Steuerung „Logamatic 2107“. Als vor einiger Zeit – natürlich in der kalten Jahreszeit – eine Brennerstörung auftrat und wir das erst bemerkten, als die Wohnräume schon deutlich abgekühlt waren, wuchs in mir der Wunsch, die Heizung zu überwachen und im Fall von Störungen per E-Mail oder dergleichen benachrichtigt zu werden. Auf diese Weise kann man bei einer erneuten Störung hoffentlich schneller reagieren (und sei es nur, zügig einen Heizungsbauer anzurufen), um zu verhindern, dass das Haus allzu stark auskühlt, bis die Heizung wieder funktioniert.

Eine Google-Recherche zeigte relativ schnell, dass sich in der Logamatic 2107 ein „Kommunikationsmodul KM271“ nachrüsten lässt, das eine serielle Schnittstelle bereitstellt. Außerdem fand ich einen Blog, in dem der Autor darüber berichtet, dass er erfolgreich eine Datenverbindung mit der Logamatic 2107 bzw. dem KM271 hergestellt hat. Allerdings war die Beschreibung im Blog eher als eine Art Einstieg ins Thema zu sehen und noch weit entfernt von einer fertigen Lösung, erst recht einer, die mir gefallen hätte. Also war Eigenarbeit angesagt.

Hardware

Die Hardware war für mich der eher einfache Teil. Da ich bei anderen Projekten schon prinzipiell gute Erfahrungen mit Raspberry Pis gesammelt hatte, sollte es auf jeden Fall ein Raspberry Pi werden, konkret geworden ist es ein Modell 3B+. Für die Heizung habe ich mir ein originales KM271-Modul besorgt und problemlos eingebaut. Dem Raspberry Pi habe ich mittels eine RS232-Moduls von Renkforce um eine serielle Schnittstelle erweitert und beides mit einem seriellen 1:1-Verlängerungskabels verbunden. Damit das Ganze ein etwas professionelleres Aussehen bekommt, habe ich den Raspberry Pi in ein Hutschienengehäuse eingebaut und das zusammen mit einem kleinen Hutschienennetzteil in ein Aufputzgehäuse montiert.

Um die Sache kompakt zu halten und keine zusätzliche, potentiell fehlerträchtige Schnittstelle zu haben, benutze ich als Datenträger kein USB-Speichermedium, sondern „klassisch“ eine Micro-SD-Karte – dazu weiter unten noch mehr. Da ich keine Lust hatte, ein LAN-Kabel in den Heizungskeller zu verlegen, hängt der Raspberry Pi im WLAN.

Software

Auslesen der Heizung

Wie schon geschrieben, enthielt der weiter oben verlinkte Blog eher Einstiegsinformationen für die Software. Immerhin war dort dokumentiert, dass die Heizung das 3964R-Protokoll zur Kommunikation verwendet. Ebenfalls dort zu finden war ein „Treiber“ für dieses Protokoll, allerdings in der für mich bis dato unbekannten Programmiersprache Python geschrieben. Damit stand ich vor der Wahl, mir entweder zumindest rudimentäre Python-Kenntnisse anzueignen oder den Code zu verstehen und in einer mir besser bekannten Programmiersprache nachzuprogrammieren. Entschieden habe ich mich dann für die Verwendung in Python, zumindest soweit es sich nicht vermeiden ließ.

Die Art der Datenübertragung, die die Logamatic 2107 verwendet, ist von sich aus leider nur bedingt für die Art von Monitoring geeignet, die mir vorschwebte: Die Heizung sendet in regelmäßigen Abständen von ca. 3 Sekunden ein Datentelegramm, das den letzten Parameterwert, der sich in der Heizung geändert hat, enthält. (Oder, wenn sich nichts geändert hat, einen Platzhalterwert.) Obendrein ist das Format der Datentelegramme offiziell von Buderus gar nicht dokumentiert und bis dato im Internet auch nur bruchstückhaft. Also war zunächst Reverse Engineering, unter anderem mit Hilfe der offiziellen Buderus-Dokumentation des Datenprotokolls an der „verwandten“ Logamatic 4000. Die „Entschlüsselung“ der Datentelegramme, soweit ich das tun konnte und wollte, habe ich einem Github-Repository dokumentiert.

Da ich zur Darstellung in einem grafischen Frontend alle aktuellen Parameterwerte „auf einmal“ haben wollte, musste ich die „zufällig“ eintreffenden Datentelegramme bzw. die darin enthaltenen Werte zunächst einmal zwischenspeichern. Da ich für die weitere Verarbeitung der Daten ohnehin auf das mir wesentlich besser vertraute Duo aus PHP und MySQL (bzw. MariaDB) zurückgreifen wollte, lasse ich das Python-Skript, das die Werte von der Heizung entgegen nimmt, die Werte in einer MySQL-Datentabelle, die nur eine einzige Zeile enthält, eintragen bzw. aktualisieren. Da ich mit dem Betrieb von Datenbanken, selbst mit sehr geringer Last, auf Raspberry Pis mit SD-Karten dahingehend schlechte Erfahrungen gemacht habe, dass die SD-Karten bereits nach ein bis zwei Jahren kaputt gehen, ist diese Datentabelle für den Status mit der MEMORY Storage-Engine, die ausschließlich im RAM bleibt, definiert.

Nachdem das Python-Skript, das die Daten von der Heizung entgegen nimmt und in die Statustabelle schreibt, fertig war, muss daraus noch ein Daemon werden, der idealerweise auch gleich beim Booten des Raspberry Pis (z.B. nach einem Stromausfall) automatisch startet. Auch wenn ich sonst überhaupt kein Fan von systemd bin, das mittlerweile auch bei Raspberry Pi OS zum Einsatz kommt, muss ich fairerweise zugeben, dass das „Daemonisieren“ einer Software mit systemd erfreulich einfach geht: mit Hilfe dieser Anleitung war das eine Sache von wenigen Minuten.

Da ich zusätzlich auch noch eine Langzeitarchivierung der Statusdaten für mögliche statistische Auswertungen haben wollte, lasse ich mir zusätzlich mittels eines Cronjobs – diesen allerdings bereits in PHP geschrieben – auf dem Raspberry Pi die jeweils aktuellen Statusdaten im Takt von einer Minute in eine „Archiv-Tabelle“ übertragen. Wegen der bereits erwähnten Schreiblast, mit denen SD-Karten nicht gut klarkommen, liegt diese Datenbank-Tabelle allerdings nicht auf dem Raspberry Pi, sondern auf meinem Heimserver. Ebenfalls auf dem Server liegt schließlich noch eine dritte Datenbank-Tabelle, in die ich mir alle Datentelegramme, die ich bislang noch nicht entschlüsselt habe, in „Rohform“ eintragen lasse, damit ich diese eventuell später doch noch entschlüsseln kann. Das PHP-Skript, das im Minutentakt die aktuellen Statusdaten in die „Archiv-Tabelle“ überträgt, ist darüber hinaus auch dafür zuständig, in einigen besonderen Fällen Info- und Warn-E-Mails zu verschicken – also den Zweck zu erfüllen, der überhaupt die Eingangsmotivation für dieses Projekt lieferte.

Auch den Code bis hierhin, soweit ich ihn selbst geschrieben und nicht aus dem eingangs verlinkten Blog übernommen habe, habe ich in einem Github-Repository veröffentlicht.

Web-Frontend

Um die Überwachung der Heizung noch etwas „familienfreundlicher“ zu gestalten, habe ich zusätzlich noch ein Web-Frontend programmiert, dieses dann allerdings wieder in PHP. Sozusagen als Einstieg dient dabei eine Visualisierung der Heizungsanlage mit einigen Eckdaten, insbesondere diversen Temperaturwerten.

Unten drunter, auf dem Screenshot nicht sichtbar, folgen noch weitere Daten in Form kleiner Tabellen wie z.B. noch einmal die Temperaturwerte aus der Grafik, die bislang aufgelaufenen Betriebsstunden des Brenners und so weiter. Außerdem lassen sich Graphen anzeigen, die den Verlauf diverse Parameter über die Zeit für die letzten 24 Stunden bzw. 30 Tage darstellen.

Update 2021-04-06: Link zum zweiten Github-Repository korrigiert, Typo korrigiert.