eBus Schaltung in Betrieb nehmen

[dfhome]

Hallo zusammen,

ich steh hier noch ganz am Anfang und hab nun meinen Adapter fertig gelötet. Nun aber eine kurze Frage zum Anschluss an den empfohlenen USB-Adapter: ist die Belegung der PINS am USB-Adapter genau wie im Schaltplan im WIKI angegeben? Also VDD an PIN1, RX an PIN3, GND an PIN5 und TX an PIN6 (PIN´s von oben gezählt)? Denn laut der Beschreibung des USB-Adapters ist dessen PIN-Belegung etwas anders.

Gruß & Danke für eine kurze Info,
dfhome

[Prof. Dr. Peter Henning]

Natürlich muss man die konkrete Pinbelegung des eigenen Adapters nehmen !

LG

pah

[dfhome]

Hallo pah,
Danke für deine Antwort; ich hab ja den EL*-Mini-USB-Adapter, welchen Du in den Schaltplänen im WIKI eingezeichnet hast. Frage ist, ob Du den Anschluss symbolisch eingezeichnet hast oder ob die Pfeile der Kästchen konkret auf den jeweiligen Pin gehen.
Aber dann leg ich mal RX auf RX, TX auf TX, VDD auf +5V und GND an GND und schaue, was passiert. Danke. 

Gruß
dfhome

[dfhome]

Hallo zusammen,

hab jetzt mal alles angeschlossen und eingestellt.
Ein "ebusd scan full" liefert:

Code Auswählen Erweitern


ebusctl scan result
15;Vaillant;SDR_P;0309;6801
23;Vaillant;SDR_P;0309;6801
25;Vaillant;SDR_P;0309;6801
ec;Vaillant;SDR_P;0309;6801


Kann mir kurz einer auf die Sprünge helfen, wie ich jetzt weitermachen muss?
Heißt obiges Ergebnis, dass zumindest mal eine Kommunikation mit meiner Solaranlage (Vaillant auromatic 560/2) stattfindet?

Gruß & Danke,
dfhome

[Prof. Dr. Peter Henning]

Jein. Heißt, dass der ebusd auf dem Bus gelauscht und diese Geräte gefunden hat - jetzt braucht es noch die entsprechenden Konfigurationsdateien, um mit ihnen auch zu reden und sie zu verstehen.

LG

pah

[john30]

hab jetzt mal alles angeschlossen und eingestellt.
Ein "ebusd scan full" liefert:

Code Auswählen Erweitern


ebusctl scan result
15;Vaillant;SDR_P;0309;6801
23;Vaillant;SDR_P;0309;6801
25;Vaillant;SDR_P;0309;6801
ec;Vaillant;SDR_P;0309;6801


es wurde also ein SolarDifferenzRegler_Profi gefunden. Wenn Du ebusd mit "--scanconfig" zusammen mit den 2.1.x config Dateien laufen lässt, dann wird er für dieses Gerät bereits eine Konfiguration finden und Du kannst dann mit z.B. "ebusctl f -c sdr_p" alle bekannten Nachrichten finden, die Du dann mit "read" auch auslesen kannst.

[dfhome]

Hallo zusammen,

Danke für eure Antworten. Hab alles in meinen Verteilerschrank eingebaut, deswegen kommt meine Antwort etwas später.
Wenn ich "ebusd --scanconfig" laufen lasse, dann erscheint im Log nur "2016-06-01 19:48:15.933 [main error] can't open pidfile: /var/run/ebusd.pid" und es passiert nichts weiter...? Auch mit sudo klappt das nicht. Das File selbst ist vorhanden, aber leer.

Kann mir bitte nochmal jemand helfen?

Gruß & Danke,
dfhome

[dfhome]

Guten Morgen an alle,

hab ebusd nochmal neu installiert; jetzt funktioniert alles. Vielen Dank für eure Unterstützung! 
Echt klasse Projekt, Respekt!

Schönen Tag und Gruß
dfhome

[dfhome]

Jetzt hab ich doch noch eine Frage: 

wenn ich den Pi neu starte, dann findet ebusd erstmal keine gültige Konfig. Erst wenn ich "ebusctl scan full" ausführe und ebusd dann darüber die richtige Konfiguration findet, klappt das Abfragen. Ich dachte, mit dem Parameter "--scanconfig" macht ebusd das bei jedem Start von selbst?
Wenn ich vor dem "ebusctl scan full" ein "ebusd --scanconfig --checkconfig" laufen lasse, dann hagelt es nur so vor Fehlermeldungen. Ich hab jetzt schon viel gesucht und hoch und runter gelesen, aber dazu noch keinen Hinweis gefunden.

Gruß & Danke,
dfhome

Edit: nochmal etwas anders gefragt: über "ebusctl info" seh ich ja, welches CSV durch den Scan geladen wurde ("/vaillant/15.sdr_p.csv"). Wie kann ich denn jetzt dieses CSV fest an ebusd binden, ohne zuvor einen Scan machen zu müssen?

[john30]

wenn ich den Pi neu starte, dann findet ebusd erstmal keine gültige Konfig. Erst wenn ich "ebusctl scan full" ausführe und ebusd dann darüber die richtige Konfiguration findet, klappt das Abfragen. Ich dachte, mit dem Parameter "--scanconfig" macht ebusd das bei jedem Start von selbst?

Es könnte sein, dass der SDR_P von sich aus gar nichts auf den Bus sendet. Schau doch mal, ob da überhaupt irgendwelche "update" Meldungen im Log stehen, ohne dass Du explizit einen Request startest.
ebusd initiiert derzeit von sich aus keinen Scan (steht aber auf der TODO Liste), weshalb ein CSV erst on demand geladen wird, sobald eine gültige Kommunikation mit oder von dem Gerät stattgefunden hat.

Wenn ich vor dem "ebusctl scan full" ein "ebusd --scanconfig --checkconfig" laufen lasse, dann hagelt es nur so vor Fehlermeldungen. Ich hab jetzt schon viel gesucht und hoch und runter gelesen, aber dazu noch keinen Hinweis gefunden.

Dann müsstest Du mal etwas mehr verraten, denn so kann ich Dir nicht weiterhelfen. Was für Fehlermeldungen genau, mit welchen CVSs?

Edit: nochmal etwas anders gefragt: über "ebusctl info" seh ich ja, welches CSV durch den Scan geladen wurde ("/vaillant/15.sdr_p.csv"). Wie kann ich denn jetzt dieses CSV fest an ebusd binden, ohne zuvor einen Scan machen zu müssen?

Du könntest von scanconfig auf manuell konfiguriert umsteigen. Dazu müsstest Du dann alle anderen CSVs löschen und --scanconfig aus den Startparametern entfernen.

[dfhome]

Hallo john,

also: es ist tatsächlich so, dass meine Vaillant-Steuerung überhaupt nichts von sich aus sendet. Nur auf Anfrage kommt was auf dem ebus zurück.
Das mit dem Löschen der restlichen CSV´s hat auch nicht funktioniert; es kommt dann trotz einem positiven "ebusctl scan full" als Meldung "ERR: Element not found".

Aber ich hab mir jetzt anders geholfen: ich hab mir ein Startup-Skript geschrieben, welches nach einem Reboot automatisch einen Scan startet. Das funktioniert, da ich ja über die "Required-Start"-Tags definieren kann, dass das Skript erst läuft, nachdem ebusd gestartet wurde. Dann funktioniert auch die Abfrage der Werte. Das reicht mir für meine Belange. 

Danke Dir für deine Hilfe und das tolle Programm! 

[john30]

also: es ist tatsächlich so, dass meine Vaillant-Steuerung überhaupt nichts von sich aus sendet. Nur auf Anfrage kommt was auf dem ebus zurück.

ja das dachte ich mir.

Das mit dem Löschen der restlichen CSV´s hat auch nicht funktioniert; es kommt dann trotz einem positiven "ebusctl scan full" als Meldung "ERR: Element not found".

okay, dann hast irgendwas falsch gemacht. aber ist jetzt egal, oder?

Aber ich hab mir jetzt anders geholfen: ich hab mir ein Startup-Skript geschrieben, welches nach einem Reboot automatisch einen Scan startet. Das funktioniert, da ich ja über die "Required-Start"-Tags definieren kann, dass das Skript erst läuft, nachdem ebusd gestartet wurde. Dann funktioniert auch die Abfrage der Werte. Das reicht mir für meine Belange. 

dann ists ja gut

VG John

[Franky1992]

Hallo

ich versuche nun schon eine weile meinen Ebusadapter in Betrieb zu nehmen und damit eine WOLF CWL 400 excellent zu steuern.

Ich komme jedoch nicht weiter da ich nicht ganz eindeutig finde ob die Busverbindung funktioniert.

Ich habe wen ich mir die ebusd rawDaten anzeigen lasse die gewünschten aa und scheinbar eine saubere Verbindung.

jedoch sieht das Log so aus:

Code Auswählen Erweitern

2016-06-23 11:33:18.299 [update info] update BC cmd: 77fefe010a45313131202020202020
2016-06-23 11:33:18.299 [update notice] update broadcast error QQ=77: E111     
2016-06-23 11:33:18.506 [main debug] performing regular tasks
2016-06-23 11:33:20.345 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:33:25.362 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:33:28.506 [main debug] performing regular tasks
2016-06-23 11:33:28.982 [bus debug] ERR: read timeout during ready, switching to skip
2016-06-23 11:33:30.340 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:33:35.348 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:33:38.507 [main debug] performing regular tasks
2016-06-23 11:33:40.362 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:33:45.379 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:33:48.508 [main debug] performing regular tasks
2016-06-23 11:33:50.396 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:33:55.415 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:33:56.038 [bus debug] ERR: read timeout during ready, switching to skip
2016-06-23 11:33:58.508 [main debug] performing regular tasks
2016-06-23 11:33:59.034 [bus debug] ERR: read timeout during ready, switching to skip
2016-06-23 11:34:00.390 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:34:05.397 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:34:08.509 [main debug] performing regular tasks
2016-06-23 11:34:10.414 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:34:15.430 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:34:18.509 [main debug] performing regular tasks
2016-06-23 11:34:20.448 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:34:25.467 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:34:28.510 [main debug] performing regular tasks


ebusctl info gibt folgendes aus:

Code Auswählen Erweitern



Version: ebusd 2.1.086dea5
Signal: accuired
Symbol rate: 22
masters: 2
Messages: 12
address 31: master #8, ebusd
address 36: slave #8
address 77: master #19


ebusctl scan full wird mit "done" abeschlossen
ebusctl scan result zeigt jedoch "empty"

kann mir jemand sagen ob die Verbindung nun sauber steht oder nicht?

Gruß
Franky

[john30]

Ich komme jedoch nicht weiter da ich nicht ganz eindeutig finde ob die Busverbindung funktioniert.

Solange nicht permanent "signal lost" und "signal acquired" im Log auftauchen, ist die Verbindung in Ordnung.

jedoch sieht das Log so aus:

Code Auswählen Erweitern

2016-06-23 11:33:18.299 [update info] update BC cmd: 77fefe010a45313131202020202020
2016-06-23 11:33:18.299 [update notice] update broadcast error QQ=77: E111     
2016-06-23 11:33:18.506 [main debug] performing regular tasks
2016-06-23 11:33:20.345 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:33:25.362 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-06-23 11:33:28.506 [main debug] performing regular tasks
...


Wenn Du natürlich "debug" Logging aktivierst, darfst Dich nicht wundern, dass wirklich viel protokolliert wird.
In obigem Beispiel scheint ein Master einen Slave (oder Master) zu adressieren, der dann aber nicht antwortet, z.B. weil er gar nicht am Bus hängt.
Alternativ könnte noch sein, dass der Adressat sich nicht in der spezifizierten Zeit meldet. Mit dem Parameter "--receivetimeout" kannst Du das austesten. Ein Blick in den raw output zeigt das zeitliche Verhalten.

VG John

[Franky1992]

Hallo John

danke für die Hilfe.

ich habe nun den loglevel auf notice reduziert un es ist schonmal übersichtlicher

Code Auswählen Erweitern


2016-06-23 12:27:07.194 [main notice] ebusd 2.1.086dea5 started
2016-06-23 12:27:07.240 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2016-06-23 12:27:07.300 [bus notice] signal acquired
2016-06-23 12:27:07.571 [bus notice] new master 77, master count 2
2016-06-23 12:27:23.958 [bus error] send to 7c: ERR: read timeout, retry
2016-06-23 12:27:24.019 [bus error] send to 7c: ERR: read timeout, retry
2016-06-23 12:27:24.072 [bus error] send to 7c: ERR: read timeout, retry
2016-06-23 12:27:24.125 [bus error] send to 7c: ERR: read timeout
2016-06-23 12:27:24.125 [main error] scan config 7c message: ERR: read timeout
2016-06-23 12:30:30.746 [update notice] update broadcast ident QQ=77: ENCON;   " ;-;-


Also es scheint Kommunikation auf dem Bus zu geben denn der Fehler E111 ist tatsächlich existent und auch aktuell gesetzt in der Wolf CWL (RH Sensor funktioniert nicht richtig)

Die Wolf cwl kennt mehrere Optionen zur ebus Adresse Master oder Slave 1 - 9
als Master gibt es laut FTDI traffic auf dem ebus als slave ist alles tot!?

Ich starte ebusd mit folgenden params:

Code Auswählen Erweitern


EBUSD_OPTS="-d /dev/ttyUSB0 -p 8888 -l /var/log/ebusd.log --scanconfig --loglevel notice"

wenn ich die Parameter um --receivetimeout ergänze startet der Service nicht mehr!?

Gruß
Franky