Der EBus der Heizung hängt am Netz!

Lange geplant, recherchiert und dann endlich was gefunden: Dank des EBus-Koppler Ethernet🖹, einem bereits beim Bau verlegten Telefonkabels vom Stromkasten zum Patchfeld und eines alten Telefonkabels (TAE auf RJ11) ist jetzt die Vaillant Wärmepumpe am Netz.

Aber ich hole besser etwas weiter aus um die vielen Probleme anzusprechen und deren Umschiffung zu erleichtern.

Über den EBus der Vaillant Heizung lässt sich deren Status und etliche andere Parameter abfragen. Dazu muss aber dieser EBus erstmal ans Netz - weil dann alles einfach wird. Dazu dient zum einen der EBus-Koppler. Den gibt es in der Variante USB und Ethernet. Ich habe mich für Ethernet entschiedenen, da so kein Treiber für den USB-Anschluss benötigt wird und auch kein Gerät her muss, das einen USB-Anschluss mit passendem Treiber und Betriebssystem samt nötiger Version benötigt.

Der Koppler ist auf der einen Seite per EBus an die Heizung angeschlossen und auf der anderen eben ans lokale Netz. Die EBus-Verkabelung ist im Prinzip einfach, erweisst sich im Detail aber aufwändig:

Es reicht eine 2-Draht-Leitung. Schön ist es natürlich, wenn diese Leitung auch irgendwie in die Heizung gelangt. Dazu bietet sich die Kabeleinführung an, über die auch schon die Elektrik ins Gerät kommt. Natürlich ist diese schon recht voll gewesen, wodurch die Einfädelung eines weiteren Kabels zur Fummelei wurde. Vorgesehn war dazu ein nicht mehrbenötigtes Telfonkabel, eine Seite TAE, die andere RJ11. Denn laut Schaltbild gibt es auf der Hauptplatine der Heizung eine RJ-Buchse. Der TAE-Stecker konnte weg.

Nachdem endlich das Kabel in der Kabeleinführung lag, stellte sich jedoch heraus, dass die Vaillant-Leute da keie RJ11-Buchse verbaut haben. Also abgeschnitten und die Leitung direkt an die EBus-Pins der Platine geschraubt.

Damit erschien der komplizierte Teil vorbei. Der EBus-Koppler konnte leicht per Tool ins Netz eingebunden werden. Ein Programm namens "ebusd" sollte den leichten Zugriff auf den Koppler unter Linux erlauben. Leider fingen da aber erst die richtigen Probleme an!

Nach 24 Stunden waren etliche Fehler im Konzept gefunden und behoben und alles lief endlich. Um zukünftigen Nutzern diese Probleme zu ersparent, hier nun meine Erfahrungen und Lösungen:

In der Beschreibung des Kopplers stehen die Optionen, die man ändern soll gegenüber dem Auslieferungszustand. Leider sind da nicht alle Punkte hervor gehoben bzw. es gibt jetzt Werte mit anderen Voreinstellungen als zum Zeitpunkt der Doku-Erstellung. Deshalb sollte man alle Werte - vor allem die, die einem nichts sagen - exakt so einstellen, wie sich in den Screenshots in der Doku ausgedruckt sind. Es gab da einen Parameter Character-Mode, der auf den Bildern auf 00 steht, bei meinem Gerät auf 0C stand. 24 Stunden unnötige Arbeit.

Immerhin haben diese zu etlichen gefundenen Fehlern im ebusd geführt. Damit zu den nächsten Erfahrungen. Der ebusd wurde in Version 0.1 in C geschrieben und mit 0.2 in C++ komplett neu. Leider sind beide Versionen nicht wirklich fehlerfrei. Schlimmer noch, in der C++-Fassung fehlen Optionen, die bei der Inbetriebnahme nützlich sind: Dump des EBus zum Kalibrierung.

Wirklich emfehlen kann ich den ebusd jedoch keinem, der sich nicht in C und C++ auskennt: Die Version 0.3 habe ich inzwischen durch die 0.1 ersetzt. Nicht nur, dass ältere C++-Compiler mit dem Code nicht klar kommen, er hat auch üble Fehler, die nur durch Zufall mit manchen Compilern funktionieren. Unter anderem, wer Ahnung hat, wird ein String-Pointer in ein Hash als Key gepackt. In einem anderen Modul wird nun nach dem gleichen String gesucht, jedoch ist das ein anderer Pointer. Einzig mit starker Optimierung wird der Compiler diese Strings auf den gleichen Pointer legen.

Ansonsten ist der C++-Code sicherlich übersichtlicher, da er mit aufgeräumten Klassen arbeitet. Er ist aber noch nicht für den Produktivbetrieb geeignet.

Blieb die Version 0.1 mit purem C. Der lief dann in der Tat recht gut und ohne Compiler-Probleme. Auf das automake-Zeugs hätte man sicherlich verzichten können und genau das habe ich auch getan, denn ältere Systeme haben ein älteres automake installiert und das steigt dann mit einem Fehler aus. Grundlos, denn der Programm selbst lässt sich problemlos compilieren und läuft.

Leider läuft aber auch die 0.1er C-Version nicht stabil: nach zwei Tagen im Dauerbetrieb lieferte der ebusd plötzlich nichts mehr. Ok, das kann viele Ursachen haben und wa ja auch der erste Einsatz der ganzen Infrastruktur, dazu gleich mehr. Anfangs war auch nicht klar, ob es eben der ebusd selbst oder das Zeugs drumrum ist. Ein Neustart aller Komponenten half und lief wieder alles. Für ca. 1 Tag. Dann hing wieder alles. Diesesmal konnte ich per Tests und Debugging den ebusd als Ursache feststellen. Leider aber konnte ich den Fehler nur vermuten. Nach einem Neustart lief er wieder. Für ca. 1 Tag. Nun stand auch der Fehler fest und konnte behoben werden. Seit dem läuft er durch.

Zur genannten Infrastruktur.

Wie schon beschrieben läuft ein All3500 zur Steuerung und Überwachung. Dessen Werte landen zudem in einem Lrrd (inzwischen Munin genannt) und so gibt es schöne Graphen der Temperaturen usw. und eben dort sollte auch die Heizung erfasst werden.

Der 3500 kann XML-Geräte abfragen. Nun liefert der ebusd kein XML per HTTP. Genaugenommen liefert er auch kein HTTP. Im ersten Ansatz wollte ich da irgendwas simples als Adaper zwischen setzen und ggf. später den Teil in den ebusd-C++-Code einbauen. Der C++-Code ist aber eben nicht im Einsatz.

Drum läuft ein simples Java-Programm als Adapter: Es erfragt zyklich Werte vom ebusd und liefert diese komplett als XML-Datei per HTTP-Anfrage. D.h. das Programm ist einerseits ein Web-Server und am anderen Ende sammelt es Daten vom ebusd in einem Kreislauf. Als diese Datensammlung das 1. mal ab brach, hatte ich deshalb auch diesen Kreislauf im Java-Programm im Verdacht. War es aber nicht.

Nun fragt der 3500 diesen Web-Server ab und speichert die Werte aus der XML-Datei.

Und ab dort können sich nun alle Systeme im Haus an den Daten bedienen:

  • Lrrd/Munin für die Graphen
  • die PDAs zur Darstellung der Messwerte im Haus

Alles in allem eine super Sache, aber leider auch etliche Probleme und Fehler, die man ohne umfassendes Wissen auf der Software-Seite nicht so leicht lösen konnte. Dachte ich erst, der Anschluss an die Heizung wäre das große Problem und dabei könne viel schief gehen - bis hin zu einem Schaden dort - war es am Ende leider die Software. Nicht falsch verstehen, ich bin froh, dass es diese bereits gab. Jedoch ist deren Nutzbarkeit für Anfänger sehr gering und hat zu viele zu hohe Hürden.

In einem nächsten Schritt überlege ich, den XML-Web-Server in den ebusd zu integrieren. Das wäre im C++-Code sicherlich leichter aber der C-Code läuft einfach auf mehr Systemen, auch auf älteren Versionen.