Online-Monitor für Regler der Buderus Logamatic 4000 Serie

Schon lange wollte ich die Heizungsanlage in meinem Haus zeitgemäß überwachen. Der Heizkessel ist ein bodenstehender Gaskessel, er wird von einer Buderus Logamatic aus der 4000er Serie geregelt. Von den vier möglichen Kreisen verwende ich drei — 1. Stock, Erdgeschoß und Fußboden im Bad.

Die Anlage wurde Anfang der 2000er installiert, aber wie in dieser Branche offenbar üblich, hinkt die Ausführung dem Stand der Technik wesentlich weiter hinterher.

Die Regelungen dieser Generation kann man zwar über einen proprietären «ECO-CAN Bus» steuern und überwachen, aber nicht etwa einfach mit einem (billigen) kleinen externen Interface einmal schnell ins Netz hängen. Der Hersteller bietet (um etliche 100€) ein serielles Interface an, sowie PC-Programme usw. — aber die neuere Web- bzw. App-basierte Lösung mit dem KM200 Gateway kommuniziert laut Buderus-Datenblatt nur mit neueren Reglern «mit EMS-BUS-Schnittstelle ab Fertigungsdatum 2003». Gut, dass ich meine Anlage noch 2003 gekauft habe, grrr ...

Allerdings sind die Raumthermostate bei der Logamatic 4000 «intelligent», d.h. sie kommunizieren über einen Zweidrahtbus mit dem Regler. (Der Heizkreis wird mit einem Kodier-Schalter im Raumthermostaten ausgewählt.)

Es stellt sich heraus, daß die Raumthermostate (Type «BFU») aller Heizkreise und die Fernbedieneinheit mit Display (Type «MEC2») trotz separater Anschlußklemmen im Reglergehäuse offenbar an einem gemeinsamen Bus hängen, und über diesen auch mit Strom versorgt werden.

Die Schnittstelle zwischen Regler und Raumthermostaten ist relativ einfach: Es ist ein gegenüber üblichen Konventionen invertiertes serielles Asynchron-Protokoll mit Ruhepegel von 10 V und Arbeitspegel von 16 V. Durch die immer anliegende Spannung werden die Raumthermostate fernversorgt.

Die Rückmeldungen von den Thermostaten zum Regler werden offenbar als Stromimpulse gesendet, d.h. die 10 V-Versorgung wird stärker belastet, wenn der Thermostat den Arbeitspegel anlegt. Man erkennt dieses Signal als Spannungen kleiner als 10 V am Bus. Durch Beobachten der Spannung läßt es sich aber nicht leicht auswerten, weil der Spannungshub zu klein ist.

Das serielle Datenformat ist simpel: 1200 bit/s, 8 bit, 1 Stopbit, kein Paritätsbit. Es werden immer Datenblöcke von einigen Bytes übertragen, dazwischen sind Rückmeldungen der Raumthermostate zu sehen — manchmal nur kurze (offenbar einfach ein «ACK»), manchmal mehr-bytige Frames mit Informationen wie Raumtemperatur, Tag/Auto/Nacht, und Uhrzeit (BFU-F und MEC2 haben einen eingebauten DCF-77 Zeitzeichenempfänger).

Zum Mitschreiben und Auswerten der seriellen Übertragung reicht ein simpler invertierender Pegelwandler mit 12 V Z-Diode und Transistor. Noch beser ist natürlich ein galvanisch getrennter Pegelwandler.

Weil er leicht verfügbar und billig ist und alle Optionen für Netzwerkanschluß bietet, habe ich einen Raspberry Pi als Interface verwendet. Der ist zwar von der Leistungsfähigkeit her eindeutig überqualifiziert, war aber zur Hand. Seither ist auch der Raspberry Pi Zero W erschienen, der eine charmante kleine Lösung (eventuell sogar im Loagamatic-Gehäuse) erlaubt.

Entscheidende Vorteile dieser Lösung sind die galvanische Trennung zwischen Regler und Netzwerk, die Möglichkeit, nach Bedarf entweder kabelgebundenes Ethernet oder WiFi einzusetzen, und die einfache Programmierung — in meinem Fall in einer meiner Lieblingssprachen, dem «Pathologically Eclectic Rubbish Lister».

Perl ist durchaus für relativ systemnahe Anwendungen wie Interaktion mit seriellen Schnittstellen geeignet, und bietet eine Riesenvielfalt an Bibliotheken für alle erdenklichen Zwecke an.

Zuerst einmal muß allerdings die Struktur der Datenblöcke entschlüsselt werden. Ein typischer Datenblock, wie hier gezeigt, enthält die 11 Bytes

80 00 04 02 2A 28 2C 2C 53 AF 82

(hex). Wenn man eine Sequenz solcher Blöcke beobachtet, sieht man mehrere solcher Telegramme mit dem ersten Byte 80h, dann folgen andere Werte. Das zweite Byte steigt jeweils von 00 in Sechserschritten an, also 00, 06, 0C, 12, usw.

Mit einem bißchen Erfahrung erkennt man leicht, daß im weiteren sechs Datenbytes, ein Prüfsummen-Byte und eine fixe Sequenz (AF 82) folgen (letztere evtl. eine Aufforderung an die Raumfühler, zu senden?)

Offenbar werden also Parameter-Telegramme mit einer Telegrammnummer (80h im Beispiel) und einer Anzahl von Datenbytes in Gruppen von jeweils sechs übertragen, wobei das 2. Byte also den Offset im Telegramm angibt.

Man könnte jetzt natürlich weiter an der Bedeutung der einzelnen Bytes herumraten, indem man die vom MEC2 im Monitormodus angezeigten Werte in den Telegrammen wiederzufinden versucht. Buderus dokumentiert diese Schnittstelle natürlich nicht, aber zum Glück sind Programmierer ja grundsätzlich faul. In der Dokumentation des erwähnten seriellen Interfaces (Dokument «Technische Information Monitordaten System 4000») findet man nämlich sofort die fraglichen Telegrammnummern, und erkennt auch denselben Aufbau mit 6er-Blöcken wieder — dieses Interface setzt offenbar die Dateninhalte gar nicht um! (Was ist dann so teuer daran ...?)

Der oben gezeigte Block sind beispielsweise die ersten 6 Byte der Monitorwerte für den ersten Heizkreis (80h). In den ersten beiden Datenbytes (04 02) finden sich Status- bzw. Fehlerbits, dann kommt die Vorlauf-Solltemperatur (2Ah = 42°C), Vorlauf-Isttemperatur (28h = 38°C), usw.

Der aktuelle Stand meines Perl-Programmes kann hier heruntergeladen werden. (Das Programm ist mit einigen Konfigurationen direkt lauffähig, wenn die benötigten Perl-Bibliotheken installiert sind. Ich gebe hier aber bewußt kein «Kochrezept» an, sondern einen Anstoß für eigene Ideen.)

Das Programm schreibt die erfaßten Daten lokal nach /var/log/buderus, und kann sie parallel auch an einen MQTT-Broker und/oder eine EmonCMS-Instanz schicken. Zusätzlich können Fehlermeldungen, z.B. bei einer Brennerstörung, per email verschickt werden. Die jeweiligen Zugangsdaten und Mailadressen müssen zuerst am Anfang des Programms eingetragen werden.

Einer der Vorteile von EmonCMS ist, daß die Software als Service auf emoncms.org, aber auch zur Installation auf eigenen Webservern oder einem Raspberry Pi verfügbar ist. Zum Experimentieren kann man z.B. einfach mit einem Account auf emoncms.org beginnen. Ursprünglich war dieses Service gratis verfügbar, mittlerweile verlangen die Betreiber eine moderate Gebühr.

EmonCMS speichert die Meßdaten und kann sie sehr hübsch grafisch darstellen. Der logische Ablauf in EmonCMS ist, kurz gefaßt, Input → Feed → Graph → Dashboard. Die «inputs» erzeugt EmonCMS aufgrund der geposteten JSON-Daten automatisch. Für Parameter, die man weiterverarbeiten will, muß man je einen feed anlegen, der bestimmt, was und wann gespeichert wird, wobei für die meisten Parameter hier realtime/phptimeseries angebracht ist.

Feeds kann man dann in «graphs» auswerten — besonders leistungsfähig sind multigraphs — und solche Graphen lassen sich zu «dashboards» wie dem gezeigten verbinden. In den Graphen kann man dann interaktiv navigieren.

Aus Open-Source-Komponenten kann man mit etwas mahr Handarbeit natürlich auch andere Lösungen zusammenstellen, beispielsweise Mosquitto als MQTT Broker, InfluxDB zum Speichern der Daten, und Grafana zur Visualisierung.

Feedback und Erfahrungsaustausch zu diesem Projekt ist willkommen (→ projekte@holzleitner.com) — Support kann ich aber leider nicht anbieten.

---