Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
dabei musste ich nochmal über den Weg nachdenken, wie wir mehrere Parameter in einem Antwort- oder Cycle-Telegramm auswerten. Alle Parameter aus einem Telegramm in ein Array zu packen, scheint effizient. Man muss dann danach aber nochmal Aufwand treiben, um den richtigen Parameter/Wert rauszubekommen (wie pflege ich das in der Konfig?).
Von der Konfiguration scheint es mir einfacher, dass man jeden Parameter separat abfragt. Zugegeben, damit erhöht man die Anzahl der Get-Telegramme.
Hab ich mich klar genu ausgedrückt?
Gruß
Ja hast Du, und so hab ich es bisher auch in der config gepflegt.
Hier mal ein Beispiel:
Ja hast Du, und so hab ich es bisher auch in der config gepflegt.
Ok, so werde ich dann die Wolf Config auch aufbauen.
Denkst Du, dass im Falle von GET wir dann für jede Zeile ein get-Telegramm schicken und dann nur den Parameter der einen Zeile in der Konfig auswerten, oder denkst Du der Daemon sollte/müsste alle Konfigzeilen desselben get-Telgrames zusammenfassen? Also ein Get Telegramm abschicken und dann alle verfügbaren Werte zurückliefern?
Ich würde den Daemon mit den Kurznamen arbeiten lassen. Die Ansteuerung kommt dann von aussen "get Speichertemperatur" und der Daemon sucht in seiner config den short_name "Speichertemperatur", sendet das entsprechende Telegramm, wertet es aus und gibt z.B.: "53" zurück.
Wir sind in den Vaillant configs bei weit über 150 möglichen Lesebefehlen, davon sind vielleicht 5-10 wirklich interessant, und 20 braucht man vielleicht gelegentlich.
Ich bin für ein "aktives" Konzept, also Daten nur auf Anforderung. Ein wünschenswertes Feature wäre natürlich: Sende mir alle 60 Sekunde die Werte x,y,z per UDP. Aber dafür haben wir noch ein wenig Arbeit vor uns und müssten Roland mal mit einem C-Kollegen entlasten
Ich würde den Daemon mit den Kurznamen arbeiten lassen. Die Ansteuerung kommt dann von aussen "get Speichertemperatur" und der Daemon sucht in seiner config den short_name "Speichertemperatur", sendet das entsprechende Telegramm, wertet es aus und gibt z.B.: "53" zurück.
Perfekt, dass lässt sich gut pflegen - gefällt mir.
Bedeutet halt nur, dass im Zweifel das gleiche GET-Telegramm mehrfach abgesetzt wird, falls ich zwei unteschiedliche Parameter hintereinander abfragen will, die über das gleiche get abgerufen werden. Ich finde das aber nicht schlimm!
ich habe mal eine erste Config für meine Wolf Gastherme ins SVN geschoben.
Das pflegen der Konfiguration hat soweit auch gut funktioiniert.
@JuMi: wäre super wenn Du es Dir mal anschauen könntest.
Zwei Fragen haben sich für mich ergeben:
1. bei Service 05 03 gibt es laud Spezifikatioion zwei Blöcke. Diese werden über byte 06 angegeben. Allerdings habe ich bei mir bisher nur Block 01 gesehen.
2. Zustände und Status werden viel über Bits angegeben. Z.B. Service 05 03; Position 08. Wie wollen wir sowas konfigurieren?
Hallo Moritz,
kannst Du mal Beispiele von den Telegrammen posten?
Ich seh da gerade mit data_pos und answer_bytes nicht durch.
Vor allem von denen hier:
10 03 05 07 09 ...
03 fe 05 03 08 ...
Das passt nämlich z.B. bei "Kesselsolldruckwert" nicht. Die data_pos bezieht sich auf die Bytenummer der Nachricht und nicht die Bytenummer des Telegrammes, das wäre aber auch leicht zu korrigieren.
Wollte meinen Adapter auch schonmal anschließen. Unser Solarmodul hat dafür auch außen einen Anschluss. Sieht aus wie ein Western-Stecker. Dachte da würde ein normaler 4-poliger Telefonstecker reinpassen...aber leider nicht. Ist kleiner :-(
Irgendjemand 'ne Ahnung, was das für einer ist? Leider ist das Modul so toll in die Ecke gebaut, dass ich mir das nur mit 'nem Zahnarztspiegel anschauen kann. Aber Spiegel und Stecker reinfummeln zugleich geht nicht.
Weiß nur, dass er nicht passt.
Klar kann man das eBus-Signal auch noch innen abgreifen. Mit gefällt aber eigentlich die Idee, hier von außen ranzugehen, denn noch haben wir Garantie auf die gesamte Anlange....
Also jemand 'ne Idee, was für ein Stecker das genau ist und wo man so'n Kabel bekommt?!
ich habe mal eine erste Config für meine Wolf Gastherme ins SVN geschoben.
Hi Moritz,
ich habe eine neue Wolf CGB-11 und interessiere mich brennend für dein Setup, weil meine Situation leider unverändert die ist, dass ich gar nichts vom Ebus sehe. Wie genau hast du das (Hardware-)Setup gemacht? (Bausteine, Verdrahtung...)
Danke für deine Hilfe,
Fry
@moritz, genau das meinte ich. Die Telegramme bestätigen auch den Verdacht.
1. Ein Broadcast Telegramm (Ziel=0xFE) bekommt natürlich kein ACK (0x00) und sendet das SYN (0xAA) direkt im Anschluss.
2. Die cycle Telegramme bei Wolf sind keine Anfragetelegramme i.d.S. dass der Empfänger die auszuwertenden Daten sendet. Daraus folgt dann dass answer_bytes eben 0 ist bzw. erstmal leer ist. Ich wäre dennoch für das ausfüllen der Spalte. Nach den Datenbytes kommt dann lediglich das CRC, dann das ACK vom Empfänger und das SYN des Senders.
Das interpretieren von Bits müsste dann das Plugin oder was immer übernehmen.
Wie genau hast du das (Hardware-)Setup gemacht? (Bausteine, Verdrahtung...)
Hallo Fry,
ich versuchs mal zusammenzufassen. Wenn ich was vergessen habe oder was unklar ist, einfach nachhaken.
Hardware:
CGB-(K)20 mit Solar
Ebus USB Koppler von eservice-online
Den habe ich mit ganz normaler 2-draht Leitung an den EBus von der Therme geklemmt (Bei mir war es am einfachsten am Solarmodul zu klemmen)
USB ans Wiregate (USB Hub mit eigener Stromversorgung)
Software:
Der USB Koppler wird am Wiregate ohne Probleme erkannt
Ich habe mir eine udev Regel erstellt, damit ich das Device nicht suchen muss:
Code:
user@wiregate248:~/src/ebusd$ cat /etc/udev/rules.d/usbserial.rules
# Moi 2012-12-15
# rules to give specific names to usb serial devices
#
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", \
ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6001",ATTRS{serial}=="AHVPBDMS" \
SYMLINK+="ttyUSBHeizung"
idVendor usw bekommst Du mit dmesg der lsusb -v
Dann solltest Du mit cat, socat, od -x oder ähnlichem jedenfalls Daten auf dem Interface finden (Bei Problemen hat es sich als hilfreich gezeigt, mal ein altes Windows mit hterm auszupacken)
Jetzt ausm OpenAutomation SVN (das gleiche wie das der Cometvisu) den ebus code von yuhu und jumi ziehen:
im Verzeichnis ebusd den ebus daemon kompilieren - einfach ein make. Falls noch nicht vorhanden: apt-get install build-essential
jetzt kannst Du mit ./ebusd -f -l3 -s /dev/[Dein Device] mal schauen, ob Du Telegramme empfängst.
Falls Du viele Zeilen mit "aa" siehst, ist alles gut. Falls nicht, musst Du am Poti vom Ebus Adapter drehen, bis Du zwischen den eigentlichen Telegrammen viele "aa" syncs siehst.
wenn das erledigt ist, kannst Du den ebus Daemon mit -n starten, dann zeigt er Dir die vielen syncs nicht mehr an.
Hilfreicht sind noch zwei Tools von yuhu: check und serial_write. wechsel ins tools Verzeichnis und mach ein "gcc -Wall -o check check.c" und das gleiche fürs serial_write
mit ./check kannst Du aus den Hex Werten die richtigen Daten übersetzen. Mit serial_write kannst Du selber Telegramme auf den Bus schicken.
Wenn das soweit funktioniert, geht es ans Telegramme entziffern. Wolf benutzt neben dem Standard Kromschröder Telgramme. Die sind eher gar nicht dokumentiert.
Falls Du da wirklich eine Möglichkeit hast, von Wolf was zu bekommen, wäre das super!
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar