@Jumi: Ich habe auch schon dran gedacht, aber das alleine hilft nicht, wenn ebusd ein USB-Device die ganze Zeit offen hält. ebusd müsste erkennen, dass ein USB-Device nicht mehr funktioniert und es neu öffnen. Deswegen meine Frage an yuhu.
-
-
Geöffnet wird mit sfd = open(dev, O_RDWR | O_NOCTTY | O_NDELAY); beim Start des Daemons.
Der Zugriff erfolgt mit *buflen = read(sfd, buf, *buflen); bzw. val = write(sfd, buf, buflen);
Die Werte von *buflen und val werden auf Negativ geprüft.
Wenn der FD ungültig wird sollte das mit einer negativen Rückmeldung quittiert werden.
EDIT:
Es wäre sicher möglich vor jedem Zugriff das serielle Device neu zu öffnen und dann wieder zu schließen.
Wie bekommt der Daemon jedoch mit, dass sich das Device von ttyUSB0 auf ttyUSB1 geändert hat?
Da hat die Fritzbox wohl einen FehlerKommentar
-
Das denke ich mittlerweile nicht, siehe die Links zu Diskussionen bei Google-Groups. Das Problem mit dem ttyUSB-Hopping ist nicht Fritzbox-spezifisch.Da hat die Fritzbox wohl einen Fehler
Das kann ebusd natürlich nicht. ebusd soll IMHO erkennen können, wenn ein USB-Device plötzlich nicht mehr funktioniert, z.B. wenn Lese/Schreib-Versuche mit einem Timeout zurückkommen. Dann das Device schließen und neu öffnen. Kann das so funktionieren?Wie bekommt der Daemon jedoch mit, dass sich das Device von ttyUSB0 auf ttyUSB1 geändert hat?Kommentar
-
Was ist der Grund für das Hopping?Zitat von aloz77 Beitrag anzeigen
Wenn das Device sich verändert hat, wird ein neu öffnen auch schiefgehen.Zitat von aloz77 Beitrag anzeigenKommentar
-
Kannst Du das reproduzieren? Den ebusd mit Loglevel ALL laufen lassen. Mich würde interessieren, ob da was ins Logfile kommt.Kommentar
-
Eine andere Möglichkeit wäre das Device einfach by-id anzugeben.
/dev/ttyUSB0 ist nichts anders als ein "symlink"
Am Raspberry sieht das zb so aus.
root@raspberrypi:/# ls -l /dev/serial/by-id/usb-E-Service_Online_eBus_Coupler_Iso_AHVPBDW5-if00-port0
lrwxrwxrwx 1 root root 13 Jän 1 1970 /dev/serial/by-id/usb-E-Service_Online_eBus_Coupler_Iso_AHVPBDW5-if00-port0 -> ../../ttyUSB0Kommentar
-
Das stimmt natürlich. Das sich ändernde Device lässt sich durch eine udev-Regel oder wie du schreibst durch Ansprache by ID vermeiden. Laut den Infos in den Diskussionen, die ich heute gepostet habe, hilft das alleine aber nicht, wenn sich ein USB-Gerät (warum auch immer) trennt und wiederverbindet. Der Dämon kann in so einem Fall nicht mehr auf das Device zugreifen, wenn er sich nicht mit dem neuen Device (auch wenn unter dem gleichen Namen!) wiederverbindet.Wenn das Device sich verändert hat, wird ein neu öffnen auch schiefgehen.
Wie ist es bei euch? Wenn ihr das USB-Kabel vom Converter kurz abzieht und wieder einsteckt, funktioniert ebusd weiter?Kommentar
-
Das habe ich noch nie getestet. Funktioniert das bei Dir?Zitat von aloz77 Beitrag anzeigenKommentar
-
Nein, bei mir funktioniert das nicht. Ich habe jedoch noch nicht das Problem des veränderlichen Device-Namens nicht gelöst. Nachdem, was ich gelesen habe, soll es bei euch auch bei einem gleichbleibenden Device-Namen nicht gehen.
Es sieht bei mir beim Abziehen und Wiederverbinden des USB-Kabels so aus:
Merkt ebusd im Betrieb nicht, dass das USB-Device nicht mehr funktioniert? Hast du eine Idee, ob/wie man das nachrüsten kann? Ich denke, das wäre für den stabilen Betrieb des Dämons sehr sehr wichtig, dass man mitbekommt, dass die Hardware nicht läuft.2013-05-05 20:00:02.079 [DBG] id: 2 elem: 1 p1: 3 p2: 0 p3: 0
2013-05-05 20:00:02.079 [DBG] id: 2 elem: 2 p1: 4 p2: 0 p3: 0
2013-05-05 20:00:02.079 [EBS] 0 10.00 0
2013-05-05 20:00:02.382 [EBH] 10 08 b5 09 03 29 0f 00 56 00 05 0f 00 25 01 00 dd 00
2013-05-05 20:00:02.383 [NOT] found: 08B50903290F00 type: 3 ==> id: 8
2013-05-05 20:00:02.383 [DBG] id: 8 elem: 0 p1: 3 p2: 4 p3: 0
2013-05-05 20:00:02.383 [DBG] id: 8 elem: 1 p1: 5 p2: 0 p3: 0
2013-05-05 20:00:02.383 [EBS] 18.3125 0
<!-- Vermutlich hier hab ich irgendwann gezogen und wieder eingesteckt -->
2013-05-05 20:00:40.774 [NET] client [4] from 127.0.0.1 connected.
2013-05-05 20:00:40.774 [NET] >>> client [4] get amu wp_stat
2013-05-05 20:00:40.775 [NOT] search: get amu.wp_stat
2013-05-05 20:00:40.775 [NOT] found: 08B509030DD000 type: 3 ==> id: 56
2013-05-05 20:00:40.775 [NOT] data: -
2013-05-05 20:00:40.775 [DBG] add: id: 56 clientfd: 4 ==> entries: 1
2013-05-05 20:00:45.841 [NET] client [4] disconnected.Kommentar
-
Tja, ich habe wie immer keine Ahnung wie ich sowas implementieren kann.
Die Endlosschleife verwendet select() zur Überwachung der File Descriptoren. (Seriell + Netzwerk).
Hat jemand eine Idee?Kommentar
-
Teste mal die aktuelle Version im SVN. Added function checks whether the FD is still a valid serial device.Kommentar
-
Super, das teste ich morgen. Ich hätte vorgeschlagen, mit ioctl() zu testen, ob ein serielles Device noch lebt. Das scheint gut zu erkennen, wenn ein USB-Device abgezogen wird, ich bin jedoch nicht sicher, ob das die anderen Funktionen stören könnte.
if (ioctl(fd, TIOCMGET, &serial)<0)
{ // fd lebt nicht mehr
}Kommentar
-
ich habe sowas im netz gefunden.
int
eb_serial_valid()
{
return fcntl(sfd, F_GETFD) != -1 || errno != EBADF;
}Kommentar
-
Hmm, habe die aktuelle Version von ebusd ausprobiert. Wenn ich ebusd mit -l ALL laufen lasse und dann USB abziehe, bleibt die Logdatei einfach stehen. Keine Fehlermeldung. :-(
Bist du sicher, dass die Prüfung mit eb_serial_valid() nicht in main_loop() reinsoll? Nach meinem Verständnis bleibt ebusd dort im Loop einfach hängen, wenn am Socket nichts mehr passiert.Kommentar
-
Du hast recht. :/
Somit müsste das serielle Device aber zyklisch (timer) getestet werden.
EDIT:
Oder mit dem timeout von select() ein max. Wartezeit einführen und somit ständig testen.Kommentar
Kommentar