Logamatic 4000 Serie

Buderus Heizungsregler
der Serie Logamatic 4000

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 ist jetzt zwar ca. 10 Jahre alt, aber wie in dieser Branche offenbar üblich, hinkt die Ausführung dem Stand der Technik wesentlich weiter hinterher.

Fernbedienung (Raumthermostat) BFU   Fernbedienung (Raumthermostat) MEC2

Fernbedienungen
BFU (links), MEC2 (rechts)

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.

Protokoll 1

Serielles Protokoll (1). Man erkennt den Ruhepegel von 10 V und den Arbeitspegel von 16 V.

Protokoll 2

Serielles Protokoll (2). Antworten der Bediengeräte unter der 10 V-Basislinie.

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

Raspberry Pi mit Pegelwandler

Raspberry Pi mit aufgesetztem
Pegelwandler, noch ohne Gehäuse

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 RPI 2 ist zwar von der Leistungsfähigkeit her eindeutig überqualifiziert, war aber zur Hand. (Aktuell wäre der neue Raspberry Pi Zero W eine charmante Lösung.)

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?)

Protokoll 3

Serielles Protokoll (3). Ein typisches Paket im Detail.
Die Daten werden mit 1200-8N1 übertragen.

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

EMONCMS Beispiel-Dashboard

Ein Beispiel-Dashboard aus EmonCMS. In den unteren beiden Graphen sind jeweils Soll- und Ist-Temperatur sowie die Aktivität der Wärmequelle (Ladepumpe bzw. Brenner) zusammen dargestellt.

Das Programm schreibt die erfaßten Daten lokal nach /var/log/buderus, und schickt sie parallel an die Website emoncms.org. Dort bekommt man bei der kostenlosen Registrierung einen Schlüssel, den man im Programm einträgt. Weiters sollten Mailadressen und SMTP-Server konfiguriert werden, damit das Programm Fehlermeldungen schicken kann, z.B. bei Brennerstörungen.

Einer der Vorteile von EmonCMS ist, daß die Software auch zur Installation auf eigenen Webservern verfügbar ist. Man kann also einfach und gratis mit einem Account auf emoncms.org beginnen und später die Daten auf dem eigenen Server speichern. Es gibt auch eine EmonCMS-Distribution für den Raspi selber, (die ich jedoch noch nicht getestet habe), oder man installiert EmonCMS im Standard-Raspbian.

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.

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


Monitor-Hardware v2 außen

Zweite Version der Monitor-Hardware, im Hutschienengehäuse mit galvanisch getrenntem Pegelwandler und zwei Relaisausgängen

In einer zweiten Version wurde der Raspberry Pi in eine «RasPiBox Open+» von Hartmut Wendt eingebaut, in der auch der galvanisch getrennte Pegelwandler sowie zwei Relais für weitere Steueraufgaben Platz finden.

In der Installation des Autors wird mit demselben Raspberry Pi mittlerweile noch ein Solarthermie-Regler von RESOL mit überwacht. Dazu ist ein Resol-Bus-Interface via USB angeschlossen.

Und auch der neue Regler für einen Kühlraum liefert Daten an EMONCMS.

Monitor-Hardware v2 innen

Innenaufbau der Monitor-Hardware v2