[GELÖST] IntelNUC MaxCUL - /Cannot init /dev/ttyACM0 - USB3 Problem

[porty]

Moin Moin,

habe ein kleines Problem.
bin gerade mit Fhem auf einen NUC umgezogen und mein MaxCUL spinnt rum.

- MaxCube geflashed mit aktueller a-culfw.
Das Teil lief und läuft auf dem RPi Problemlos. Habe es gestern extra nochmal am PI angeschlossen.

- System:
- intelNuc mit Debian 9.5 64bit
- Fhem installiert
- CUL eingesteckt: lsusb -> gerät wird anzeigt

definiere ich nun das Gerät in FHEM funktioniert alles, egal ob ich via SerialID oder über den ttyACM0 port gehe.

Wenn ich nun den Nuc neustarte geht nichts mehr. Gerät erkannt aber folgende Meldung:

Code Auswählen Erweitern

018.09.09 11:25:05 3: Opening CUL0 device /dev/ttyACM0
2018.09.09 11:25:05 3: Setting CUL0 serial parameters to 9600,8,N,1
2018.09.09 11:25:14 1: Cannot init /dev/ttyACM0, ignoring it (CUL0)
2018.09.09 11:25:14 1: Including ./log/fhem.save
2018.09.09 11:25:14 1: usb create starting
2018.09.09 11:25:14 1: usb create end

lösche ich nun das das Gerät aus Fhem, ziehe den stecker ab, starte den nuc neu, stecke den Stecker wieder ein und definiere den CUL erneut, läuft es wieder.
Hänge da nun seit 3 Tagen dran.
Habe diverse USB-Port freigaben versucht etc, erfolglos.

Nun habe ich heute morgen den Nuc & Fhem komplett neu installiert (kein Backup oder ähnliches), selbe Problem.

Hat jemand eine Idee?

[DS_Starter]

Hast du es mit einem solchen Define schon probiert ?

Code Auswählen Erweitern


/dev/serial/by-id/usb-busware.de_CUL433-if00@9600 0000


Must du natürlich anpassen. Mal nach /dev/serial/by-id/ schauen und die richtige Device-Datei benutzen.

Grüße

[porty]

Habe ich,

bei mir war es natürlich anders:
define CUL0 CUL /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00@9600 0000

gleiche Problem.
Habe nun nochmal den Jeelink mit eingesteckt.
Keine Probleme. 3x neu gestartet, Gerät wird immer erkannt. Ein Gerät (technoline DHT) angelernt um testen, wird auch nach jedem Neustart Problemlos empfangen

edit: hier mal 2 Screens. (1) vor dem Reboot, (2) Nach dem reboot. Auch die CMDS etc werden nicht mehr angezeigt.


und noch ein Nachtrag:

Code Auswählen Erweitern


ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Sep  9 12:13 usb-03eb_AT91USBSerial1-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Sep  9 12:13 usb-FTDI_FT232R_USB_UART_AI04PHBS-if00-port0 -> ../../ttyUSB0



Habe soeben im laufendem Betrieb mal den Cul0 entfernt aus Fhem, CUL ein/ausgesteckt und neu definiert. Wird sofort wieder erkannt in Fhem.
Es scheint aber kein Problem von FHEM zu sein. Habe soeben das ganze mal mit IObroker getestet. Gleiche Problem.

Beim ersten start verbindet er sich Problemlos, nach dem Reboot nicht mehr. mache ich den CUL kurz spannungsfrei, stecke ihn wieder ein, geht es sofort wieder.

[porty]

Und noch ein Nachtrag nach vielen Tests.
Es geht immer wenn ich den CUL entferne, den NUC starte und wenn alles hochgefahren ist den CUL wieder einstecke.

[Wernieman]

Wenn es "nicht" geht, reicht also nicht den CUL rausziehe, 10 sec. warten und wider reinstecken?

was sagt dmesg nach dem wieder einstecken?

[porty]

Ahoi,
also ein/austecken im laufendem Betrieb bringt nichts. nach dem Reboot steht der CUL bei Fhem auf "Open".

dmesg | grep usb (nach einem normalem Reboot)

Code Auswählen Erweitern

[    4.148419] usb 1-4: new full-speed USB device number 4 using xhci_hcd
[    4.318473] usb 1-4: New USB device found, idVendor=03eb, idProduct=6119
[    4.318477] usb 1-4: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    4.318480] usb 1-4: Product: AT91USBSerial1

Trenne ich den CUl kommt natürlich die Meldung:

Code Auswählen Erweitern

[  341.767550] usb 1-4: USB disconnect, device number 4

Verbinde ich den Cul wieder:

Code Auswählen Erweitern

[  414.916246] usb 1-4: new full-speed USB device number 14 using xhci_hcd
[  415.082443] usb 1-4: New USB device found, idVendor=03eb, idProduct=6119
[  415.082460] usb 1-4: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[  415.082471] usb 1-4: Product: AT91USBSerial1


keine Verbindung von Fhem möglich, Gerät steht auf "open".
Mache ich nun aber ein "shutdown restart" wird die Verbindung hergestellt, der Cul0 steht auf "initialized" und ich kann alles bedienen.

Wenn ich Fhem mit Shutdown restart neu starte nach einem Reboot bringt es nichts. Ich muss vorher den Cul trennen einmalig.

[Wernieman]

Wie viele /dev/ttyACM Device hast Du nach einer solchen Aktion?

Da Du FHEM eben NICHT runtergefahren hast, dürfte /dev/ttyACM0 (und das passende /dev/serial/by-id) nicht gelöscht werden. Beim wiedereinstekcen dürftest Du dann ein 2. /dev/ttyACM (Warscheinlich /dev/ttyACM1) bekommen. Da die Seriennnummer bei  /dev/serial/by-id die gleiche ist, wird dort nicht ein 2. Angelegt (und auf das falsche /dev/ttyACM verwiesen)

Bei einem reboot wird aber bei 0 Angefangen, d.h. Du hast noch keine  /dev/ttyACM und damit bkommt das Device die 0 ....

[porty]

Guten Morgen,

also laut: ls -l /dev/serial/by-id
habe ich lediglich 1 Device.
Entferne ich das Gerät bleibt lediglich der ttyUSB0 übrig (Jeelink).
Wird das Gerät neu verbunden erscheint der ttyACM0 erneut.

Kurz gesagt, es ist immer nur ein Device (ttyACM0)  vorhanden. 
Das Problem besteht ja wie bereits geschrieben auch wenn ich das Gerät komplett neu hochfahre. Ich den Nuc zB 10min ausgeschaltet lasse und dann starte.
Ich muss zwingend den Stick abziehen vorm einschalten und dann einstecken. Oder den Ablauf wie vorher beschrieben, (Austecken, einstecken, fhem Restart)

[Wernieman]

Also scheinbar Hardwareproblem ......

[Beta-User]

Auch wenn das folgende ein Gestochere im Nebel ist:

- Vielleicht auch irgendwas, was mit dem Schnittstellentyp USB2/USB3 zu tun hat?

Wir hatten den Fall schon, dass manche seriellen Devices Probleme an USB3-Schnittstellen hatten; da gab es irgendwo eine Option, das umzustellen.

- Außerdem hat neulich irgendwer im Zusammenhang mit Ubuntu18.04 von Problemen mit USB-Devices berichtet. Da es hier um ein sehr neues Debian geht, liegt evtl. ein ähnliches Problem vor? (Da ging es darum, dass die USB-Schnittstellen irgendwo ganz anders im filesystem zu finden waren). Könnte sein, dass auch Debian in die Richtung geht und irgendein Kompabilitätslayer zwischengeschaltet ist, der nicht richtig ausgereift ist? (wäre nicht Debian-like, aber wer weiß?)

Ergänzend sollten m.E. die defines aller USB-Devices auf "by-id" umgestellt werden, sofern möglich (hat aber ziemlich sicher nichts mit dem Problem zu tun, das ist schon klar).
Gruß, Beta-User

[porty]

Hardware im Sinne von Defekt schließe ich aus.

Was Beta-User sagt wäre evtl eine Option, bezüglich des USB3.0 ports.

Alternativ wäre die Startreihenfolge evtl eine Option.
Mir ist noch eingefallen das ich KDE (aus welchem Grund auch immer) mitinstalliert habe. Evtl startet dadurch Fhem vor der initialisierung der USb /TTY ports.

[Beta-User]

Das mit der Startreihenfolge halt ich nicht für wahrscheinlich, aber evtl. was anderes:
Die Hardware sollte mit udev recht früh eingebunden werden, insbesondere vor FHEM; FHEM startet als Dienst vor dem xserver soweit so gut.
ABER: Das Ding identifiziert sich als Modemgerät (ttyACM0) und das könnte sich der KDE-User erst mal unter den Nagel reissen, dann darf user fhem nicht mehr dran... Verantwortlich ist evtl. auch der networkmanager.

Sollte bei der Sichtweise zwar eigentlich egal sein, wann man das Teil einstöpselt, aber denkbar wäre es.

Wenn du noch nicht viel dran rumkonfiguriert hast (oder üben willst), würde ich empfehlen, das Debian nochmal von vorne in der Minmalst-Variante zu installieren (Anleitung steht unter ThinClient-Hardware im Wiki). Nicht nur wegen dieses Themas, aber ein Server "verliert" durch die Installation einer GUI. Und die installierten Abhängigkeiten bekommt man vermutlich durch eine Deinstallation nicht mehr gerade gebogen.

Just my2ct.

Beta-User

[Wernieman]

Also Desktopsystem ....  das könnte der Grund sein.

Mit Hardware meinte ich eigentlich den USB-Bereich im Rechner. Der wird durch ein Reboot (oder Treiber entfernen/laden) resettet ...

[porty]

Bisher habe ich nichts gemacht, habe mein altes IObroker & Fhem System eh als Backup liegen. Von daher stellt eine Neuinstallation keine Probleme.

Ja mit dem Desktop System ist mir auch gerade erst eingefallen da ich es bisher nicht genutzt habe. Habe nicht mal einen Monitor an dem Teil, lediglich zum installieren.
und @wernieman, so hatte ich es auch verstanden, mir ging es nur darum einen defekten Verbraucher auszuschließen

Ich Installiere nachher mal alles neu sobald ich zuhause bin.

[porty]

Soo habe alles neu aufgesetzte, die thin Version.

Gleich Ergebniss.
Habe auch nochmal im BIOS an den USB Ports gespielt (legacy aus u.s.w.)

Parallel habe ich einen zweiten cul868 versucht womit ich das gleiche Problem habe.

Habe diesmal einfach nach Anleitung installiert, thin -> FHEM Debian manuell Install.
Mehr habe ich nicht gemacht. Cul angelernt, OK. Läuft.
Reboot, cul steht auf Open und bekommt keine Signale.
Ablauf von oben wiederholt (aufstecken, einstecken, shutdown restart) wieder erkannt.

Ich glaube ich hau FHEM wieder auf den RPi und Lager den Rest auf den NUC aus. Optional einen Pi mit fhem2fhem wobei der RPi dann nur für den Cul ist.

Aja, ist übrigens ein nuc5cpyh. Aber wüsste nicht wo da das Problem liegen sollte