eBus Schaltung V2 in Betrieb nehmen

[minscof]

set the Jumper on the Uart to 3,3V!

LG

Thanks, does  it mean the 5V pin is useless, or do I have to connect it as well ?

[Reinhart]

Yes, the 5V Pin is useless!

LG

[john30]

Ich habe folgende Dateien und Ordner in /etc/ebusd per Hand aus /etc/ebusd.old/ebusd-configuration/ebusd-2.1.x/de kopiert um sicher zu sein, dass diese in dem Ordner vorhanden sind:

• /etc/ebusd/vaillant (Ordner)
• /etc/ebusd/_templates.csv
• /etc/ebusd/broadcast.csv
• /etc/ebusd/memory.csv

Irgendwas stimmt damit aber nicht, denn Dein checkconfig zeigt ja folgendes:

2018-03-10 21:34:59.882 [main notice] found messages: 10 (0 conditional on 0 conditions, 0 poll, 7 update)

Und das sollten nicht 10 sondern mehrere 1000 sein.

Oder müssen diese in dem Unterordner de liegen, sprich /etc/ebusd/de/vaillant usw.?

Die Ordnerstruktur stimmt so. Als welcher User lässt Du denn den --checkconfig laufen? Vielleicht hat der nicht genügend Rechte.

Mein Regler ist ein Calormatic 470. Dafür sollte doch eigentlich eine CSV vorhanden sein. Sind ja etliche mit demselben Regler hier unterwegs.

Ja das ist richtig, aber Dein 470 erscheint auch nicht beim in der info Ausgabe...

[Reinhart]

die Verzeichnisstruktur sollte so aussehen!

LG

[dkreutz]

Hallo John,

also hier geht einfach grundsätzlich was völlig schief, denn es versucht F1 sich selbst zu scannen. Das macht nun so gar keinen Sinn.
Das ist ebenso bizarr, denn nach dem SYN möchte ebusd was senden, bekommt auch seine Adresse zurück, aber mit deutlicher Latenz von 13ms. Dass hier ansonsten nichts protokolliert wird, ist auch merkwürdig. Zumindest eine Meldung über Timeout o.ä. müsste da schon kommen. Sicher, dass die Log Einstellungen angepasst wurden?

Anyway, versuch mal, ebusd mit zusätzlichem Startparameter --latency=20000 zu starten. Damit lässt sich die Latenzproblematik zumindest mal temporär umschiffen.

Ich habe ein Log angehängt, das mit folgender Konfiguration erstellt worden ist:

Code Auswählen Erweitern

EBUSD_OPTS="-d /dev/serial/by-id/usb-Silicon_Labs_CP2102N_{...}-if00-port0 -p 8888 -l /var/log/ebusd.log  --scanconfig --lograwdata=bytes --loglevel=info --latency=20000"


VG Dominik

[Allodo]

@Reinhart
Danke, genau so sieht meine Verzeichnisstruktur momentan aus.

Habe gerade noch einmal ebusd --checkconfig --scanconfig eingegeben, dabei wird folgendes ausgespuckt:

Code Auswählen Erweitern

pi@fhem:~ $ ebusd --checkconfig --scanconfi
2018-03-12 19:59:15.028 [main notice] ebusd 3.1.v3.1-22-gdaf771e performing configuration check...
/etc/ebusd/vaillant/ed.pms.sc.csv:1: ERR: end of input reached, missing message type/name/pbsb
2018-03-12 19:59:15.120 [main error] error reading config files: ERR: end of input reached, last error: /etc/ebusd/vaillant/ed.pms.sc.csv:1: ERR: end of input reached, missing message type/name/pbsb
2018-03-12 19:59:15.155 [main notice] found messages: 238 (7 conditional on 6 conditions, 0 poll, 17 update)
2018-03-12 19:59:15.159 [main notice] ebusd stopped


Zumindest schon einmal mehr, als gestern. Kann mit der Meldung aber nix anfangen

EDIT: Ich habe gerade noch einmal die Erweiterungsplatine abgesteckt und die LED's in die Brückkontakte gesteckt. Es leuchtet nach wie vor nur die Gelbe LED dauerhaft.
Mir ist ja egal, ob die LED's leuchten, oder nicht. Nur sind die ja wohl nicht ohne Grund vorhanden

Könnte evtl. etwas mit der Platine selbst nicht stimmen, oder ist das auf Grund der Übertragung auszuschließen?

Wenn ich auf das Webinterface des WEMOS gehen, steht dort "ebusd connected: yes (inactive)" und "eBUS signal: acquired"
Sollte dort inactive stehen?

Code Auswählen Erweitern

pi@fhem:~ $ ebusctl find
broadcast datetime = no data stored
broadcast error = no data stored
broadcast id = no data stored
broadcast id = no data stored
broadcast signoflife = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan.08  = Vaillant;V3x00;0118;9902
scan.15  = no data stored


[Reinhart]

@Allodo

bei dir stimmt nach wie vor mit der Installation der CSV Fles was nicht!

Code Auswählen Erweitern

pi@raspberrypi:~ $ ebusd --checkconfig
2018-03-12 21:41:21.123 [main notice] ebusd 3.1.v3.1-22-gdaf771e performing configuration check...
2018-03-12 21:41:29.949 [main notice] found messages: 11126 (437 conditional on 154 conditions, 17 poll, 63 update)
2018-03-12 21:41:30.258 [main notice] ebusd stopped

so sollte in etwa der checkconfig ausehen, aber du hast stattdessen "ERR: end of input reached" an Fehlermeldungen.
Hast du vielleicht die Files einmal mit einem Windows Editor geändert und gespeichert, denn dann wären sie hin?

[Allodo]

Nein, ich habe sie mittels putty von dem einen Ordner in den anderen kopiert, nix editiert o.ä.

In dem File steht (jetzt aus dem Kopf heraus) nur eine Adresse zu einer anderen Datei.

Vielleicht komme ich heute dazu, mal auf einem anderen Raspi ebusd komplett neu zu installieren. Mal schauen, was dann passiert. Werde dann mal aus Github alles direkt herunterladen und auf dem Raspi entsprechend kopieren.

Übrigens hat beim starten gestern einmal die rote LED ganz schwach aufgeleuchtet. Hatte das bei der Beleuchtung gar nicht gesehen
Die grüne ist nach wie vor aus. Aber, wie gesagt, wenn ansonsten die Platine laufen sollte kann ich das sehr gut verschmerzen.

[Reinhart]

OK, ändert aber nichts das die CSV nicht passen. Ist eine gute Idee einmal alles auf einem anderen Raspi zu installieren.
Mit Putty über SSH zu kopieren ist ok.

Die rote Led sollte blinken (sofern das deine Tx Led ist), wenn ein Full Scan oder der Initialscan läuft. Wenn das nicht der Fall ist, dann ist sie falsch gepolt und dann kann auch nichts gesendet werden. Warum die Leds bei dir so schwach leuchten kann ich nicht sagen. Aber die Rx Led muss unbedingt blinken sobald der eBus angeschlossen ist, Polung?

Ich habe hier ein kurzes Video damit du siehst wie das blinken soll, rot=Rx, gelb=Tx, grün=Power.

LG

[Allodo]

Gibt es irgendeine Möglichkeit die Platine ohne Labornetzteil durchzumessen?
Ich könnte max ein PC-Netzteil anschließen, welches ja 12V liefert.

[Reinhart]

die Messpunkte Messplan wurden alle bei 17 Volt erstellt um möglichst nahe an die Busspannung zu kommen.
Bei 12V werden die Messwerte nicht passen.

Ich glaube aber nicht, dass deine Platine was hat, das ist nur Konfigurationssache.

LG

[galileo]

Gibt es irgendeine Möglichkeit die Platine ohne Labornetzteil durchzumessen?
Ich könnte max ein PC-Netzteil anschließen, welches ja 12V liefert.

12V sind sicher zu wenig um ein eindeutiges "HIGH" zusammenzubringen.
Nimm doch einfach 2 Stück 9V Batterien in Serie, dann hast du 18V (statt der 17V im Messplan).
Damit sollten sich nur unwesentlich andere Messwerte ergeben. Für eine Fehlersuche wird es allemal reichen.
330 Ohm Widerstand nicht vergessen!

LG
Eduard

[john30]

Ich habe ein Log angehängt, das mit folgender Konfiguration erstellt worden ist:

Code Auswählen Erweitern

EBUSD_OPTS="-d /dev/serial/by-id/usb-Silicon_Labs_CP2102N_{...}-if00-port0 -p 8888 -l /var/log/ebusd.log  --scanconfig --lograwdata=bytes --loglevel=info --latency=20000"


also der Slave f6 mag nicht auf die ID Anfrage antworten und schert sich offensichtlich auch sonst kaum um Einhaltung des eBUS Protokolls. Des weiteren sendet der (oder noch ein anderer Teilnehmer) anscheinend beliebig 0x00 auf den Bus, was ebenfalls nicht dem Protokoll entspricht.
Das sieht für mich leider immer noch so aus, als würde der Teilnehmer nicht eBUS sondern irgendwas anderes sprechen...
Was hängt denn da noch alles an dem Bus dran?

[Allodo]

Es ist zum Mäuse melken, ich habe ebusd jetzt mal auf einem anderen Rpi2 installiert. Vorher Stretch komplett neu aufgesetzt.
Habe mich an das WIKI gehalten und selbst compiliert. Anschließend habe ich die Konfigurationsdateien (*.csv) per ssh nach /etc/ebusd kopiert.

Es wird immer noch nix geladen bzw ebusd --checkconfig --scanconfig ergab dieses Mal ein Error Reading bei 15.360.csv.

Also habe ich alle Dateien und den Vaillantordner unter /etc/ebusd wieder gelöscht und wie in Github von John beschrieben folgende Befehle ausgeführt:

Code Auswählen Erweitern

git clone https://github.com/john30/ebusd-configuration.git
sudo ln -s $PWD/ebusd-configuration/ebusd-2.1.x/de /etc/ebusd

War auch nicht wirklich von Erfolg gekrönt, nur dass ich jetzt folgende Ordnerstruktur habe:  /etc/ebusd/de/vaillant.

Habe dann gestern Abend die Platine abgeklemmt und zumindest die Widerstände gemessen, die passten soweit. Hatte nur bei einigen merkwürdige Messwerte.
Zum Beispiel bei R3 habe ich je nachdem, wie ich die Messpitzen anlege, entweder 100k Ohm oder einen anderen Wert. Sollte die Richtung des Widerstandes nicht egal sein?

Problematischer ist es bei R7, R8, R12, R9, da bekomme ich nie den richtigen Wert im Multimeter angezeigt. Die Farbcodierung entspricht jedoch den hier eingestellten Bildern.
Heute Nachmittag werde ich dann mal 2x9V-Blöcke in Serie anklemmen (@Galileo Danke für den Tipp) und dann messen. Sind die Messpunkte der V2 identisch mit der V2.1?

Die Belegung der Widerstände auf der Basisplatine sollte doch so sein, wie im angehangenen Bild, oder?

[john30]

Also habe ich alle Dateien und den Vaillantordner unter /etc/ebusd wieder gelöscht und wie in Github von John beschrieben folgende Befehle ausgeführt:

Code Auswählen Erweitern

git clone https://github.com/john30/ebusd-configuration.git
sudo ln -s $PWD/ebusd-configuration/ebusd-2.1.x/de /etc/ebusd

War auch nicht wirklich von Erfolg gekrönt, nur dass ich jetzt folgende Ordnerstruktur habe:  /etc/ebusd/de/vaillant.

das ist so nicht richtig, weil Du das zweite Kommando unterschlagen hast:

Code Auswählen Erweitern

if [ -d /etc/ebusd ]; then sudo mv /etc/ebusd /etc/ebusd.old; fi