Problem mit 'usb create' und JeeLink

[hexenmeister]

Hallo!

Seit ca. 2 Tagen habe ich ein Problem mit dem 'usb create' - Mechanismus. Es funktioniert, braucht aber eine gefühlte Ewigkeit dafür. Als Ergebnis benötigt FHEM drei bis fünf (oder manchmal auch mehr) Minuten zum Start. Die Ursache scheint mein JeeLink zu sein. Wenn ich ihn abziehe, geht alles normal schnell. Auf dem JeeLink ist ein leicht modifizierter Test-Sketch aufgespielt (silent modus und ein anderer String statt 'OK'). Das ist aber schon seit Längeren so, früher gab es keine Störung.
Jetzt scheint die Erkennung irgendwo zu klemmen 
Hat jemand eine Idee?

Log:

Code Auswählen Erweitern


2014.02.08 23:55:52 3: FHZ device opened
2014.02.08 23:55:52 5: SW: OÉ
...
2014.02.08 23:55:52 4: got wrong answer for a FHZ
2014.02.08 23:55:52 4: ### ttyUSB1: checking if it is a TRX
2014.02.08 23:55:52 3: Opening TRX device /dev/ttyUSB1
2014.02.08 23:55:52 3: Setting TRX baudrate to 38400
2014.02.08 23:55:52 3: TRX device opened
2014.02.08 23:55:52 5: SW:
             
2014.02.08 23:55:53 5: SW:
 
         
2014.02.08 23:55:53 4: got wrong answer for a TRX
2014.02.08 23:55:53 4: ### ttyUSB1: checking if it is a ZWDongle
2014.02.08 23:55:53 3: Opening ZWDongle device /dev/ttyUSB1
2014.02.08 23:55:53 3: Setting ZWDongle baudrate to 115200
      >>>>-------------------> hier sieht man die knapp 3-minutige 'Denkpause' --->
2014.02.08 23:55:53 3: ZWDongle device opened
2014.02.08 23:58:42 5: SW:
  Ü
2014.02.08 23:58:42 4: got wrong answer for a ZWDongle
2014.02.08 23:58:42 4: ### ttyUSB1: checking if it is a FRM
2014.02.08 23:58:42 3: Opening FRM device /dev/ttyUSB1
2014.02.08 23:58:42 3: Setting FRM baudrate to 57600
2014.02.08 23:58:42 3: FRM device opened
2014.02.08 23:58:42 5: SW: ù
2014.02.08 23:58:47 5: SW: ðy÷
2014.02.08 23:58:48 4: got wrong answer for a FRM
2014.02.08 23:58:48 1: usb create end
2014.02.08 23:58:48 0: Server started with 264 defined entities (version $Id: fhem.pl 4829 2014-02-07 07:27:47Z rudolfkoenig $, os linux, user fhem, pid 3262)
2014.02.08 23:58:48 1: Perfmon: possible freeze starting at 23:55:17, delay is 211.379


[justme1968]

usb autocreste probiert alle als bekannt konfigurierten geräte durch sobald sich das device öffnen lässt. dabei werden wie du siehst auch unterschiedliche baudraten durchprobiert. wenn das dazu führt das die antwort nicht gelesen werden kann gibt es das delay.

die einzige verbünftige lösung ist wenn du das usb autocreate deaktivierst.

gruss
  andre

[hexenmeister]

Hallo Andre,

danke für die Antwort! Das ist mir soweit schon klar gewesen, die Frage ist, warum das früher nicht aufgetreten ist. Es muss an irgendeiner Änderung in der letzten Zeit liegen. Wäre schon spannend herauszufinden...
geht autocreate nur die ttyUsb durch? Vlt. hilft, den JeeLink-Eintrag zu umbenennen?
wo schaltet man usb autocreate ab?

[justme1968]

es gibt ein

Code Auswählen Erweitern

define initialUsbCheck notify global:INITIALIZED usb create

das musst du löschen.

gruss
  andre

[rudolfkoenig]

Eigentlich sollte die Pruefung hoechstens 0.1 Sekunde dauern.
Und autocreate sollte keine Geraete anfassen, die bereits in FHEM eingetragen sind.

Nach "ZWDongle device opened" wird "01030020dc" (von hex in binaer konvertiert) hingeschrieben, und danach 0.1 Sekunde auf eine Antwort gewartet. Offensichtlich funktioniert letzeres nicht, ich vermute dass der Kernel-Treiber nicht richtig reagiert. Um es naeher einzugrenzen muesstest du in DevIo_TimeoutRead 3 Log Zeilen einbauen, eins vor dem select, eins nach dem select ($nafound bitte ausgeben), und eins nach DevIo_DoSimpleRead.

Merkwuerdig ist, dass die ZWDongle das Problem hat, TRX davor und FRM danach geht relativ flott.

[justme1968]

ein unterschied ist die baudrate. wenn die beim sender und empfänger so schlecht übereinstimmt kann es passieren das nur zufällig ein zeichen durch kommt. scheinbar nach der langen wartezeit. und wenn dann der timeout beim lesen nicht funktioniert würde es genau das verhalten erklären.

[rudolfkoenig]

Select sagt, es sind Daten da. sysread bekommt das, was da ist.
Keiner der beiden sollte laenger als beabsichtigt blockieren.

Einer der beiden Funktionen macht es anders, und ich meine das ist ein Treiberfehler.
Oder ich habe was falsch gebaut, das waere am einfachsten zu beheben.

[hexenmeister]

Danke für alle Antworten!

USB create zu verbieten ist für mich wohl die beste Lösung. Ich möchte schon selbst meine USB-Geräte anmelden

autocreate sollte keine Geraete anfassen, die bereits in FHEM eingetragen sind

Ich vermute, das liegt daran, dass JeeLink nicht per ttyUSB1 sondern als /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A702GA5B-if00-port0 definiert ist.

Logging werde ich später einbauen, möchte gerade mein Log nicht vermüllen, teste etwas mit dem neuen HM Wandthermostat.

Treiberproblem klingt ja schon sehr plausibel, allerdings ging das bis vor kurzen noch schön schnell und ein Update des Betriebssystems habe ich in der letzten Zeit nicht gemacht.

Grüße,

Alexander

[rudolfkoenig]

Ich vermute, das liegt daran, dass JeeLink nicht per ttyUSB1 sondern als /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A702GA5B-if00-port0 definiert ist.

Ach. Kannst Du bitte pruefen, ob das auch ein Symlink ist?

[Wernieman]

(Auch wenn ich nicht angesprochen wurde)
Das ist ein Symlink

Code Auswählen Erweitern


hedwig ~ # ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 25. Jan 22:20 usb-FTDI_FT232R_USB_UART_A702GD6P-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 25. Jan 22:20 usb-busware.de_CUL433-if00 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 25. Jan 22:20 usb-busware.de_CUL868-if00 -> ../../ttyACM0


[rudolfkoenig]

Ich habe CommandUsb geaendert, damit es solche Links prueft.
Weiterhin habe ich die Meldung bei usb scan/create von "Opening" auf "Probing" geaendert.

[hexenmeister]

ist das schon eingecheckt?
Habe gerade (nach einem update) usb create wieder reingenommen und neugestartet. ging sehr schnell

Vielen Dank!