eBus (Vaillant Heizung)

Heizungssteuerung in die Home Automation einbinden

Jetzt ist es endlich so weit. Die Heizung muss in die Home Automation eingebunden werden.
Folgende Ausgangslage: Ein Vaillant Brennwertgerät ecoTecplus mit einer VR70 Steuerzentrale, einer VRC700 Zimmersteuerung und einem Außentemperaturfühler. Das alles ist über den eBus miteinander verbunden.
Kurz erklärt: Der eBus ist ein im Bereich der Heizungstechnik verwendetes Schnittstellenprotokoll, das auf der seriellen Schnittstellentechnik RS232 in Twisted-Pair-Technik mit zwei Drähten aufbaut. Es wurde von der Firma Dungs eingeführt. Verwendet werden dabei 2400 Baud und die jeweilige binären Signalpegel liegen bei: logisch 1: nominal 15 V (15–24 V); logisch 0: 9–12 V

Damit man also über den eBus mit der Heizung kommunizieren kann benötigt man etwas Hardware. Die gibt es fertig zu kaufen, oder man baut sich etwas selber. Ich habe mich für den Weg dazwischen entschieden und habe mir den beim FHEM Forum beschriebenen eBus Adapter besorgt. Der Bausatz kommt fertig bestückt, es sind nur bei Bedarf noch einige Stiftleisten einzulöten. Ja, und dann ist er Monate herumgelegen, weil keine Zeit, was anderes zu tun, blablabla… (Momentan gibt es die Platine gar nicht, denn es gibt die Chips derzeit nicht; Stand April 2022). Bei Interesse nachschauen bei Reinhart im Forum.

Der erste Schritt war also den Adapter mit der aktuellen Firmware zu beschreiben und ihm eine fixe IP-Adresse zuzuweisen. Alle Software, die man braucht findet man bei john30 auf github.

Ich habe mir den eBus Adapter mit dem Ethernet Aufsatz und einem Wemos WLAN Aufsatz gekauft, zum firmeware flashen, wollte ich ihn aber einfach über den USB Anschluss betreiben. Für die Verwendung mit den einzelnen Komponenten müssen entsprechende Jumper am Adapterboard gesetzt werden. Genau Beschreibung gibt es beim eBus Adapter3.

Für die Verwendung am USB Anschluss wurde alles vorbereitet und dann sollte man mit dem eBus PIC Loader die neueste firmware aufspielen können. Dafür muss man den USB Port angeben. Da ich die Software auf einem Raspberry Pi 4 installiert habe, musste ich also herausfinden, wie der USB Port lautet. Ich kann es gleich sagen, ich habe es bis heute nicht geschafft. Angeblich soll er /dev/ttyUSB0 oder ähnlich lauten, bei mir jedoch nicht und auch alle anderen Ports, die ich gefunden habe, haben nicht funktioniert. Vielleicht hat da jemand eine Idee und kann mir einen Kommentar hinterlassen.

Meine Lösung war dann den Adapter nicht über USB anzusprechen, sondern als HAT auf den Raspy zu montieren. Dafür musste noch eine Stiftleiste eingelötet werden und auch eine für den Jumper, damit man das board in den Boatloader Modus bringt.

# IP Adresse in einem /24 Netz setzen
ebuspicloader --ip=IP_Address --mask=24 /dev/ttyAMA0
# aktuelle firmware flashen
ebuspicloader -f 20220327-offset.hex /dev/ttyAMA0

Damit war einmal der Grundstein gelegt und das board konnte mit der gewünschten IP-Adresse angesprochen werden.

Als nächsten Schritt benötigt man einen daemon (system service) über den man mit dem Device Infos austauschen kann. Nachdem dieser daemon in der Produktionsumgebung auf dem Home Automation Debian Server in einem Docker Container laufen soll, wurde auch auf dem Raspberry das ganze in einem Docker Container laufen gelassen. Das hat auch nicht ganz so funktioniert, wie ich mir das vorgestellt habe. Witzigerweise läuft es auf dem Debian Server problemlos im Container. Na jedenfalls habe ich es am Raspy ohne Container aufgesetzt. Ach ja, die Adapterplatine wurde mit dem Ethernet Aufsatz versehen (die Jumper nicht vergessen richtig zu setzten) und mittels einer 2 Drahtleitung mit dem ebus am VR70 und mit einem Ethernet Kabel ins Heimnetz verbunden.

Da ich die Kommunikation mit der Heizung und OpenHAB über MQTT laufen lasse, ist es auch nötig beim Starten des daemons bzw. des Containers die entsprechenden MQTT setting mit anzugeben.

#docker-compose.yml
version: "2.1"
services:
  ebusd:
    container_name: ebusd
    image: john30/ebusd
    ports:
      - 8888:8888
    environment:
      - EBUSD_SCANCONFIG=
      - EBUSD_ENABLEDEFINE
      - EBUSD_ENABLEHEX
      - EBUSD_ACCESSLEVEL='*'
      - EBUSD_LATENCY=20000
      - EBUSD_DEVICE=enh:IP_Address:9999
      - EBUSD_MQTTHOST=IP_Address of MQTT Server
      - EBUSD_MQTTPORT=1883
      - EBUSD_MQTTJSON=      
    restart: always

Wenn der ebusd demon läuft, dann kann man mit dem ebusctl Programm gleich einmal schauen, ob man Daten bekommt.

# Info (Version, Master, Slave, etc.)
ebusctl i
# Nachrichten mit Parametern und Werten anzeigen
ebusctl find -d -v

Sieht man, dass Nachrichten ankommen, dann kann man diese auch über MQTT auslesen. Dafür stellt eBus einige topics zur Verfügung

# allgemeine Infos, wie Version, etc bekommt man mit
ebus/global/xxx
# Die Außentemperatur und Datum / Uhrzeit liefert
ebus/broadcast/xxx
# Spezifische Heizungswerte gibt es beim topic
ebus/bai/xxx

Die oben beschriebenen Infos werden regelmäßig upgedated, d.h. man kann sie z.B. im OpenHAB einfach einem item zuweisen und hat schon die aktuellen Werte. Man kann aber Werte auch gezielt abfragen. Wenn ich z.B. wissen möchte, welche Temperatur mein Warmwasser-Speicher hat, dann kann ich dies mit folgendem Statement erreichen.

# publish von folgendem topic
ebusd/bai/StorageTemp/get
# liefert dieses Ergebnis
{"temp": {"value": 59.69},
 "sensor": {"value": "ok"}}

Da ich die Nachrichten gerne im JSON Format haben möchte und so auch im OpenHAB weiterverarbeite, muss beim starten des ebusd daemon der Parameter –mqttjson mit angegeben werden (entspechend die Variable im docker-compose file).

Auf die Einbindung ins OpenHAB möchte ich hier gar nicht ins Detail eingehen, da es sich um ganz normale MQTT things inkl. channels handelt.

Die Schwierigkeit, die sich herausgestellt hat, ist das Herausfinden der richtigen Werte. Vereinfacht wird das durch das aktuelle ebusd Programm. Damit braucht man sich nicht mehr darum zu kümmern, welche dBus Protokoll Nachrichten was bedeuten, das übernimmt ein Übersetzungsfile. Was sich dann aber schlussendlich hinter den Variablen verbirgt, ist nicht ganz so einfach raus zu bekommen.

Hier einmal eine Liste einiger interessanter Werte:

aktuelles Datum: ebusd/broadcast/vdatetime JSONPATH:$.date.value
aktuelle Zeit: ebusd/broadcast/vdatetime JSONPATH:$.time.value
Außentemperatur: ebusd/broadcast/outsidetemp JSONPATH:$.temp2.value

Vorlauftemperatur: ebusd/bai/Status01 JSONPATH:$.0.value
Rücklauftemperatur: ebusd/bai/Status01 JSONPATH:$.0.value
Außentemperatur: ebusd/bai/Status01 JSONPATH:$.0.value
Speichertemperatur: ebusd/bai/Status01 JSONPATH:$.0.value
Pumpenstatus: ebusd/bai/Status01 

Betriebsart: ebusd/bai/Status02 JSONPATH:$.0.value
Maximaltemperatur: ebusd/bai/Status02 JSONPATH:$.1.value
ReglerCurrentTEMP: ebusd/bai/Status02 JSONPATH:$.2.value
Maximaltemperatur: ebusd/bai/Status02 JSONPATH:$.3.value
ReglerCurrentTemp: ebusd/bai/Status02 JSONPATH:$.4.value

Speicher Ist Temperatur: ebusd/bai/StorageTemp JSONPATH:$.temp.value
Speicher Ist Temp. Sensor Zustand:  ebusd/bai/StorageTemp JSONPATH:$.sensor.value
Speicher Soll Temperatur: ebusd/bai/StorageTempDesired JSONPATH:$.temp.value

Vorlauftemperatur: ebusd/bai/FlowTemp JSONPATH:$.temp.value
Rücklauftemperatur: ebusd/bai/ReturnTemp JSONPATH:$.temp.value
Wasserdruck: ebusd/bai/WaterPressure JSONPATH:$.press.value

hcmode: ebusd/bai/SetMode JSONPATH:$.hcmode.value
flowtempdesired: ebusd/bai/SetMode JSONPATH:$.flowtempdesired.value

Problem 1: Es gibt 2 Geräte, die am eBus hängen. Das ist die Therme mit der VR70 Steuerung und ein Zimmersteuergerät VRC700. Der VR70 wird sofort erkannt und die richtige csv-Datei geladen. Den VRC700 bekomme ich nicht ins System. Wenn ich ihn händisch scanne, dann bekomme ich gar nichts, wenn ich einfach warte, dann erscheint er irgendwann mal an der Adresse 15, aber es wird keine Datei geladen.

root@3880c5fd5c6c:/# ebusctl i
version: ebusd 22.2.p20220227
update check: version 22.3 available
device: W:X.Y:Z:9999, enhanced
access: '*'
signal: acquired
symbol rate: 23
max symbol rate: 116
min arbitration micros: 1
max arbitration micros: 11
min symbol latency: 32
max symbol latency: 45
reconnects: 0
masters: 3
messages: 226
conditional: 3
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0608;HW=5502", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 52: slave

Ich habe in der Zwischenzeit, den Adapter sehr nahe am VR70 angeschlossen, weil ich dachte, es hat etwas mit der Distanz zu tun, aber Fehlanzeige. Momentan bin ich echt mit meinem Latein am Ende. Vielleicht kommt ja ein Tipp von außen.

Problem 2: Nach einigen Tagen schwirrt der MQTT Teil am Adapter ab und schickt keine Daten mehr, da hilft dann nur mehr ein Neustart, auch keine Ahnung warum.