eBus Schaltung in Betrieb nehmen

pc1246 · 12 Dezember 2018, 09:11:14

Moin
Da haben wir das Problem. Ich habe mich schon immer gefragt, ob ein in der Therme platzierter Regler wirklich am eBus haengt, bzw. ob es nicht einen zweiten Bus gibt. Kannst Du (Ihr?) den Regler mal rausnehmen und an die Busleitung vom Koppler haengen? Da Du keine Montageplatte (Konsole) hast, wird es etwas schwierig mit dem Anschluss. Ich habe eine Anleitung fuer den Fachhandwerker gefunden: https://www.josefy.at/wp-content/uploads/2017/04/mulitmatic_vrc700_4_fhw.pdf
Auf Seite 5 kann man erkennen, hoffe ich, wo der Bus angeschlossen wird. Sonst kann das auch mal jemand mit Montageplatte schauen, welche Kontakte in der VR700 fuer den Bus sind!?
Gruss Christoph

americanium · 12 Dezember 2018, 09:50:17

Hab kurz die Platine aus der Wärmepumpe ausgebaut auf der der VR700 steckt.
Darauf sind eindeutig mit EBUS gekennzeichnete Leitungen ersichtlich, siehe Anhang.

Hätte schon noch irgendwo die Montageplatten, hatte das Terminal mal im Wohnzimmer, was sich aber als sinnlos herausstellte.

Ich könnte, wenn ich die Montageplatte finde natürlich testen was passiert, wenn ich das VR700 direkt an die Zweidrahtleitung hänge.

EDIT: Gerade direkt an den Bus gehängt, direkt neben dem RPi mit Ebus Modul, keine Besserung, siehe Anlage 2.

pc1246 · 12 Dezember 2018, 10:30:55

Hallo
Danke fuer den schnellen Test! Ok, damit ist meine Theorie hinfaellig.
Dann muessen jetzt die Experten wieder uebernehmen!
Gruss Christoph

Reinhart · 12 Dezember 2018, 11:45:01

generell zu diesen "read timeout", das ist ja nicht unbedingt ein Fehler. Das sagt ja nur aus, das der eBus Dämon eine Sendeanfrage gestellt hat und innerhalb des vorgesehen Zeitfenster keine Antwort bekommen hat. Warum er keine Antwort bekommen hat kann ja mehrere Ursachen haben und da sollte man im Raw Log schauen ob hier was sinnvolles zu sehen ist.

Code Auswählen

--lograwdata=bytes --lograwdatafile=/var/log/ebusdraw.log

Ein Fehler wäre es, wenn immer ein Timeout kommt. Mir fällt aber auch auf, das speziell bei Einsatz eines Reglers der Type 700 das hier öfters vorkommt. Ich kann bei meiner Calormatic 430 abfragen was ich will, da muss ich mich schon sehr bemühen ein Timeout zu produzieren.
Das eBus Protokoll ist leider kein TCPIP und auf exaktes Timing aufgebaut. Wenn nur einer der Busteilnehmer die Spezifikation nicht exakt einhält und zu senden beginnt obwohl er es noch gar nicht darf, dann kann es natürlich sehr leicht zu diesen Timeouts kommen, aber das sieht man dann im Rawlog.
John hat das schon so programmiert, dass er die Zeitfenster exakt einhält und wenn eben keine Antwort kommt dann hat das meist andere Gründe. Natürlich ist es auch möglich, das schlechte Kabel oder Klemmstellen das Signal verzerren und so auch Fehler produziert werden können.

Und man muss auch immer daran denken, je mehr Busteilnehmer sich da am Bus unterhalten desto wahrscheinlicher wird ein "Timeout". Sehr intensiv ist da ein "Full scan", denn der versucht ja die Adressen abzuklappern und das im vollen produktiven Betrieb.

Auf jeden Fall muss man nicht unbedingt Fehler am Adapter suchen wenn der Großteil der Telegramme gelesen werden kann.

LG
Reinhart

Matze_Bln · 12 Dezember 2018, 20:29:46

Ich habe das Log mal erstellt. Damit du einen zeitlichen Anhaltspunkt hast, habe ich dir mal einen Auszug der Abfragen hier aufgelistet.
Was mir aber so auf den ersten (ungeschulten) Blick auffällt ist, dass da scheinbar viel "gequatscht" wird, wenn man Anfragen macht, die fehlschlagen

Code Auswählen


[19:50:00] openhabian@openHABianPi:/etc/default$ ebusctl read -f YieldTotal
0

[19:50:11] openhabian@openHABianPi:/etc/default$ ebusctl read -f DisplayedOutsideTemp
1.0625

[19:51:00] openhabian@openHABianPi:/etc/default$ ebusctl read -f MaintenanceDue
ERR: read timeout

[19:51:22] openhabian@openHABianPi:/etc/default$ ebusctl read -f MaintenanceDue
ERR: read timeout

americanium · 12 Dezember 2018, 22:14:33

So bezüglich meinem MQTT Problem:

Habe jetzt einfach aus dem git ebusd nochmal drüber installiert, keine Veränderung des Problem... hat John noch irgend eine Idee für mich ? *bettel*

Ich habe nun noch folgendes probiert.

apt-get remove ebusd
rm -r ebusd

dann nochmal mit sudo dpkg -i temp/ebusd-3.2_armhf-jessie_mqtt1.deb das ding installiert
Die Ebusd wieder wie gehabt konfiguriert...

Kein Erfolg - die Broadcasts kommen am MQTT Server an, aber auf meine "Anfragen" wird nicht reagiert.

Vielleicht hilft das noch

Code Auswählen

loxberry@loxberry:~ $ mosquitto_sub -d -v -t \#
Client mosqsub/1599-loxberry sending CONNECT
Client mosqsub/1599-loxberry received CONNACK
Client mosqsub/1599-loxberry sending SUBSCRIBE (Mid: 1, Topic: #, QoS: 0)
Client mosqsub/1599-loxberry received SUBACK
Subscribed (mid: 1): 0
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/700/DisplayedOutsideTemp/get', ... (33 bytes))
loxberry/700/DisplayedOutsideTemp/get ebusctl r -f DisplayedOutsideTemp
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (2 bytes))
loxberry/global/uptime 76
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/broadcast/vdatetime', ... (75 bytes))
loxberry/broadcast/vdatetime {
     "time": {"value": "22:41:10"},
     "date": {"value": "12.12.2018"}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/broadcast/outsidetemp', ... (34 bytes))
loxberry/broadcast/outsidetemp {
     "temp2": {"value": -1.812}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/hmu/DateTime', ... (147 bytes))
loxberry/hmu/DateTime {
     "dcfstate": {"value": "valid"},
     "btime": {"value": "22:41:12"},
     "bdate": {"value": "12.12.2018"},
     "temp2": {"value": -1.812}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (2 bytes))
loxberry/global/uptime 92
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 108
Client mosqsub/1599-loxberry sending PINGREQ
Client mosqsub/1599-loxberry received PINGRESP
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/700/HwcOpModep/get', ... (22 bytes))
loxberry/700/HwcOpModep/get ebusctl r -f HwcOpMode
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 124
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/700/HwcOpModep/get', ... (22 bytes))
loxberry/700/HwcOpModep/get ebusctl r -f HwcOpMode
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/hmu/Status01', ... (271 bytes))
loxberry/hmu/Status01 {
     "0": {"name": "temp1", "value": 33.0},
     "1": {"name": "temp1", "value": 27.5},
     "2": {"name": "temp2", "value": -1.812},
     "3": {"name": "temp1", "value": null},
     "4": {"name": "temp1", "value": 21.0},
     "5": {"name": "pumpstate", "value": "on"}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 140
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/broadcast/vdatetime', ... (75 bytes))
loxberry/broadcast/vdatetime {
     "time": {"value": "22:42:10"},
     "date": {"value": "12.12.2018"}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/hmu/DateTime', ... (147 bytes))
loxberry/hmu/DateTime {
     "dcfstate": {"value": "valid"},
     "btime": {"value": "22:42:12"},
     "bdate": {"value": "12.12.2018"},
     "temp2": {"value": -1.812}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/700/HwcOpModep/get', ... (22 bytes))
loxberry/700/HwcOpModep/get ebusctl r -f HwcOpMode
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 156
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 172
Client mosqsub/1599-loxberry sending PINGREQ
Client mosqsub/1599-loxberry received PINGRESP
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/700/HwcOpModep/get', ... (14 bytes))
loxberry/700/HwcOpModep/get r -f HwcOpMode
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 188
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/700/HwcOpMode/get', ... (14 bytes))
loxberry/700/HwcOpMode/get r -f HwcOpMode
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/hmu/DateTime', ... (147 bytes))
loxberry/hmu/DateTime {
     "dcfstate": {"value": "valid"},
     "btime": {"value": "22:43:14"},
     "bdate": {"value": "12.12.2018"},
     "temp2": {"value": -1.812}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/broadcast/vdatetime', ... (75 bytes))
loxberry/broadcast/vdatetime {
     "time": {"value": "22:43:10"},
     "date": {"value": "12.12.2018"}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 204
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/700/HwcOpMode/get', ... (22 bytes))
loxberry/700/HwcOpMode/get ebusctl r -f HwcOpMode
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 220
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/700/HwcOpMode/get', ... (22 bytes))
loxberry/700/HwcOpMode/get ebusctl r -f HwcOpMode
Client mosqsub/1599-loxberry sending PINGREQ
Client mosqsub/1599-loxberry received PINGRESP
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 236
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 252
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/broadcast/vdatetime', ... (75 bytes))
loxberry/broadcast/vdatetime {
     "time": {"value": "22:44:11"},
     "date": {"value": "12.12.2018"}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/hmu/DateTime', ... (147 bytes))
loxberry/hmu/DateTime {
     "dcfstate": {"value": "valid"},
     "btime": {"value": "22:44:13"},
     "bdate": {"value": "12.12.2018"},
     "temp2": {"value": -1.812}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 268
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 284
Client mosqsub/1599-loxberry sending PINGREQ
Client mosqsub/1599-loxberry received PINGRESP
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 300
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 316
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/hmu/DateTime', ... (147 bytes))
loxberry/hmu/DateTime {
     "dcfstate": {"value": "valid"},
     "btime": {"value": "22:45:13"},
     "bdate": {"value": "12.12.2018"},
     "temp2": {"value": -1.812}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/broadcast/vdatetime', ... (75 bytes))
loxberry/broadcast/vdatetime {
     "time": {"value": "22:45:11"},
     "date": {"value": "12.12.2018"}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 332
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 348
Client mosqsub/1599-loxberry sending PINGREQ
Client mosqsub/1599-loxberry received PINGRESP
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 364
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 380
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/broadcast/vdatetime', ... (75 bytes))
loxberry/broadcast/vdatetime {
     "time": {"value": "22:46:12"},
     "date": {"value": "12.12.2018"}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/hmu/DateTime', ... (147 bytes))
loxberry/hmu/DateTime {
     "dcfstate": {"value": "valid"},
     "btime": {"value": "22:46:14"},
     "bdate": {"value": "12.12.2018"},
     "temp2": {"value": -1.812}}
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 396
Client mosqsub/1599-loxberry received PUBLISH (d0, q0, r0, m0, 'loxberry/global/uptime', ... (3 bytes))
loxberry/global/uptime 412
Client mosqsub/1599-loxberry sending PINGREQ
Client mosqsub/1599-loxberry received PINGRESP

john30 · 13 Dezember 2018, 08:28:38

Zitat von: americanium am 12 Dezember 2018, 22:14:33
Kein Erfolg - die Broadcasts kommen am MQTT Server an, aber auf meine "Anfragen" wird nicht reagiert.

stell doch mal ebusd auf debug log level ein, starte den nochmal neu, warte bis ebusd alles gescannt hat, mache die Abfrage via MQTT publish und poste dann das log oder schick es mir direkt an ebusd@ebusd.eu

Reinhart · 13 Dezember 2018, 14:43:36

@Matze_Bln

Das Log hast du gut gemacht. Ich habe es mir durchgesehen und sehe eigentlich keinen ersichtlichen Grund warum das Wartungsdatum in ein Timeout fällt.

Code Auswählen

r,,DisplayedOutsideTemp,Außentemperatur,,,,7300,,,tempv,,,Außentemperatur
[19:50:11] openhabian@openHABianPi:/etc/default$ ebusctl read -f DisplayedOutsideTemp
1.0625

2018-12-12 19:50:11.362 <aa 
2018-12-12 19:50:11.406 <aa 
2018-12-12 19:50:11.449 <aa   # Syn vom Bus
2018-12-12 19:50:11.452 >31   # Adapter will senden
2018-12-12 19:50:11.457 <31   # vom Masster bestätigt, Adapter darf senden
2018-12-12 19:50:11.462 >15   # Adapter sendet nun seine Anfrage
2018-12-12 19:50:11.468 <15 
2018-12-12 19:50:11.472 >b5 
2018-12-12 19:50:11.478 <b5
.......
2018-12-12 19:50:11.622 <00  # fertig, alles empfangen
2018-12-12 19:50:11.632 >aa  # Adapter gibt Bus wieder frei, Dauer 180 msec

hier die Abfrage der Aussentemperatur, die auch erfolgreich war

Code Auswählen

r,,MaintenanceDue,Wartung fällig,,,,9600,,,yesno,,,zeigt an ob die Wartung fällig ist
[19:51:00] openhabian@openHABianPi:/etc/default$ ebusctl read -f MaintenanceDue
ERR: read timeout

2018-12-12 19:51:00.117 <aa  # Syn vom Bus
2018-12-12 19:51:00.120 >31  # Adapter will senden
2018-12-12 19:51:00.125 <31  # vom Master bestätigt, Adapter darf senden
2018-12-12 19:51:00.129 >15  # Adapter sendet nun seine Anfrage
2018-12-12 19:51:00.134 <15 
2018-12-12 19:51:00.137 >b5 
2018-12-12 19:51:00.143 <b5 
2018-12-12 19:51:00.146 >24 
2018-12-12 19:51:00.152 <24 
2018-12-12 19:51:00.155 >06 
2018-12-12 19:51:00.161 <06 
2018-12-12 19:51:00.164 >02 
2018-12-12 19:51:00.170 <02 
2018-12-12 19:51:00.182 >00 
2018-12-12 19:51:00.187 <00 
2018-12-12 19:51:00.191 >00 
........
2018-12-12 19:51:00.335 <00  # fertig, alles empfangen
2018-12-12 19:51:00.341 >aa  # Adapter gibt Bus wieder frei, Dauer 221 msec
2018-12-12 19:51:00.347 <aa  # Bus wieder empfangsbereit, syn werden wieder vom Master gesendet

und hier im Vergleich das Wartungsdatum, welches mit einem Timeout endet. Wieso das so ist kann ich nicht sagen, laut RAW Log war es für mich erfolgreich.

Code Auswählen


2018-12-12 19:51:21.901 <aa 
2018-12-12 19:51:21.906 >31   # Adapter möchte senden und teilt dies dem Bus mit
2018-12-12 19:51:21.955 <aa   # Der Bus versteht die Anfrage nicht und sendet 50 msec später erneut ein syn
2018-12-12 19:51:21.960 >31   # der Adapter wiederholt, weil er noch keine Bestätigung erhalten hat
2018-12-12 19:51:21.965 <31   # diesmal bestätigt der Bus 5 msec später die Sendeanfrage
2018-12-12 19:51:21.969 >15   # und der Adapter legt los
2018-12-12 19:51:21.974 <15 
2018-12-12 19:51:21.979 >b5

hier ist noch eine interessante Stelle, erstmaliger Versuch wird vom Master ignoriert.

Eines was mir auffällt, dein Bus ist ordentlich ausgelastet und es gibt kaum Zeiten wo der Adapter senden darf. Bei mir sind wesentlich mehr Syn ("<aa") zu sehen was mehr Ruhe am Bus bedeutet. Du hast eine sehr geschwätzige Umgebung, wobei ja das meiste von dir produziert wurde.

Vielleicht sieht John hier wo einen Fehler, bzw. kann er uns sagen ob die 221msec noch im Rahmen sind oder der Dämon die Übertragung deshalb vorzeitig beendet hat weil es ihm zu lange gedauert hat.

LG
Reinhart

Matze_Bln · 13 Dezember 2018, 18:12:24

Danke erstmal für die Auswertung. Zumindest die Verkabelung rückt damit wieder etwas aus dem Fokus.
Ein wenig konnte ich mein Problem noch minimieren, indem ich nicht mehr -f sondern -m 10 in der Abfrage verwende, aber eine wirkliche Lösung wäre mir natürlich lieber. Vielleicht sieht john ja wirklich noch etwas.

Reinhart · 13 Dezember 2018, 18:55:17

ja das ist klar, Parameter "m" fragt ja nur den Buffer ab (letzter gespeicherter Wert) und nicht den Bus mit dem aktuellen Wert.
Was du sicher schon probiert hast, sind mit den Timeouts in der Default zu experimentieren. Eventuell kann dir eine Priorisierung noch helfen, indem du dem Adapter die Adresse "01" gibst (sofern die in deinem System frei ist), jetzt hast du ja "31".

LG

Matze_Bln · 13 Dezember 2018, 20:35:18

Der Parameter m gibt aber, soweit ich das verstanden habe, den wert aus dem Puffer nur, wenn dieser nicht älter als die angegeben Sekunden ist. In meinem Fall sind das 10 Sekunden, das ist für meinen Anwendungsfall ausreichend.
Mit dem Timeout habe ich auch schon gespielt, das hatte zwar geholfen aber das Problem nicht gelöst.
Die Priorisierung ist aber noch eine gute Idee, nur sehe ich keine freie Adresse, die mir etwas bringt

Code Auswählen


address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=VMS01;SW=0116;HW=0303", loaded "vaillant/06.vms01.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0202;HW=9602", loaded "vaillant/bai.0010015600.inc" ([PROD='0010015609']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address ed: slave

americanium · 13 Dezember 2018, 22:32:09

Zitat von: john30 am 13 Dezember 2018, 08:28:38
stell doch mal ebusd auf debug log level ein, starte den nochmal neu, warte bis ebusd alles gescannt hat, mache die Abfrage via MQTT publish und poste dann das log oder schick es mir direkt an ebusd@ebusd.eu

Siehe Anlage!

Danke!

theotherhalf · 14 Dezember 2018, 19:45:30

Habe heute den Adapter V2.2 an meinen Raspi gehangen.
LEDs blinken, es ist also Leben auf dem Bus.

Bei der Eingabe erhalte ich jedoch diese Meldung:

Code Auswählen

pi@raspberrypi:~ $ ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0
2018-12-14 19:42:36.640 [bus notice] bus started with own address 31/36
2018-12-14 19:42:36.649 [bus notice] signal acquired
2018-12-14 19:42:40.002 [bus error] signal lost
2018-12-14 19:42:40.309 [bus notice] signal acquired
2018-12-14 19:42:58.008 [bus notice] max. symbols per second: 116

ebusctl raw habe ich über ein anderes Fenster eingegeben.

Fehlt etwas in den USB Einstellungen ?

Muss ich an anderer Stelle noch etwas eintragen?

theotherhalf · 14 Dezember 2018, 20:24:17

Als Zusatzinfo:

Code Auswählen

pi@raspberrypi:~ $ sudo dmesg | grep -i tty
[    0.000000] Kernel command line: 8250.nr_uarts=0 bcm2708_fb.fbwidth=1824 bcm2                                      708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_si                                      ze=0x40000000  dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=PARTU                                      UID=da414990-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet                                       splash plymouth.ignore-serial-consoles
[    0.000283] console [tty1] enabled
[    0.733315] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud                                       = 0) is a PL011 rev2
[    3.669241] usb 1-1.5: cp210x converter now attached to ttyUSB0
[    9.830127] Bluetooth: RFCOMM TTY layer initialized

Reinhart · 14 Dezember 2018, 21:31:42

Zitat von: theotherhalf am 14 Dezember 2018, 19:45:30

Code Auswählen Erweitern
pi@raspberrypi:~ $ ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0 2018-12-14 19:42:36.640 [bus notice] bus started with own address 31/36 2018-12-14 19:42:36.649 [bus notice] signal acquired 2018-12-14 19:42:40.002 [bus error] signal lost 2018-12-14 19:42:40.309 [bus notice] signal acquired 2018-12-14 19:42:58.008 [bus notice] max. symbols per second: 116

kommt den "Signal lost" noch öfters im Log, einmal am Anfang spielt soweit keine Rolle. Warum startest du den Dämon im Vordergrund, das ist eigentlich nur zur Unterstützung bei der Fehlersuche gedacht.

Starte doch einmal den Dämon als Service und schaue nach ein paar Minuten mit "ebusctl i" ob deine Geräte erkannt wurden.

LG

LG