eBus Adapter an Vaillant

mge · 14 Mai 2020, 17:15:37

Hallo zusammen ans FHEM-Forum,

ich lese schon eine ganze Weile mit in Bezug auf eBus, bin aber an einem Punkt hängen geblieben, wo mir doch das Wissen bzw. Input fehlt.
Zu meiner "Verteidigung"

, ich nutze OpenHab, aber die eBus-Experten scheinen sich hier aufzuhalten.

Das WIKI hier, die Forenbeiträge und das Github-Wiki von john30 haben schon viel geholfen, aber einige Themen sind aktuell einfach noch "böhmische Dörfer" für mich. Seht daher bitte nach, wenn ich blöde Fragen stellen sollte.

Mein Setup: ich habe eine 4 Jahre alte VAILLANT Gastherme mit VRC700 + VR70 (Solarthermie) -> Arduino Mini Pro am eBus (nur lesend -> blöd) -> FTDI -> Ubuntu, auf dem OpenHab läuft.

Ich sehe reichlich Telegramme fliegen, egal ob ich über ebusd schaue oder aber ebusd beende und aus dem OpenHab-Binding ("eBus 2.0" direkt auf /dev/ttyUSB0 lausche; siehe Anhang). Korrigiert mich, wenn ich das falsch verstanden habe, aber in dem Setup sehe ich nur broadcast-Telegramme, richtig?
Hintergrund ist, ich kann zwar keinen Scan machen, sehe aber nach einer gewissen Zeit trotzdem Geräte auf dem Bus, die das Openhab-Binding dann auch korrekt identifizieren kann als "Thing" (siehe Anhang). Das Binding identifiziert mir auch diverse Items, die ich über den Bus befüllen können müsste (auch hier ein Beispiel im Anhang), allerdings sehe ich hier keine Informationen.

Lange Vorrede dazu, meine Fragen wären.

"Outside Temperature" bekomme ich ausgelesen und aktualisiert, das kommt aber vermutlich über Broadcast, richtig?
Ich hab mir eine eBus-Adapter Platine V1.6 gekauft und gelötet, soweit ich sehen kann nach mehrmaligen Prüfungen, habe ich alles richtig gelötet. Scheinbar aber doch einen Fehler eingebaut, denn wenn ich den Adapter anschließe, startet mein VRC700 neu. Und zwar im etwa 10 Sekunden-Rhythmus. Daher liegt der Adapter natürlich nur erstmal bei Seite. Woran könnte das liegen? Gibt es einen Prüfplan, die Platine auf korrekte Funktion zu testen? Auf den eBus-Klemmen messe ich keine (ausgehende) Spannung wenn ich den Adapter am FTDI habe, ich messe an den Klemmen unendlichen Widerstand (muss ich da ggf. einen messbaren Widerstand haben?). Ich bin daher noch lange nicht so weit, hier die Poti-Einstellungen vorzunehmen
oben genannter Punkt brachte mich dazu zu überlegen, eine Adapter-Platine Version 2(.2) zu löten. Gibt es ggf. noch Platinen aus einer (alten) Sammelbestellung zu kaufen oder ggf. einen fertig funktionierenden Adapter? Löten wäre aber absolut kein Problem

OpenHab ist tatsächlich für mich aktuell noch nicht so das entscheidende; denn soweit ich Log-Files prüfen konnte, sehe ich zwar sehr viele Telegramme, allerdings auch sehr viele "received unknown MS cmd". Kann das das oder eines der Haupt-Probleme sein? (deckt sich auch mit der Aussage, die mir OpenHab anzeigt, "unresolved telegrams ratio" liegt immer so bei etwa 40% bis 45%)

Ich danke Euch vorab schon mal für Eure Unterstützung.
Viele Grüße
Matze.

mge · 21 Mai 2020, 10:36:46

Hat niemand eine Idee dazu?
Möchte gern mit dem Thema weiter kommen.

Würde mich auch über Input freuen, von wo ich eine Version 2.x-Platine beziehen kann.

Danke und beste Grüße
Matze.

Prof. Dr. Peter Henning · 22 Mai 2020, 03:39:45

Einen neu aufgemachten Thread dazu liest kaum jemand. Am Besten in einem der EBUS-Hauptthreads fragen.

LG

pah

Beta-User · 22 Mai 2020, 09:42:44

Ist auch immer ein Problem, wenn man viele unterschiedliche Aspekte gleichzeitig beleuchten will.

OpenHAB kenne ich nicht, aber ist das nicht sehr MQTT-"lastig"? Dann wäre es vermutlich das einfachste, den ebusd mit MQTT-Client-Interface anzuwerfen; darüber kann man auch dann direkt Anweisungen an den Ebus schreiben. Es wird vermutlich nur etwas "lustig", das was da als attrTemplate & Co vorhanden ist, "nach OpenHAB zu übersetzen"...

Afaik (bin kein ebus-Nutzer!) gibt es zu allen Platinenvarianten auch entsprechende Prüfanleitungen für die Schaltungen, und soweit ich das überblicke, haben die Ebus-Leute (v.a. Reinhardt) das ganze auch sehr gut dokumentiert. Auf die Schnelle scheint mir https://wiki.fhem.de/wiki/EBUS ein guter Einstiegspunkt zu sein (Prüfungen!), von da ab dem MQTT2-Pfad folgen, was die MQTT-Themen angeht.

mge · 22 Mai 2020, 18:01:48

Danke für Eure Antworten dazu.
Ich möchte auch erstmal gar nicht auf OpenHAB eingehen, sondern die eBus-Seite beleuchten. OpenHQB kommt dann erst im zweiten Schritt. Hier ist mqtt nicht unbedingt das Maß der Dinge, da OpenHAB ein ebusd-binding (quasi Connector) bietet.

@pah: danke für den Tipp, dann schreibe ich mal dort rein.

Beste Grüße
Matze.

Beta-User · 22 Mai 2020, 18:16:30

Eine Anmerkung noch zu dem MQTT-Hinweis:

Das "Binding" dürfte was ähnliches sein wie ein "Modul" bei FHEM. Auch in FHEM gibt es seit langem ein Modul für den ebusd, aber hier scheint es so zu sein, dass sehr viele User zwischenzeitlich auf den MQTT-Pfad gewechselt sind, weil der einfach sehr viel flexibler Zugriff auf praktisch alle Werte und Einstellungen bietet, ohne dass man groß im Modulcode was ändern müßte.

_Vielleicht_ wäre es doch eine gute Idee, das MQTT-Thema mal näher anzusehen (auch wenn ich keine Ahnung habe, ob OpenHAB da ähnlich flexible Lösungen bietet wie FHEM (da hat Rudi vieles an den generischen MQTT"2"-Modulen extra dafür gebaut, dass es auch auf ein so komplexes Umfeld wie ebus paßt...)).

mge · 22 Mai 2020, 18:22:58

Danke für den Hinweis. In meiner OpenHAB-Installation habe ich schon einiges per mqtt angebunden, werde das auf jeden Fall mal näher beleuchten, wenn ich das eBus-Adapter-Thema im Griff habe!

cs-online · 03 Juni 2020, 14:02:07

Hallo,

mal eine (vielleicht blöde, weil ich das Setup noch nicht ganz geblickt habe) Frage: Kannst du EBUSd nicht direkt ansprechen ? Auf den Raspis kann man im Terminal oder über SSH "ebusctl info" aufrufen, dann sieht man, ob und wie der EBUSD läuft, welche CSVs geladen sind, mit "ebusctl find -d" sehen, welche Werte schon umgesetzt werden konnten, usw. Erst wenn man dort sieht, dass alles sauber läuft, würde ich versuchen, über andere Schnittstellen an die gespeicherten Werte zuzugreifen...

Grüße Christian

mge · 10 Juni 2020, 20:43:04

Hi alle,

vielen Dank für Euren Input und Eure Hilfe. Sorry, dass ich mich lange nicht gemeldet habe, viele andere Projekte parallel (z.B. Familie

).
Ich habe es nun hinbekommen, Daten zu empfangen. Das hat geklappt über ebusd, ebusd mit MQTT und zum Schluss habe ich nun auch die Daten ins OpenHAB bekommen (hatte ja oben geschrieben, dass es mir im ersten Schritt darum ging, überhaupt erst einmal was zu empfangen, OpenHAB logischerweise ist darin der letzte Schritt, egal über welches Protokoll).

Ich habe nun die Hardware getauscht und damit in den Griff bekommen, eine stabile Verbindung aufbauen zu können. Und vor allem auch mit Senderichtung, damit ich pollen kann. Das ging mit dem Arduino Mini ja nicht, da der nur Empfangsrichtung konnte. Gelöst habe ich das ganze nun mit einem eBus-Adapter, für den mein Bruder die Platine entwickelt, geätzt und gelötet hat. Die Platine ist direkt mit FT232 ausgerüstet und damit entfällt das Umsetzen von TTL auf USB. Sehr komfortabel.

Anbei ein Foto der Platine und eines vom selbst gedruckten Gehäuse, passt perfekt. Muss ich jetzt nur noch ordentlich verbauen, baumelt aktuell noch unter der VR70.

Jetzt muss ich lediglich noch rausfinden, die Sensoren vom VR70 für die Solarthermieanlage abzufragen und die aktuelle Kollektortemperatur und Wasserspeichertemperatur rausbekommen. Dann hab ich alles was ich benötige.

Also nochmal danke für Euren Input und beste Grüße
Matthias.

Rolf_bfd1 · 16 Februar 2022, 09:33:54

Hallo mge,

habe gerade mit Interesse gelesen, dass du es geschafft hast über einen selbst gebauten Adapter Informationen über die ebus-Schnittstelle mit dem VRC700 auszutauschen.
Kannst du das vlt noch etwas genauer beschreiben, bzw die Schaltung des Adapters veröffentlichen?

VG, Rolf

mge · 16 Februar 2022, 22:25:34

Hallo Rolf,

ich mache mal eine Anleitung draus, vielleicht hilft es dann in den weiteren Schritten. So läuft das Setup bei mir (und das auch sehr stabil, regelmäßige Neustarts sind eigentlich nicht notwendig).

Mein Setup ist wie folgt: Vaillant ecoTEC (genaues Modell müsste ich prüfen), mit VR70 für die Solarthermie-Steuerung und 300l Brauchwasserspeicher. Dann angesprochener eBus-Adapter an einen Intel NUC i3 (10.Generation) auf dem ein VMWare ESXi läuft, da drauf wiederrum mehere Ubuntu's, für unseren Fall eines für Openhab, auf dem auch Mosquitto und eBusd läuft.

Angefangen habe ich mit der Version 1.6 (die hier: https://wiki.fhem.de/wiki/EBUS), habe aber nie ein Signal hinbekommen. Gründe unbekannt
dann bin ich gewechselt auf Version 2 (den hier, wenn ich mich recht erinnere https://ebus.github.io/adapter/base.en), allerdings dank meinem Bruder in etwas abgewandelter Form mit integr. FT232 wie schon etwas weiter oben beschrieben. Interessant klingt auch der hier: https://adapter.ebusd.eu/. Habe ich absolut keine Erfahrung mit, klingt aber sehr interessant. Version 2 wie gesagt läuft bei mir aber erfolgreich nun seit Juni 2020.
den (ungeschirmten) Anschluss vom eBus habe ich sehr kurz gehalten (genauer gesagt, der Adapter passt noch ins Gehäuse vom VR70 rein), dafür aber 5m USB-Kabel (hier funktioniert bei mir auch eines ohne aktivem Verstärker)
natürlich musste ich nun in meinem Fall das USB-Gerät meiner virtuellen Maschine im ESXi zur Verfügung stellen.
alles folgende als root! Also der Einfachheit halber zu Beginn sudo -i
[optional] da ich ein weiteres USB-Gerät in der VM habe, ist nicht immer sichergestellt, dass der eBus-Adapter immer /dev/ttyUSB1 ist, daher habe ich eine USB-Rule erstellt:
- udevadm info -n /dev/ttyUSB<#_des_Adapters> -a | grep "KERNEL" --> die Ausgabe notieren für das erste USB-Gerät
- udevadm info -n /dev/ttyUSB<#_des_Adapters> -a | grep "KERNEL" --> die Ausgabe notieren für das zweite USB-Gerät usw.
- nano /etc/udev/rules.d/<neue Datei>.rules (z.B. usb-parse-kernel.rules) (siehe Codeschnippsel)
- udevadm trigger --> die neue Regel anwenden
- ll /dev/tty* --> prüfen, ob die symbolischen Links erstellt wurden

Code Auswählen


SUBSYSTEM=="tty", KERNELS=="<EIN Ergebnis aus Punkt 1, in meinem Fall z.B.: 1-1.2:1.0>", SYMLINK+="ttyEBUS"
SUBSYSTEM=="tty", KERNELS=="<EIN Ergebnis aus Punkt 2, in meinem Fall z.B.: 1-1.3:1.0>", SYMLINK+="ttyDEVICE2"

eBusd installieren, zu finden hier: https://ebusd.de/. Richtige Version wählen zum Betriebssystem (Achtung, wenn mit MQTT-Unterstützung gewünscht, dann die Version mit <_mqtt1> wählen. Installation in meinem Fall kurz und knapp wie folgt:
- https://github.com/john30/ebusd/releases --> Download bullseye mqqt1.deb
- WinSCP nach Linux und hochladen
- dpkg --install <pfad>/ebusd-<version>_mqtt1.deb
- /etc/default/ebusd anpassen
- systemctl daemon-reload
- systemctl start ebusd.service
- systemctl enable ebusd.service
- die /etc/default/ebusd sieht bei mir wie folgt aus:

Code Auswählen


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

# Options to pass to ebusd (run "ebusd -?" for more info):
#EBUSD_OPTS="--scanconfig"
EBUSD_OPTS="--scanconfig -p 8888 -l /var/log/ebusd.log -d /dev/ttyEBUS --mqtttopic=ebusd/%circuit/%name --mqtthost=<IP-ADRESSE MQTT-SERVER> --mqttport=1883 --mqttuser=<MQTT-USERNAME> --mqttpass=<MQTT-PASSWORT> --accesslevel=* --scanconfig=full"

ggf. nochmal den Daemon neu starten (systemctl restart ebusd.service)

ebusctl info --> Ausgabe prüfen

Das Ergebnis sollte in etwa so hier aussehen (wichtig ist, auf "signal" zu achten und die erkannten Bus-Adressen, die trudeln bei erfolgreicher Verbindung nach und nach ein):

Code Auswählen


root@OHStation:~# ebusctl info
version: ebusd 22.1.v22.1
update check: OK
device: /dev/ttyEBUS
access: *
signal: acquired
symbol rate: 23
max symbol rate: 139
min arbitration micros: 191
max arbitration micros: 9475
min symbol latency: 5
max symbol latency: 19
reconnects: 0
masters: 3
messages: 654
conditional: 3
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0609;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", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903", loaded "vaillant/52.vr_70.csv"
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103"

Für weitergehendes würde ich dann auf John's gutes und ausführliches Wiki verweisen: https://github.com/john30/ebusd/wiki, z.B. hilft hier das Script readall.sh (/etc/ebusd/readall.sh), wie der Name schon sagt...

Oder ein ebusctl read -f -c 700 Date oder ebusctl read -f -c 700 DisplayedOutsideTemp nur exemplarisch

via MQTT kann nun auch gelauscht und die Daten verwertet werden, prüfen kann man das z.B. mit dem Tool "MQTTBox". Auf den MQTT-Server verbinden und beispielsweise in meiner Konfiguration "ebusd/#" subscriben. Schon "flummelt" es fleißig.
der letzte Punkt mag im FHEM-Forum eher uninteressant sein, dennoch für die Vollständigkeit in meinem Fall: Die Einbindung in OpenHAB schlussendlich erfolgt mittels OpenHAB-Binding ("eBus-Binding") über Netzwerk (localhost:8888). Das Binding erkennt die Geräte auf dem Bus automatisch (in OpenHAB "Things") und auch die vorhandenen Informationen (in OpenHAB "Channels"). Somit ist man relativ schnell am Ziel und hat die gewünschten Werte. Auch via Switch kann z.B. auf dem Bus gesendet werden, um z.B. den Heizmodus umzustellen (Auto/ Tag/ Nacht)

Ich hoffe, die Ausführungen helfen dem einen oder anderen, die Schnittstelle in Betrieb zu bekommen. Es geht natürlich noch viel mehr, aber für den Start war das für mich das Entscheidende.

Viele Grüße
Matze.

Rolf_bfd1 · 18 Februar 2022, 11:00:32

Hallo Matze,

vielen Dank für deine ausführliche Erklärung! - Ist ja doch eine Menge zu tun $:-\$

VG, Rolf