ebusd

[Helmut]

Hallo zusammen,

ich installiere gerade die ebusd auf meinem System. Über Telnet kann ich alle werte der "ehp_brinetowater.csv" meiner Vaillant VWS 101/3 auslesen. Soweit scheint alles bisher zu funktionieren.
Aber die Datei ebusd.log im Verzeichnis /var/log/ wächst ständig, obwohl ich ohne Parameter -l gestartet habe. "ebusd -d 192.168.178.225:5000 -p 8888"
ist das so ok?

Gruß Helmut

2015-10-1620:52:25.065 [update notice] unknown MS cmd: 1008b5090329b801 / 03b80100
2015-10-16 20:52:25.228 [update notice] unknown MS cmd: 1008b5090329b901 / 03b90100
2015-10-16 20:52:25.400 [update notice] update ehp SourceTempInput QQ=10: 9.88;ok
2015-10-16 20:52:25.563 [update notice] update ehp ActualEnvironmentPowerPercentage QQ=10: 0
2015-10-16 20:52:25.726 [update notice] update ehp ActualEnvironmentPower QQ=10: 0
2015-10-16 20:52:25.889 [update notice] unknown MS cmd: 1008b5090329e201 / 03e2017a
2015-10-16 20:52:26.061 [update notice] update ehp FlowTemp QQ=10: 28.50;ok
2015-10-16 20:52:26.633 [update notice] unknown MS cmd: 1008b5100900023a000000000000 / 00
2015-10-16 20:52:27.008 [update notice] unknown MS cmd: 1008b509040ed10001 / 00

[johnm]

Hallo,
gibt es eigentliche eine Möglichkeit, die Fehlermeldungen der Wärmepumpe über ebusd auszulesen und abzuspeichern? Und wenn ja, wie?

Also, die Fehlerhistorie lässt sich wohl mit b50303010100 und folgenden abrufen. Das ist etwas wiederlich, weil das letzte Byte so lange erhöht werden muss, bis die Antwort mit 00 anfängt.
Beispiel:

ebusctl write -h 26b50303010100
08020d1101030e1902

Und wenns dann nichts mehr interessantes gibt:

ebusctl write -h 26b50303010109
0800ffffffffffffff

Der aktuelle Fehler ist so zu finden:

ebusctl write -h 26b503020001
0affffffffffffffffffff

Wenn da ff drin steht, gibts gerade keinen Fehler.

[johnm]

Aber die Datei ebusd.log im Verzeichnis /var/log/ wächst ständig, obwohl ich ohne Parameter -l gestartet habe. "[FONT=&quot][COLOR=#000000][FONT=arial][SIZE=14px]ebusd -d 192.168.178.225:5000 -p 8888"
ist das so ok?

Wenn Du weniger Logging haben willst, dann kannst Du z.B. den Level ändern mit "--loglevel=error", siehe https://github.com/john30/ebusd/wiki/2.-Run#log-options

[johnm]

Die Meldung "[bus debug] ERR: SYN received during skip, switching to ready" kommt aber immer -- egal wie ich das Poti am eBus-Adapter regle. Praktisch nach jeder auf dem ebus übertragenen Meldung. Teste gerade noch im readonly-Modus. Die Me ldung sieht man aber nur, wenn man loglevel=debug setzt.

Also Debug Meldungen sind wie der Name schon suggeriert zum Debugging...
"ERR: SYN received during skip, switching to ready" ist völlig normal, weil am Bus eine AUTO-SYN Einheit angeschlossen ist, die nach definierter Schweige-Zeit auf dem Bus ein SYN abgibt. Also völlig normal.

Außerdem kommt noch gelegentlich ein "[bus debug] ERR: read timeout during receive command ACK, switching to skip" hinzu.

Ebenfalls debug... Wenn im Zustand "receive command ACK" keine Antwort kommt, heißt das, dass einer eine Nachricht an einen Teilnehmer geschickt hat, die dieser nicht willens ist zu beantworten. Entweder weil er gar nicht existiert, oder weil er schlicht nichts damit anfangen kann. Das ist zum Teil bei Vaillant auch nicht ungewöhnlich.

[johnm]

meine WP, hat noch diese Funktionen:

Einmalig Aufladen
Party (Speicher bleibt die ganze Zeit Warm)
Sparen aktiviert bis (UHRZEIT)

In der aktuellen https://github.com/john30/ebusd-conf...t_de/quick.csv sind die drei jetzt enthalten.

[johnm]

Ich habe hier ein Problem mit dem ebusd.
Leider fällt dieser einfach aus bzw. verliert das Signal. Der alte lief Monate lang sauber durch ohne restart oder dergleichen .. wie kann ich das weiter debuggen?

 Oct 15 02:27:49 black-board-automation ebusd[14527]: 2015-10-15 02:27:49.520 [update notice] unknown MS cmd: 1008b5090329e201 / 03e20147
Oct 15 02:27:49 black-board-automation ebusd[14527]: 2015-10-15 02:27:49.692 [update notice] update ehp FlowTemp QQ=10: 23.88
Oct 15 02:27:50 black-board-automation ebusd[14527]: 2015-10-15 02:27:50.845 [update notice] update mc DateTime QQ=10: valid;04:27:52;15.10.2015;7.688
Oct 15 02:27:52 black-board-automation ebusd[14527]: 2015-10-15 02:27:52.347 [update notice] update broadcast hwStatus QQ=10: 0;24;0
Oct 15 02:27:54 black-board-automation ebusd[14527]: 2015-10-15 02:27:54.405 [update notice] unknown MS cmd: 1025b505072b010100000000 / 00
Oct 15 02:27:54 black-board-automation ebusd[14527]: 2015-10-15 02:27:54.858 [update notice] update bc Status QQ=10: 24.69;2.144;2.191;03 08 00 00
Oct 15 02:27:55 black-board-automation ebusd[14527]: 2015-10-15 02:27:55.021 [update notice] unknown MS cmd: 1008b5110102 / 050000c800c8
Oct 15 02:27:56 black-board-automation ebusd[14527]: 2015-10-15 02:27:56.403 [update notice] unknown MS cmd: 1008b5130304cd01 / 0acd010100000001000100
Oct 15 02:27:58 black-board-automation ebusd[14527]: 2015-10-15 02:27:58.427 [update notice] update bc Mode QQ=10: off
Oct 15 02:27:58 black-board-automation ebusd[14527]: 2015-10-15 02:27:58.846 [update notice] unknown MS cmd: 1008b509040ed10001 / 00
Oct 15 02:28:00 black-board-automation ebusd[14527]: 2015-10-15 02:28:00.432 [update notice] update cp Mode QQ=10: 30;auto;00;0
Oct 15 02:28:00 black-board-automation ebusd[14527]: 2015-10-15 02:28:00.599 [update notice] update cp Status QQ=10: 0;0;-;0
Oct 15 02:28:04 black-board-automation ebusd[14527]: 2015-10-15 02:28:04.027 [bus error] signal lost
Oct 15 02:31:47 black-board-automation ebusd[14527]: 2015-10-15 02:31:47.348 [bus error] send to 08: ERR: no signal, give up
Oct 15 02:31:47 black-board-automation ebusd[14527]: 2015-10-15 02:31:47.348 [main error] send message: ERR: no signal
Oct 15 02:31:48 black-board-automation ebusd[14527]: 2015-10-15 02:31:48.356 [bus error] send to 08: ERR: no signal, give up
Oct 15 02:31:48 black-board-automation ebusd[14527]: 2015-10-15 02:31:48.356 [main error] send message: ERR: no signal
Oct 15 02:31:49 black-board-automation ebusd[14527]: 2015-10-15 02:31:49.363 [bus error] send to 08: ERR: no signal, give up

Also bei mir passiert es ab und an mal, dass sich das USB Device verabschiedet (ist allerdings ein kommerzieller Adapter). Dann muss ich ebusd neu starten, damit alles wieder gut ist. Warum das passiert, konnte ich noch nicht rausfinden.

Signal lost kommt dann, wenn kein SYN innerhalb der vorgegebenen Zeit vorbei kommt. Das Timing ist relativ "eng" (45 ms). Um das zu debuggen, einfach mal in einem client "raw" absetzen, dann wird jedes gelesenes und geschriebens byte ins Log geschrieben (Vorsicht, das Log wächst dann sehr schnell!).

Daran kann man dann die Zeiten ablesen und ich vermute stark, dass das eben deutlich mehr als 45ms sind...

[sparsematrix]

In der aktuellen https://github.com/john30/ebusd-conf...t_de/quick.csv sind die drei jetzt enthalten.

Hallo,

danke für die CSVs.

in welchem Format muss das Datum gesetzt werden?

So?

ebusctl write save 22:00


Gruß
spars

[johnm]

in welchem Format muss das Datum gesetzt werden?

So?

ebusctl write save 22:00

Das müsste so passen, ja.

[Goodevil]

Hallo zusammen,
erst einmal vielen Dank an John für die geniale (Weiter-)Entwicklung des ebusd.
Mein Plan ist meine Vailland geoTherm plus mit dem ebusd auszulesen und zu steuern. Dazu habe ich einen Raspberry Pi (B2) mit einem ebus-Koppler von eservice online angeschlossen und die aktuelle ebusd Version kompiliert. Allerdings bin ich etwas am verzweifeln. Im Großen und Ganzen funktioniert das auslesen, ich bekomme jedoch häufig Fehlermeldungen beim Absetzen der Kommandos. Setze ich z.B. alle paar Sekunden ein "r -f outsidetemp" über den ebusctl ab, funktionieren nur ca. 2 von 3 Aufrufen. Bei den anderen bekomme ich Fehlermeldungen wie

ERR: invalid argument
ERR: element not found
ERR: CRC error
ERR: arbitration lost

Im ebusd steht dann entsprechend:

2015-10-30 23:23:25.830 [bus error] send to 08: ERR: invalid argument, retry
2015-10-30 23:23:27.502 [bus error] send to 08: ERR: ACK error, retry
2015-10-30 23:23:28.371 [bus error] send to 08: ERR: arbitration lost, retry
2015-10-30 23:23:28.600 [bus error] send to 08: ERR: invalid argument, retry
2015-10-30 23:23:29.914 [bus error] send to 08: ERR: CRC error, retry
2015-10-30 23:23:30.656 [main error] read ehp OutsideTemp: ERR: element not found
2015-10-30 23:23:31.227 [bus error] send to 08: ERR: invalid argument, retry
2015-10-30 23:23:31.747 [bus error] send to 08: ERR: invalid argument, retry
2015-10-30 23:23:32.466 [bus error] send to 08: ERR: CRC error, retry
2015-10-30 23:23:33.117 [bus error] send to 08: ERR: invalid argument
2015-10-30 23:23:33.118 [main error] send message: ERR: invalid argument
2015-10-30 23:23:35.727 [bus error] send to 08: ERR: invalid argument, retry
2015-10-30 23:23:36.463 [bus error] send to 08: ERR: ACK error, retry
2015-10-30 23:23:37.014 [bus error] send to 08: ERR: invalid argument, retry
2015-10-30 23:23:37.524 [bus error] send to 08: ERR: invalid argument
2015-10-30 23:23:37.525 [main error] send message: ERR: invalid argument
2015-10-30 23:23:38.186 [bus error] send to 08: ERR: CRC error, retry

Bei einigen wenigen Aufrufen erhalte ich auch vollkommen falsche Werte. Bsp:

localhost:  r -f outsidetemp
261.81;ok

Am Poti des ebus-Kopplers habe ich schon wie verrückt gedreht. Egal ob im oberen, mittleren oder unteren Teil des Bereichs in denen er Daten empfängt sind die Fehlermeldungen und "Ausbeute" identisch. So langsam habe ich das Gefühl das Gerät spinnt.
Angeschlossen ist der ebus-Koppler über einen ca 4m langen geschirmten Schaltdraht (0,6mm²). Könnte eventuell die Kabellänge das Problem sein?

[johnm]

Im ebusd steht dann entsprechend:

2015-10-30 23:23:25.830 [bus error] send to 08: ERR: invalid argument, retry
2015-10-30 23:23:27.502 [bus error] send to 08: ERR: ACK error, retry
2015-10-30 23:23:28.371 [bus error] send to 08: ERR: arbitration lost, retry
2015-10-30 23:23:28.600 [bus error] send to 08: ERR: invalid argument, retry
2015-10-30 23:23:29.914 [bus error] send to 08: ERR: CRC error, retry

Am Poti des ebus-Kopplers habe ich schon wie verrückt gedreht. Egal ob im oberen, mittleren oder unteren Teil des Bereichs in denen er Daten empfängt sind die Fehlermeldungen und "Ausbeute" identisch. So langsam habe ich das Gefühl das Gerät spinnt.
Angeschlossen ist der ebus-Koppler über einen ca 4m langen geschirmten Schaltdraht (0,6mm²). Könnte eventuell die Kabellänge das Problem sein?

Kurze Antwort: weiterdrehen!
Lange Antwort: Die Einstellung des Poti ist unglaublich empfindlich und man muss mit Fingerspitzengefühl den Punkt erwischen, wo die Kommunikation reibungslos klappt.
Mein Tipp: Poti ganz nach links, dann so lange nach rechts drehen, bis die LED dauerhaft leuchtet.
Jetzt kommt die Feineinstellung: gaaanz langsam und in minimalen Schritten nach links drehen, bis die LED wieder flackert (aber nicht zu viel).
Dann ist man an dem Punkt, wo es ziemlich gut aussehen sollte. Bei mir ist das glaube ich ein Stück vor der Mittelstellung.
Dann kannst Du das ebusd Log mitlaufen lassen. Wenn gar keine CRC Fehler mehr kommen, dann bist Du gut dabei.

[JuMi2006]

Ich habe hier ein komisches Phänomen beobachtet.

Ich frage alle 90 Sekunden die Werte ab. Während ich bei "ehp FlowTemp" auch immer unterschiedliche Werte bekomme die zum Heizungsverlauf passen bleibt "ehp Integral" teilweise länger konstant und hat dann ziemlich große Sprünge in den Werten.

Mir scheint da werden teilweise die Werte nicht neu ausgelesen sondern kommen aus einem Cache vom ebusd? Kann das sein?

Grüße

Version: ebusd 2.0.0-preview.3fa4655

[Thomas3025]

Hallo zusammen,

im Moment experimentiere ich auch mit der ebus Anbindung meiner Heizung. Erwähnenswert ist dabei noch, dass ich hier ziemlicher Anfänger bin. Es handelt sich dabei um ein Weishaupt WTC-15A Brennwertgerät. Leider muss ich feststellen, dass es schon bei recht grundlegenden Dingen nicht klappt. Ich verwende auch den Ebus-Koppler von eservice mit Ethernet-Schnittstelle.

Ich kann darauf mit ebusd (Version 2.0.0-preview.79cbd56) zugreifen, jedoch ist das Signal sehr instabil. Ich hab heute ca. ne halbe Stunde damit verbracht, das Poti, wie in Beitrag #205 beschrieben einzustellen.
Danach hatte ich immerhin eine ganze Reihe Busteilnehmer beim Scan angezeigt bekommen. Ich habe allerdings lediglich alle 30 Sekunden folgenden Eintrag in der ebusd.log stehen:

"2015-12-22 22:55:58.328 [update notice] unknown BC cmd: f1fe500a0d01000702003e70ff0080aae108"
Kann es tatsächlich sein, dass da nicht mehr von dem Gerät versendet wird?

Als ich dann irgendwann des ebusd neu gestertet habe, hat er wieder nur einen Master erkannt und die Fummelei ging von vorne los.

Darüber hinaus habe ich mit den unterschiedlichsten Kombinationen versucht, Read-Telegramme abzusetzen, aber jedesmal mit dem Fehler "element not found" oder "invalid argument". Liegt das daran, weil keine .csv-Datei mit den Daten von Weishaupt hinterlegt sind? Gibt evtl. hier noch jemanden, der sich schon eingehender mit Weishaupt beschäftigt hat. Alles googeln hatte da bisher wenig Erfolg.

Für ein paar Hinweise, wie ich hier weiter kommen könnte, wäre ich sehr dankbar.

Viele Grüße

Thomas

[johnm]

Ich habe hier ein komisches Phänomen beobachtet.
Ich frage alle 90 Sekunden die Werte ab. Während ich bei "ehp FlowTemp" auch immer unterschiedliche Werte bekomme die zum Heizungsverlauf passen bleibt "ehp Integral" teilweise länger konstant und hat dann ziemlich große Sprünge in den Werten.

Mir scheint da werden teilweise die Werte nicht neu ausgelesen sondern kommen aus einem Cache vom ebusd? Kann das sein?

Richtig. Ohne den Parameter "-f" an das "read" Kommando, wird immer der Cache benutzt, sofern die Daten nicht älter sind als 5 Minuten.

[johnm]

"2015-12-22 22:55:58.328 [update notice] unknown BC cmd: f1fe500a0d01000702003e70ff0080aae108"
Kann es tatsächlich sein, dass da nicht mehr von dem Gerät versendet wird?

Das ist schon möglich. Aber wenn Du eh Signalprobleme hast, kann es auch gut sein, dass der Rest an Nachrichten wegen ungültiger CRC etc. von ebusd komplett verworfen wird.
Einfach mal den Log Level erhöhen ("ebusctl log level info" oder ganz krass debug statt info).

Darüber hinaus habe ich mit den unterschiedlichsten Kombinationen versucht, Read-Telegramme abzusetzen, aber jedesmal mit dem Fehler "element not found" oder "invalid argument". Liegt das daran, weil keine .csv-Datei mit den Daten von Weishaupt hinterlegt sind? Gibt evtl. hier noch jemanden, der sich schon eingehender mit Weishaupt beschäftigt hat. Alles googeln hatte da bisher wenig Erfolg.

Richtig, für Wolf/Weishaupt gibts es derzeit keine aktiv gepflegten CSVs.
Wenn Du magst kann ich Dich dabei unterstützen.
VG John

[Thomas3025]

Hallo johnm,

vielen Dank für die schnelle Antwort und ganz allgemein danke für die viele Mühe, die Du Dir um das Thema machst.

heute habe ich mal wieder den gazen Abend damit verbracht, meiner Heizung wertvolle Infos zu entlocken, leider wieder mit eher bescheidenem Erfolg.

Begonnen habe ich damit, die Ebus-Leitung zu kürzen. Ich verwende ein normales KNX-Kabel. Jetzt hat es noch eine Länge von ca. 20 cm. Danach ging es wieder los, das Signal abzugleichen.
Außerdem habe ich den Log Level auf debug gestellt. Wirklich krass war das von der Menge der Aufzeichnungen nicht.

Im Prinzip kamen immer wieder die folgenden Zeilen:

2015-12-23 15:07:13.410 [main debug] performing regular tasks
2015-12-23 15:07:23.410 [main debug] performing regular tasks
2015-12-23 15:07:33.411 [main debug] performing regular tasks
2015-12-23 15:07:34.509 [bus debug] ERR: read timeout during ready, switching to skip
2015-12-23 15:07:36.845 [bus debug] ERR: read timeout during receive command, switching to skip
2015-12-23 15:07:43.411 [main debug] performing regular tasks
2015-12-23 15:07:53.412 [main debug] performing regular tasks
2015-12-23 15:07:59.575 [bus debug] ERR: read timeout during ready, switching to skip
2015-12-23 15:08:03.412 [main debug] performing regular tasks
2015-12-23 15:08:06.908 [bus debug] ERR: read timeout during receive command, switching to skip
2015-12-23 15:08:13.412 [main debug] performing regular tasks
2015-12-23 15:08:23.413 [main debug] performing regular tasks
2015-12-23 15:08:24.634 [bus debug] ERR: read timeout during ready, switching to skip
2015-12-23 15:08:33.413 [main debug] performing regular tasks
2015-12-23 15:08:36.857 [bus debug] ERR: read timeout during receive command, switching to skip
2015-12-23 15:08:43.414 [main debug] performing regular tasks
2015-12-23 15:08:49.686 [bus debug] ERR: read timeout during ready, switching to skip
2015-12-23 15:08:53.414 [main debug] performing regular tasks

Alle 30 Sekunden kam dann wieder das Telegramm (oder zumindest so ähnlich) wie gestern:

2015-12-23 15:58:13.545 [update info] update BC cmd: f1fe500a0d01004702006c74ff008090f408
2015-12-23 15:58:13.545 [update notice] unknown BC cmd: f1fe500a0d01004702006c74ff008090f408

Nach einer Weile habe ich mal die Schornsteinfeger-Funktion aktiviert. Dann kam auch das zuvor genannte Telegramm nicht wieder. Selbst, als der Kessel wieder in den Normalbetrieb gewechselt hat, kamen keine Telegramme mehr über den Bus.

Das Einzige, was ich bislang auf den Bus gesendet habe, wozu ich eine Antwort erhalten habe war der manuelle Scan von Adresse 08:

(2015-12-23 22:36:23.890 [main debug] >>> read -h 08070400
2015-12-23 22:36:23.890 [main notice] hex read cmd: ff08070400
2015-12-23 22:36:23.890 [main notice] hex read scan ident from cache
2015-12-23 22:36:23.890 [main debug] <<< 0a50570f000f0d03150301
2015-12-23 22:36:23.891 [network info] [00042] connection closed
2015-12-23 22:36:24.890 [network debug] dead connection removed - 0

Normalerweise müsste doch bei read -h keine -csv-Datei vorhanden sein, oder hab ich da einen Denkfehler?

Das Angebot mit der Unterstützung für die .csv-Datei für Weishaupt nehme ich natürlich gerne an (wenn alles andere mal läuft bzw. von mir verstanden ist)

Grüße

Thomas