Läuft: Heizung mit eBus-Schnittstelle

[Prof. Dr. Peter Henning]

Einen Schritt weiter bin ich.

Das Problem liegt wirklich in den Konfigurationsdateien auf dem Server. Da gibt es die wildesten Include-Befehle, und es ist nicht so ganz transparent, was eigentlich wo dazu geladen wird - und offenbar kommen darin Fehler vor (siehe Post von m8haben weiter unten), ferner ist in den Konfigurationsdateien mancher Unsinn vorhanden (z.B. eine Bezeichnung "Betriebsart_2" zwischen dem ganzen englischen Kram)

Der Weg da heraus ist nicht ganz trivial.

1. Auf dem Rechner, auf welchem der ebusd läuft, zunächst einen Clone der ganzen Konfigurationsdateien anlegen. Der Bequemlichkeit halber nehme ich an, dass man sich gerade im Verzeichnis befindet:

git clone https://github.com/john30/ebusd-configuration

2. Der ebusd muss nun so gestartet werden, dass er seine Konfigurationsdaten aus eben diesem Verzeichnis holt. Dazu beim Start des ebusd den Parameter

--config-path=/home/pi/ebusd-configuration/ebusd-2.1.x/de

3. Jetzt kann man sich in der Datei /var/log/ebusd.log ansehen, welche Konfigurationsdateien auf der obersten Ebene geladen werden - z.B.

2025-02-21 12:16:18.965 [main notice] read scan config file vaillant/08.bai.csv for ID "bai00", SW0730, HW7401

4. In dieser Datei kann man nun nachsehen, welche zusätzlichen Dateien mit der Endung .inc noch dazugeladen werden. Offenbar ist die Logik, nach welcher die  betreffenden Entscheidungen getroffen werden, leicht fehlerhaft - so wie von m8haben weiter unten bemerkt. Das kann man jetzt aber kontrollieren, indem man die betreffenden Dateien auf einem anderen Rechner mit LibreOffice oder Excel öffnet (als CSV-Datei, Spaltenseparator muss auch ein Komma sein !) und editiert. Include-Befehle, die falsche Dateien hinzuladen, können mit einem '#' in der ersten Stelle auskommentiert werden. Und statt eine Datei zu inkludieren, kann man sie auch in die gerade editierte Datei hineinkopieren. Dann wird das Ergebnis wieder zurück auf den Rechner mit dem ebusd geschoben, natürlich an die richtige Stelle.

5. Das ist natürlich nur ein temporärer Ausweg, der aber dazu dienen kann, wenigstens alle gewünschten Befehle und Register zu finden. Mittelfristig sollten die notwendigen Korrekturen an das ebusd-Team übermittelt werden. Und langfristig sollte man das ganze Verfahren für die Konfigurationsdateien vereinfachen.

Ich hänge, spaßeshalber, mal eine 10 Jahre LibreOffice-Datei an, die einigermaßen lesbar ist. Sie enthält auf den hinteren Blättern Auszüge aus der Vaillant-Protokollbeschreibung. Und auf den vorderen Blättern Makro-Buttons, mit denen man direkt die gewünschte CSV-Datei erzeugen kann.

LG

pah

[Wolpertinger]

Hallo,
ich habe heute wieder beide meiner V3 USB Adapter inbetrieb genommen.

Es sind zwei Services angelegt mit unterschiedlichen PID Files.
ebusd0.pid und ebusd1.pid

ebusd wird als root ausgeführt.

im service File steht:

Code Auswählen Erweitern

PIDFile=/run/ebusd0.pid

Fehlermeldung:

Code Auswählen Erweitern

ebusd-air.service: Can't open PID file /run/ebusd0.pid (yet?) after start: Operation not permitted
Ich habe auch getrennte Log Files
Ein Service ignoriert das mit dem PID File und nimmt das als Standard ebusd.pid
Der Andere Service startet dann nicht:

Code Auswählen Erweitern

2025-02-26 19:33:13.052 [main notice] ebusd stopped
2025-02-26 19:33:43.298 [main error] can't open pidfile: /var/run/ebusd.pid, exiting
Und nu?
Wo klemmt es denn?

[Wolpertinger]

Für mich ist es ein BUG!

Vorweg es läuft nun alles einwandfrei.

Im *.service gibt es:
PIDFile=/var/run/ebusd.pid
Nun geht man davon aus, dass das genau die Stelle ist, in der man den Namen des PIDFile ändern muss wenn man mehrere Adapter nutzen möchte.
Natürlich brauchen die PIDFiles unterschiedliche Name.

Falsch gedacht!
Denn diese Zeile wird komplett ignoriert.
Warum ist das so?
Wäre es nicht sinnvoll, dass die Anweisung genau das macht was sie machen soll?

So funktioniert es nun:
Man fügt --pidfile=/var/run/ebusdXYZ.pid hinzu und schon klappt es mit den PIDFiles.

[Prof. Dr. Peter Henning]

Bevor man hier "BUG" in Großbuchstaben schreibt, sollte man erst mal die eigenen Eingaben prüfen.

PIDFile=/run/ebusd0.pid

ist nämlich nicht richtig, und die Fehlermeldung weist auch ganz klar darauf hin. Mit

PIDFile=/var/run/ebusd0.pid

sollte es gehen.

LG

pah

[Prof. Dr. Peter Henning]

So, ich bin mit den Konfigurationsdateien noch einen Schritt weiter - und schüttele über den Wust aus .csv- und .inc-Dateien etwas den Kopf.

Das fängt mit kleineren Inkonsistenzen an, z.B. heißt es einmal in den Dateien "HydraulicMap", ein andermal "HydraulicScheme" - gemeint ist dasselbe. Und geht bis zu diversen Fehlern bei der Abfrage aller Werte, die in die Meldung "invalid position in decode" führen. Meine Vermutung ist, dass hier die Abfragedefinitionen unvollständig sind.

Als Nächstes ist mir aufgefallen, dass viele Abfragen, die mit den 10 Jahre alten Dateien problemlos funktioniert haben, nicht mehr gehen. Insbesondere kombinierte Meldungen, die gleich mehrere Status abfragen, sind in den neuen Konfigurationsdateien nicht mehr vorhanden.

Es fehlen aber auch wichtige Einzelwerte, dazu mal ein Beispiel. In meinem Vaillant-Steuergerät VRS620 gibt es ein Register, das den gesamten solarthermischen Ertrag enthält. Das war in meiner alten EBUS-Installation abfragbar mit

ebusctl read -c vrs620 SolarYield

In der neuen Konfigurationsdatei vaillant/15.ui.csv gibt es ein solches Feld aber nicht mehr.

Die Konfigurationsdateien habe ich (wie unten beschrieben) auf meinen EBUS-Rechner geklont, und den fehlenden Eintrag von Hand eingefügt. Das ist gar nicht schwer, das Format ist Klartextlesbar. Die notwendige Zeile lautet

r,,SolarYield,Solarer Ertrag,,,,"0600",,,energy4,,kWh,Solarer Gesamtertrag

Darin bedeuten, jeweils durch Komma getrennt:

1. Feld: Zugriffsart (r[1-9];w;u), nur lesen => r
2. Feld: Präfix, kann leer bleiben, wenn der oben in der Datei definierte Präfix verwendet werden soll, in diesem Falle => ui
3. Feld: Name des EBUS-Readings => SolarYield
4. Feld: Kommentar, kann leer bleiben => Solarer Ertrag
5. Feld: QQ=Source address, kann leer bleiben laut Vaillant-Definition
6. Feld: ZZ=Target address, kann leer bleiben, wenn der oben in der Datei definierte Wert verwendet werden soll, in diesem Falle => 15
7. Feld: PBSB=Kommandospezifikation, kann leer bleiben, wenn der oben in der Datei definierte Wert verwendet werden soll, in diesem Falle => B509, bestehend aus:     
        B5h="Vaillant command" und 09h="Get Solar Data Block"
8. Feld: Registeradresse => "0600"
9. Feld: Feldbezeichnung, kann leer bleiben
10.Feld: Mehrfach/einfach, kann leer bleiben für Einzelwert
11.Feld: Datentyp => energy4 (Erläuterung siehe unten)
12.Feld: Teiler für den Datenwert, kann leer bleiben
13.Feld: Einheit (kann leer bleiben, wenn man die Ausgabe nicht als "kWh", sondern als dimensionslose Größe haben will)
14.Feld: Weiterer Kommentar, kann leer bleiben

Man muss bei solchen Änderungen insofern aufpassen, als der ebusd offenbar überprüft, ob Registeradressen doppelt vergeben wurden - wenn das der Fall ist, wird die Datei nicht geladen.

Bei den Datentypen ist auch noch Vorsicht geboten. Die sind nämlich in der Konfigurationsdatei _templates.csv definiert. Da ich oben den (für die neuen Konfigurationsdateien bisher nicht vorhandenen) Datentyp "energy4" verwendet habe, muss der auch in diese Datei eingetragen werden. Die notwendige Zeile lautet

energy4,ULG,,kWh,Energie

Darin bedeuten
1. Feld: Name des Datentyps => energy4
2. Feld: primitiver Datentyp => ULG = Unsigned long = 4 Bytes als Ganzzahl
3. Feld: Teiler, kann leer bleiben
4. Feld: Einheit, kann leer bleiben
5. Feld: Kommentar, kann leer bleiben

Diese Datei ist insofern interessant, als dass man darin auch Ersetzungen für bestimmte Datentypen definieren kann, z.B. 0=>OFF, 1=>ON. Das erspart einen solchen Ersetzungsaufwand auf FHEM-Seite. Man hätte natürlich in diesem Falle auch auf die Änderung in _templates.csv verzichten können, indem man als Datentyp in die neue Zeile von vaillant/15.ui.csv statt energy4 einfach ULG eingetragen hätte.

Mit diesen Änderungen habe ich dann den ebusd neu gestartet, et voilà:

ebusctl read -c ui SolarYield

liefert den korrekten Wert.

Mit diesem etwas länglichen Post will ich dafür werben, dass ebusd-Nutzer etwas mit den Konfigurationsdateien experimentieren. Eine Beschreibung des Vaillant-Protokolls und eine größere Anzahl von noch nicht ausgetesteten Registerbeschreibungen sind in der weiter unten angehängten Tabellendatei zu finden. Insbesondere kann das auch dazu dienen, selbst solche Fehler wie "Einstellung geht nicht mehr" zu beheben.

LG

pah

[Sebulba2k]

Hallo Zusammen,

hat jemand eine (Teil-) Funktionierende CSV für einen TEM "IT 5711 OGZ" Universal-Heizungsregler?
Habe mir ein eBUS Adapter Shield C6 zugelegt und entsprechend an die Steuerung angeschlossen und bekomme auch jede Menge Daten, aber kann leider nicht viel damit anfangen.

Vielen Dank & Grüße Jonas

P.S.: Würde mich auch entsprechend erkenntlich zeigen, wenn es funktioniert.

[mikesmiles]

Ich suche nach einer Möglichkeit über den eBus-Adapter die Zusatzheizung f. Warmwasser zu aktivieren? Hintergrund meiner Überlegung. Gerade jetzt im Sommer tut es nicht weh mal schön ein paar kWh durch den Heizstab zu jagen und die Wärmepumpe zu "entlasten"? Ich finde aber keinen Befehl um die Zusatzheizung der Arotherm via eBus zu aktivieren?

[cs-online]

Hallo zusammen,

nach etlichen Jahren, in denen zwei USB-Ebus-Adapter mit Ebusd 2.0 gute Dienste geleistet haben, ziehe ich nun auf einen neuen Server und möchte passend dazu die neuen V6 vom EBUSD-Adapter mit WLAN nutzen. Bestellt, angekommen, geflasht, bis hier hin passt alles. Das erste Problem ist, dass ich zwar eine Verbindung (habe zunächst nur mit meiner Calormatic 560 probiert) hinbekomme und mit Ebusctl auch Daten abfragen könnte, aber zunächst erstmal keine Register gefüllt sind (ich glaube von 2-3 abgesehen), also find -d kaum bis gar keine Daten bringt. Wenn ich mit r-f abfrage, dann sind auch bei find -d dann dort in den abgefragten Registern Daten drin. Selbiges Problem hatte ich auf dem alten System auch, hab mir hier geholfen, indem ich ein Skript zur Abfrage alle 5 Minuten gestartet habe, was aber den Rechner in der Performance ein wenig gebremst hat. Der neue Adapter soll doch, wenn ich das richtig verstanden habe, die Arbitrierung (hab das so verstanden, dass der Trafik auf dem Bus damit aufgenommen wird) übernehmen, aber wie bekommt man das hin, dass ich ohne zyklischen Aufruf eines Skripts aktuelle Werte in möglichst allen Registern bekomme ?

Zweites Problem, wie kann ich es hinbekommen, zwei Adapter gleichzeitg in EBUSD eingebunden zu bekommen ?

Für Hilfe wäre ich sehr dankbar, weil das aktuell noch ein echter Showstopper ist...

Grüße

Christian

[theotherhalf]

Zweites Problem, wie kann ich es hinbekommen, zwei Adapter gleichzeitg in EBUSD eingebunden zu bekommen ?

Ich habe seit mehreren Jahren zwei Adapter an einem Pi in Betrieb, allerdings die ,,alten".
Was genau musst du wissen? Wie die config Datei aussieht?

[cs-online]

Bei den alten hab ich das auch hinbekommen,ist aber schon viele Jahre her mit der 2.0er Version,nur hatte ich jetzt in der config zur neuesten Ebusd gesehen, dass da wohl was geändert wurde,hab nur nicht ganz verstanden,wie das nun gehen sollte...

[theotherhalf]

Bei den alten hab ich das auch hinbekommen,ist aber schon viele Jahre her mit der 2.0er Version,nur hatte ich jetzt in der config zur neuesten Ebusd gesehen, dass da wohl was geändert wurde,hab nur nicht ganz verstanden,wie das nun gehen sollte...

Meine ebusd ist die Version 24, viel hat sich da eigentlich nicht geändert in der config Datei

[cs-online]

...magst mir dann mal deine config teilen ?

Vielleicht blick ich da dann eher durch

Grüße

Christian

[cs-online]

Guten morgen,

mag mir jemand eine Beispielconfig für 2 WLAN Adapter V6 für die neue Ebusd Version schicken? Irgendwie komm ich hier nicht weiter oder hab hier ein dickes Brett vor dem Kopf....

Grüße

Christian

[theotherhalf]

...magst mir dann mal deine config teilen ?

Vielleicht blick ich da dann eher durch

Sorry, hat etwas länger gedauert, ich hoffe es hilft dir!

Code Auswählen Erweitern

# /etc/default/ebusd:
# config file for ebusd service.

# Options to pass to ebusd (run "ebusd -?" for more info):
# EBUSD_OPTS="--scanconfig"

EBUSD_OPTS1="-d /dev/ttyUSB0 -p 8888 -l /var/log/ebusd1.log --pidfile=/var/run/ebusd1.pid --scanconfig --latency=20000 --receivetimeout=50000 --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=192.168.178.9 --mqtttopic=ebusd/%circuit/%name --mqttclientid=Vaillant_VRS620"
EBUSD_OPTS2="-d /dev/ttyUSB1 -p 8889 -l /var/log/ebusd2.log --pidfile=/var/run/ebusd2.pid --scanconfig --latency=20000 --receivetimeout=50000 --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=192.168.178.9 --mqtttopic=ebusd/%circuit/%name --mqttclientid=Vaillant_EcoTec196VC3_5"

# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"

# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.

[cs-online]

Danke dir, das schau ich mir Mal an 😊