USB device /dev/ttyUSB0 disconnected, waiting to reappear
effjottler
ich beschäftige mich jetzt seit Wochenbegin mit FHEM. In
unregelmäßigen Abständen habe ich folgende Meldung im Log:
2008.12.23 11:18:00 1: USB device /dev/ttyUSB0 disconnected, waiting
to reappear
2008.12.23 11:18:05 1: USB device /dev/ttyUSB0 reappeared
Danach empfängt die FHZ1000 nix mehr. Senden geht nach wie vor, per
PGM3 kann ich FS20 Aktuatoren schalten und auch die Solltemperatur der
FHT's ändern. Daten von den FHT's werden nicht empfangen und auch
keine Fernbedienbefehle.
Aus- und wieder einstecken der FHZ am USB-Port behebt das Problem bis
zum nächsten kurzen Verlust der Verbindung. Grad vorhin habe ich FHEM
nach einem solchen Hänger neu gestartet, auch das behebt das Problem.
Vermutlich weil die FHZ beim Start neu initialisiert wird.
Ich schalte diverse FS20ST, unter anderem den Fernseher und die
Stereoanlage. Bisher hat es ohne FHEM ganz gut funktioniert, ich
möchte auf keinen Fall dass der WAF durch die Automation per Rechner
sinkt ;-)
Die FHz1000PC ist neu, wurde extra für die Automation per Linux
angeschafft und ersetzt eine FHZ1000.
FHEM läuft auf meinem Homeserver, der ein Debian Etch beherbergt. In
eine VMWARE-VW läuft noch ein IPCOP. Die VM hat keine USB-Devices
konfiguriert.
Grüße,
Manfred
Boris Neubert
Am Dienstag, 23. Dezember 2008 schrieb effjottler:
> unregelmäßigen Abständen habe ich folgende Meldung im Log:
> 2008.12.23 11:18:00 1: USB device /dev/ttyUSB0 disconnected, waiting
> to reappear
> 2008.12.23 11:18:05 1: USB device /dev/ttyUSB0 reappeared
das Problem habe ich auch. Ich vermute, daß es ein physikalisches Problem auf
dem USB ist. Bei mir half es, die FHZ über ein powered USB hub mit dem PC zu
verbinden. 100% zuverlässig läuft es nicht, nach einem Reboot nach Abschalten
des PC muß ich manchmal etwas stöpseln, bis sich die Devices alle
wohlverhalten.
> Danach empfängt die FHZ1000 nix mehr. Senden geht nach wie vor, per
> Aus- und wieder einstecken der FHZ am USB-Port behebt das Problem bis
> zum nächsten kurzen Verlust der Verbindung. Grad vorhin habe ich FHEM
Schau mal in das Listenarchiv. Im Oktober gab es einen Thread "FHTs im Koma"
zu Watchdogs i.V.m. dem Kommandos initfull und reopen für das FHZ.
Viele Grüße und frohe Weihnachten,
Boris
Pest
habt ihr schon mal das probiert:
http://www.koeniglich.de/fhem/linux.html
Abschnitt "Device links"
Damit wird nicht "/dev/ttyUSB0" verwendet sondern ein entsprechender
Alias. Auch bei Änderungen durch udev sollte das stabil bleiben.
Verwendet ihr Debian? Solche Effekte habe ich bislang nur unter Debian
gesehen.
Gruß,
Peter
Boris Neubert
Am Samstag, 27. Dezember 2008 schrieb Pest:
> http://www.koeniglich.de/fhem/linux.html
> Abschnitt "Device links"
ja, funktioniert prima. Mit dem neuern 2.6.27.7er Kernel von openSuSE 11.1
erkennt der Rechner sowohl die FHZ1300 als auch das EM1010PC out-of-the-box.
Das CUL liegt sowieso auf /dev/ttyACM0.
> Alias. Auch bei Änderungen durch udev sollte das stabil bleiben.
> Verwendet ihr Debian? Solche Effekte habe ich bislang nur unter Debian
> gesehen.
openSuSE 11.1.
Hat jemand noch eine Idee? Sonst kaufe ich mir noch ein anderes/besseres Hub.
Problematisch bzgl. Device-Erkennung sind zur Zeit noch das CM11 und das M232,
die beide über den selben Typ von RS232-USB-Konverter angeschlossen sind und
anhand der Device-ID nicht unterscheidbar sind. Ich nutze daher die
physikalische Bus-ID, um die beiden Geräte zu unterscheiden. Aber diese sind
aber auch von Boot zu Boot manchmal unterschiedlich, abhängig davon, in
welcher Reihenfolge der Kernel die physikalischen Ports findet und numeriert.
Meine Datei in /etc/udev/rules.d sieht so aus:
BUS=="usb", ID=="7-2:1.0", SYMLINK+="M232"
BUS=="usb", ID=="3-1.4:1.0", SYMLINK+="CM11"
KERNEL=="ttyUSB*", ATTRS{product}=="ELV FHZ 1300 PC", SYMLINK+="elv_fhz1300pc"
KERNEL=="ttyUSB*", ATTRS{product}=="ELV EM 1010 PC", SYMLINK+="elv_em1010pc"
Gibt es hierfür eine verläßliche Softwarelösung?
Grüße,
Boris
effjottler
On 27 Dez., 17:23, Boris Neubert <om...@online.de> wrote:
> Hallo Peter,
>
> Am Samstag, 27. Dezember 2008 schrieb Pest:
>
> >http://www.koeniglich.de/fhem/linux.html
> > Abschnitt "Device links"
> > Verwendet ihr Debian? Solche Effekte habe ich bislang nur unter Debian
> > gesehen.
>
> openSuSE 11.1.
Mein Server steht im Keller in der Nähe eines Kühlschranks. Beim
Einschalten des Kühlschranks sowie der Leuchstoffröhren im Flur und
Kellerraum passiert es. Allerdings ist der Empfang nicht nach jedem
"USB device /dev/ttyUSB0_reappeared" weg.
> Hat jemand noch eine Idee? Sonst kaufe ich mir noch ein anderes/besseres Hub.
immer noch getrennt
effjottler
Also, der USB-Hub hat bei mir nichts gebracht. Und ich bezweifle das
ein anderer HUB Dir etwas bringen wird.
das steht in messages:
Dec 27 17:25:40 srv-1 kernel: usb 1-1: USB disconnect, address 4
Dec 27 17:25:40 srv-1 kernel: ftdi_sio ttyUSB0: FTDI USB Serial Device
converter now disconnected from ttyUSB0
Dec 27 17:25:40 srv-1 kernel: ftdi_sio 1-1:1.0: device disconnected
Dec 27 17:25:44 srv-1 kernel: usb 1-1: new full speed USB device using
ohci_hcd and address 5
Dec 27 17:25:44 srv-1 kernel: usb 1-1: configuration #1 chosen from 1
choice
Dec 27 17:25:44 srv-1 kernel: ftdi_sio 1-1:1.0: FTDI USB Serial Device
converter detected
Dec 27 17:25:44 srv-1 kernel: drivers/usb/serial/ftdi_sio.c: Detected
FT8U232AM
Dec 27 17:25:44 srv-1 kernel: usb 1-1: FTDI USB Serial Device
converter now attached to ttyUSB0
Den Server an einen anderen Stromkreis zu hängen bringt auch nichts.
Vielleicht hilft ein anderes mainboard, bei dem die USB Interfaces
nicht so empfindlich sind.
Wenn ich die Schnittstelle mit "reopen" neu initialisiere gehts
wieder. Auch ein initfull funktioniert. vielleicht kann ich einen
Workaround per Watchdog bauen.
Grüße,
Manfred
effjottler
ein ständiges "reopen" alle 5 minuten brachte nach ner Weile den fhem
zum Absturz:
2008.12.28 16:41:42 2: FHZ set FHZ1 reopen
2008.12.28 16:41:42 1: USB device /dev/ttyUSB0 closed
2008.12.28 16:41:47 1: USB device /dev/ttyUSB0 reopened
Select error -1 / Bad file descriptor
(in cleanup) Can't call method "setcflag" on an undefined
value at /usr/lib/perl5/Device/SerialPort.pm line 482 during
global destruction.
Auch ein periodisches "initfull" führte nicht zum Erfolg, die FHZ ließ
sich nicht mehr initialisieren:
2008.12.28 23:04:38 2: FHZ set FHZ1 initfull
2008.12.28 23:04:39 1: Trying again get FHZ1 init2 (2 out of 3)
2008.12.28 23:04:40 1: Trying again get FHZ1 init2 (3 out of 3)
2008.12.28 23:04:43 1: Trying again get FHZ1 serial (2 out of 3)
2008.12.28 23:04:44 1: Trying again get FHZ1 serial (3 out of 3)
2008.12.28 23:09:46 2: FHZ set FHZ1 initfull
Jetzt betreibe die FHZ an einem anderen Rechner. Bis jetzt keine
Probleme. Einen "disconnect" durch ein/ausschalten von
Leuchtstofflampen und des Kühlschranks zu provozieren war nicht
möglich.
Das ist aber leider mein alter Server, der durch den anderen ersetzt
werden sollte.
Grüße,
Manfred
Pest
Probier mal folgenden Befehl:
udevinfo --query=all --name=/dev/ttyUSB0
Merke dir den output und wenn der Fehler wieder auftritt führe das
Kommando nochmal aus. Meine Vermutung ist, dass sich die Device-Nr. im
Pfad (P:...) ändert. Habe das noch nicht näher analysiert - dachte das
wäre nur bei Debian.
Gruß,
Peter
effjottler
zurück von einer kurzen Urlaubsreise und was soll ich sagen: fhem ist
auf der anderen HW ohne USB-Verbindungsverlust durchgelaufen.
Jetzt kann ich mich daran machen meine Hütte weiter zu automatisieren.
Danke für die tolle Software!
Grüße,
Manfred
Pest
wenn das USB-Gerät auf unterer Protokollebene (von USB) nicht
rechtzeitig antwortet. Dann wird das Gerät abgemeldet. Kurz danach
wird es als "neues" Gerät erkannt und erhält daher eine andere
Adresse.
Bleibt nur die Frage warum die Geräte manchmal nicht rechtzeitig
antworten bzw. wie man ggf. den Timeout des Treibers erhöhen kann.
Gruß,
Peter
Pest
sorry, hatte Deinen Text wohl übersehen.
> Problematisch bzgl. Device-Erkennung sind zur Zeit noch das CM11 und das M232,
> die beide über den selben Typ von RS232-USB-Konverter angeschlossen sind und
> anhand der Device-ID nicht unterscheidbar sind. Ich nutze daher die
> physikalische Bus-ID, um die beiden Geräte zu unterscheiden. Aber diese sind
> aber auch von Boot zu Boot manchmal unterschiedlich, abhängig davon, in
> welcher Reihenfolge der Kernel die physikalischen Ports findet und numeriert.
>
> Meine Datei in /etc/udev/rules.d sieht so aus:
>
> BUS=="usb", ID=="7-2:1.0", SYMLINK+="M232"
> BUS=="usb", ID=="3-1.4:1.0", SYMLINK+="CM11"
> KERNEL=="ttyUSB*", ATTRS{product}=="ELV FHZ 1300 PC", SYMLINK+="elv_fhz1300pc"
> KERNEL=="ttyUSB*", ATTRS{product}=="ELV EM 1010 PC", SYMLINK+="elv_em1010pc"
>
> Gibt es hierfür eine verläßliche Softwarelösung?
also ich habe den Teil mit den elv_* links über die Attributliste
ermittelt. Ich habe kein CM11 bzw. M232. Du kannst über:
udevadm info --name=/dev/ttyUSB0 --attribute-walk
...mit entsprechend angepasstem ttyUBSx alle Attribute auslesen. Evtl.
ist eines dabei das sich besser eignet. Kannst den Output ja mal
posten.
Gruß,
Peter
Matthias Urlichs
Pest:
> Habe mal mit ein paar Spezies über das Problem diskutiert. Es kommt,
> wenn das USB-Gerät auf unterer Protokollebene (von USB) nicht
> rechtzeitig antwortet. Dann wird das Gerät abgemeldet. Kurz danach
> wird es als "neues" Gerät erkannt und erhält daher eine andere
> Adresse.
Korrekt.
> Bleibt nur die Frage warum die Geräte manchmal nicht rechtzeitig
> antworten bzw. wie man ggf. den Timeout des Treibers erhöhen kann.
>
Gar nicht. Das Problem sind Störungen auf dem Bus. Wenn die so heftig
sind, dass das Gerät nicht mehr antwortet, dann muss der Master davon
ausgehen, dass es abgestürzt ist o.Ä..
Evtl. hilft ein Klappferrit oder zwei (an jedem Ende der Leitung einer) ..?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | sm...@smurf.noris.de
Disclaimer: Das Zitat wurde zufällig ausgewählt. | http://smurf.noris.de
- -
Wasimmer du auch tust ist nicht entscheidend, doch es ist wichtig, daß
Du es richtig tust.
-- Mahatma Gandhi
Boris Neubert
ich habe wie versprochen alle meine bisherigen Erkenntnisse in einem separatem
Posting zusammengetragen.
Meine persönlichen Erfahrungen diesbezüglich sind:
- FHZ1300PC geht nur mit powered hub.
- Die am powered hub (USB 1.1) angeschlossenen Geräte werden regelmäßig
automatisch abgehängt.
- Deaktivierung des USB Power Management hilft nicht.
- Einbau einer extra USB-Karte: die an der extra USB-Karte angeschlossenen
Geräte (M232, CM11) werden nicht abgehängt (Ursache unbekannt, möglicherweise
Power Management nicht unterstützt, Qualität der Ports besser, USB weniger
störungsanfällig, ...)
Ich werde jetzt noch folgendes versuchen:
- Powered USB 1.1 hub durch powered USB 2.0 hub guter Qualität ersetzen.
- Klappferrite um die Kabel.
Grüße,
Boris
Martin Fischer
> ich habe wie versprochen alle meine bisherigen Erkenntnisse in einem
> separatem Posting zusammengetragen.
danke boris für die mühen...
> Meine persönlichen Erfahrungen diesbezüglich sind:
> - FHZ1300PC geht nur mit powered hub.
> - Die am powered hub (USB 1.1) angeschlossenen Geräte werden regelmäßig
> automatisch abgehängt.
> - Deaktivierung des USB Power Management hilft nicht.
> - Einbau einer extra USB-Karte: die an der extra USB-Karte angeschlossenen
> Geräte (M232, CM11) werden nicht abgehängt (Ursache unbekannt,
> möglicherweise Power Management nicht unterstützt, Qualität der Ports
> besser, USB weniger störungsanfällig, ...)
hier mal meine persönlichen erfahrungen:
- FHZ1300PC an onboard usb 2.0 port auf einem asus p5n-e sli keine probleme
- keine eingriffe ins powermanagement
jetzt an einem anderen rechner mit touchscreen.. ziemlich alte hardware siehe
fujitsu stylistic lt c-500
- FHZ130PC an onboard usb 1.1 port keine probleme
- keine eingriffe ins powermanagement
weiterhin an gleicher hardware getestet:
- FHZ1300PC an passivem mini usb portexpander (winkelstecker 1 port auf 4
port) keine probleme
- CM11 an gleichem passiven portexpander -> CM11 rennt irgenwann in timeout,
KEINE meldungen im kernellog!
beide devices (fhz/cm11) sind mittels udev an einen symbolischen link
(/dev/cm11 und /dev/fhz1300) gebunden, um der sporadische neuuzuordnung bei
einem neustart entgegen zu wirken..
bei mir treten nur die probleme mit dem cm11 auf, nicht mit fhz1300pc und eben
auch erst nachdem ich beide an den portexpander angeschlossen habe..
und wie gesagt: keinerleich meldungen vom kernel.. nach einem neustart von
fhem lüppt das cm11 wieder.. bis auf unbestimmte zeit..
Pest
wenn ich da...
> - FHZ1300PC an passivem mini usb portexpander (winkelstecker 1 port auf 4
Leitungslänge. Oder ist hier mit "Expander" nur ein normaler Hub
gemeint? Also, keiner der versucht über mehr als 5m zu verlängern..?!?
Siehe:
http://www.usb.org/developers/usbfaq/#3
Gruß,
Peter
Martin Fischer
Am Dienstag, 13. Januar 2009 schrieb Pest:
> wenn ich da...
>
> > - FHZ1300PC an passivem mini usb portexpander (winkelstecker 1 port auf 4
>
> "Portexpander" lese... kommt mir die Frage nach der gesamten
> Leitungslänge. Oder ist hier mit "Expander" nur ein normaler Hub
> gemeint? Also, keiner der versucht über mehr als 5m zu verlängern..?!?
also die leitungslänge ist < 5m. ich habe da teil mal als "expander"
beschrieben, da es aus einem port 4 macht :-) im prinzip ist das nur
ein "streicholzschachtel grosser usb stecker" mit vier ausgängen ohne
jeglichem kabel oder externer stromversorgung..
ich habe vorhin mal gegoogelt ob ich noch eine beschreibung oder ein bild
finde.. aber wahrscheinlich habe ich den schon so lange, das der schon im
computermuseum in münchen liegt :-)
ein lsusb gibt folgende auskunft:
root@homer:~# lsusb -s 001:002 -v
Bus 001 Device 002: ID 058f:9254 Alcor Micro Corp. Hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 8
idVendor 0x058f Alcor Micro Corp.
idProduct 0x9254 Hub
bcdDevice 3.12
iManufacturer 1 ALCOR
iProduct 2 Generic USB Hub
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 4
wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
bPwrOn2PwrGood 22 * 2 milli seconds
bHubContrCurrent 100 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0103 power enable connect
Port 3: 0000.0103 power enable connect
Port 4: 0000.0100 power
Device Status: 0x0001
Self Powered
Dr. Boris Neubert
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
also ein USB 2.0-Hub,
Gruesse,
Boris
Martin Fischer
> bDeviceClass 9 Hub
> bDeviceSubClass 0 Unused
> bDeviceProtocol 0 Full speed (or root) hub
>
> also ein USB 2.0-Hub,
jo..
der usb port am rechner (fujitsu stylistic lt c-500) auf dem ein xubuntu
lüppt, ist nur usb 1.1
Boris Neubert
ich habe es geschafft. Die regelmäßigen Disconnects der FHZ1300PC sind
beseitigt!
Am Montag, 12. Januar 2009 schrieb Boris Neubert:
> Ich werde jetzt noch folgendes versuchen:
> - Powered USB 1.1 hub durch powered USB 2.0 hub guter Qualität ersetzen.
> - Klappferrite um die Kabel.
Ich habe alle fhem-gesteuerten Geräte an ein self-power USB 2.0-Hub gehangen.
Kein Erfolg.
Ich habe dann bei allen USB-Geräten an Hub das Powermanagement ausgeschaltet.
Kein Erfolg.
Ich habe dann Klappferrite angebracht.
Kein Erfolg.
Ich habe dann die USB-Portverlängerung herausgenommen und somit die Kabellänge
auf 5m verkürzt.
Erfolg. Seit 6 Stunden beschwerdefrei.
Ich werde die USB-Anleitung ergänzen und der fhem-Doku beifügen.
Viele Grüße,
Boris
Kai 'wusel' Siering
> Ich habe dann die USB-Portverlängerung herausgenommen und somit
> die Kabellänge auf 5m verkürzt.
> Erfolg. Seit 6 Stunden beschwerdefrei.
war das ein simples Kabel oder eine aktive USB-Verlängerung (d. h.
mit dickerem Stecker an einer Seite, wo sich ein Hub drin ver-
steckt)? Mit simplen Kabeln (2m, 3m) habe ich schon mit USB-Kame-
ras die Erfahrung machen dürfen, daß jene sich teilweise nicht
mal mehr am Bus anmelden; mit "aktiven" USB-Verlängerungen trat
derlei bislang nicht auf. Lustigerweise war Billig-Kabel + Hub
ans Ende nicht identisch in der Funktion wie das "aktive" Kabel
mit eingebautem Hub ...
MfG,
kai
Dr. Boris Neubert
es war eine aktive USB-Verlaengerung (Kabel mit einem
streichholzschachtelgrossen Kaestchen am fernen Ende). Offensichtlich hat
die Gesamtqualitaet der Verbindung nicht ausgereicht - ich konnte die Mimik
ja schon nicht ohne self-powered-Hub betreiben. Na ja, jedenfalls empfaengt
die FHZ jetzt auch noch alle Geraete, obwohl die Positionierung in Sachen
Empfang nicht mehr so gut ist wie vor.
Viele Gruesse,
Boris