Läuft: Heizung mit eBus-Schnittstelle

[Prof. Dr. Peter Henning]

Vor mehr als 10 Jahren, am 29. November 2014 habe ich hier den ersten Post zur erfolgreichen Ankopplung von EBUS an FHEM gesetzt.

Seitdem läuft mein erster und originaler eBus-Adapter auf einer Lochrasterplatine, und ist an einen Raspberry Pi 1 angeschlossen. Die Software des ebusd hat, ich wage es kaum zu schreiben, den Versionsstand 2.0. Es handelt sich auch noch um die erste und originale SD-Karte.

In der gesamten Zeit: Keine Fehler, keine Macken.

Ich denke dennoch, dass es Zeit ist, diese Hard- und Software aufs Altenteil zu schieben und einen neuen eBus Adapter via MQTT anzubinden.

Zwar habe ich derzeit parallel schon ebusd 24.1 mit einem neuen Adapter laufen. Dabei stolpere ich darüber, dass zwar Hardware und Software besser geworden sind - aber die Dokumentation nicht.

Kann mir irgendjemand sagen, ob ich meine alten Konfigurationsdateien (CSV-Format) auch mit einem "neuen" ebusd nutzen kann, und wo die zu liegen haben?

LG

pah

[TomLee]

Hier steht das man alternativ zum default (https://ebus.github.io/), den Pfad zu den Dateien in configpath angeben kann.

[m8haben]

Hier steht das man alternativ zum default (https://ebus.github.io/), den Pfad zu den Dateien in configpath angeben kann.

Moin, bei mir läuft das nicht. Ich gebe den Pfad zu den Config-Dateien (csv) an, aber er lädt dann keine Config-Dateien. Ich habe zur Zeit das Problem, dass eine falsche csv zu meinem Gaskessel geladen wird. Siehe meinen Beitrag vorher. Wenn ich mit configpath= https://cfg.ebus.eu in der default ebusd starte holt er die csv alle, aber eben eine falsche für meinen Kessel. Wenn ich alle csv´en in /etc/default/ ablege und auch so im configpath eintrage holt er die csv´en aber nicht. Wo werden die csv´en, die ich über https:// cfg.ebus.eu hole, dann im meinem System abgelegt?
Gruß Roland

[Prof. Dr. Peter Henning]

Natürlich will ich da nicht übermäßig meckern, schließlich ist da viel Arbeit anderer Leute hineingeflossen.

Dennoch: Ich halte es auch für einen Irrweg, Konfigurationsdateien ziemlich intransparent über das Netz zu holen. Nach meinem Verständnis werden die auch nicht lokal abgelegt, sondern stehen nur im Speicher.

Ebensowenig kann ich mit dem Format anfangen. Da soll man erst komplizierte DevSpec-Dateien erzeugen, die dann doch wieder in eine CSV_Datei umgewandelt werden???
Da war ich vor 10 Jahren weiter, indem ich einfach mit einem Spreadsheet + Makros gearbeitet habe. Das klartextlesbare Spreadsheet hat auf Knopfdruck die Konfigurationsdatei ausgespuckt.

Außerdem habe ich bemerkt, dass meine 10 Jahre alten Konfigurationsdateien mehr dekodierte Nachrichten enthalten, als die "offiziellen" - sehr seltsam.

Bevor ich dazu ein Fass aufmache, muss ich aber erst auf die allerneueste Version des ebus-Adapters warten, die kommt aus China und wird noch ein paar Tage brauchen.

LG

pah

[m8haben]

Moin,
mache mal ein

Code Auswählen Erweitern

ebusctl find id und vorher vielleicht noch ein

Code Auswählen Erweitern

ebusctl iSchicke mir mal beide Anzeigen.
Ich kämpfe auch schon lange mit falschen oder aber nicht mehr so funktionieren csv´en
Gruß Roland

P.S. Wo hast du die Config-Datei?
loacal oder vom Server.

[Prof. Dr. Peter Henning]

So, der allerneueste ebus-Adapter ist da und funktioniert bestens.

Und jetzt stolpere ich über die offenbar nicht mehr funktionierenden Konfigurationsdateien - sehr schön erkennbar, weil mein 10 Jahre alter Raspberry Pi mit ebenso altem ebusd-Adapter parallel läuft

Hier mal die Ausgabe von

ebusctl find | grep -v 'no data stored'

- also alle gefundenen nicht-trivialen Daten

ebusd Version 2, Konfigurationsdateien lokal von 2014, ebus-Adapter von 2014 auf Lochrasterplatine

BC BCDateTime2 = 12:19:01;21.02.2025
broadcast BCDateTime = 12:19:01;21.02.2025
broadcast BCOutsideTemp = 11.875
bai00 FillPressure = 1.939;ok
bai00 FlowTemp = 37.00;ok
bai00 ID = b5;BAI00;7;30;74;1
bai00 Mode = standby
bai00 Status01 = 35.0;35.0;-;-;-;off
bai00 StorageLoadPumpStatus = off
hc currenterror = -;-;-;-;-
hc DCFStatus = valid;12:19:55;21.02.2025;11.875
hc Mode = 21;auto
hc Param = 21;20;140;0;133;17;0;15;75;0
hc Status1 = 51.12;0;1;0;40
hc Status2 = 39;0;37.50;21
hc SumFlowSensor = 36.75;ok
hwc isHWCService = yes
hwc Mode = 55;auto;02;off
hwc Status1 = 0;0;57.12;55
mc Mode = 20;auto
sc Mode = 0;auto;02;off
sc Status0 = 57.12;32.25;37.69
sc Status1 = 38.69;1;8726;-;0;0
sc Status2 = 6255;180;0
sc Status3 = 19.0;1;31.5;14.0
scan.26 ident = Vaillant;SOLSY;0500;6301
scan.50 ident = Vaillant;SOLSY;0500;6301
vrs620 HcName1 = HC         
vrs620 SolarYield = 6253
vrs620 SolarYieldApr = 0
vrs620 SolarYieldAug = 0
vrs620 SolarYieldDec = 0
vrs620 SolarYieldFeb = 28
vrs620 SolarYieldJan = 19
vrs620 SolarYieldJul = 0
vrs620 SolarYieldJun = 0
vrs620 SolarYieldMar = 0
vrs620 SolarYieldMay = 0
vrs620 SolarYieldNov = 0
vrs620 SolarYieldOct = 0
vrs620 SolarYieldSep = 0

ebusd Version 24.1, Konfigurationsdateien auf dem Server, eBUS Adapter Shield C6 von 2025

bai FlowTemp = 37.00;ok
bai SetMode = auto;50.0;-;-;0;0;0;0;0;0
bai Status01 = 35.0;34.0;-;-;-;off
bai WaterPressure = 1.559;ok
Broadcast Datetime = 11.875;12:24:05;21.02.2025
Broadcast Outsidetemp = 11.875
Broadcast Signoflife =  (empty for 7ffe07ff00 / )
Broadcast Vdatetime = 12:24:05;21.02.2025
hc Currenterror = -;-;-;-;-
hc DateTime = valid;12:24:22;21.02.2025;11.875
hc SumFlowSensor = 35.44;ok
hwc Mode = 55;auto;off;hwc;00;day
hwc Status = 0;off;56.12;55
mc Mode = 20;auto;0;0;low;inactive;day
scan.08  = Vaillant;BAI00;0730;7401
Scan.08 Id = ;;;;;;
scan.15  = Vaillant;UI   ;0508;6201
Scan.15 Id = 21;14;22;0020080465;0907;005736;N9
scan.23  = Vaillant;SOLSY;0500;6301
Scan.23 Id = 21;14;21;0020080463;0907;005476;N9
scan.25  = Vaillant;SOLSY;0500;6301
Scan.25 Id = 21;14;21;0020080463;0907;005476;N9
scan.26  = Vaillant;SOLSY;0500;6301
Scan.26 Id = 21;14;21;0020080463;0907;005476;N9
scan.50  = Vaillant;SOLSY;0500;6301
Scan.50 Id = 21;14;21;0020080463;0907;005476;N9
scan.ec  = Vaillant;SOLSY;0500;6301
Scan.ec Id = 21;14;21;0020080463;0907;005476;N9
ui YieldThisYear = 19;28;0;0;0;0;0;0;0;0;0;0

Natürlich gibt es da ein paar Abweichungen, weil die ebusd-Maintainer die Bezeichnungen geändert haben.

Es ist aber erstens ärgerlich, dass mit den gegenwärtigen Konfigurationsdateien nicht einmal die Hardware (Vaillant vrs620) richtig identifiziert wird.

Zweitens ist auch gar nicht klar, welche Daten noch abgefragt werden können. Beispielsweise kann ich mit meinen alten Konfigurationsdateien problemlos auch solche Sachen abfragen wie die Steuerung der Nachtabsenkung für Donnerstag:

ebusctl read -c hc Timer.Thursday

mit der Antwort

hc Timer.Thursday = 05:30;22:00;22:00;22:00;22:00;22:00;selected

Das wird in der Folge auch gecached, prima - aber ich habe keinen Schimmer, wie ich mit den neuen serverbasierten Dateien da dran kommen kann.

Im nächsten Schritt wird mir nichts anderes übrig bleiben, als die Dateien vom Server mit meinen alten zu vergleichen.

Übrigens: Meine alten Dateien, und zwar auch als klartextlesbares Spreadsheet, stehen immer noch im contrib-Ordner von FHEM zur Verfügung.

LG

pah

[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