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

[Otto123]

Mal ganz nebenbei die Idee:

Code Auswählen Erweitern

attr initialUsbCheck disable 1

Gruß Otto

[connormcl]

Und wieso genau schliesst du nochmal einen Hardwaredefekt am NUC aus?

Um voran zu kommen könntest du den CUL noch an einem anderen x86/x64 Rechner testen und wenn es läuft, genau dieses Betriebssystem am NUC testen...
Genauso gibts noch jede Menge andere Distributionen, mit denen man noch abtesten kann, onb es nun an deinem Debian liegt oder nicht. Auch kann wie schon erwähnt eine frühere Version ein anderes Verhalten zeigen.

Wenn das dann noch nicht in irgendeiner Konstellation läuft, bleibt nur noch ein zweiter NUC zum testen...aber den solltest du ja eh als Testumgebung haben, da du ja nicht ständig an der Produktivumgebung arbeiten willst, während das Haus laufen soll...

[Wernieman]

Also das ist das erste Mal, das ich von so etwas höre. Es kann, wie oben erwähnt, eventuell an USB 3 liegen ...

Könntest Du noch probieren:
- FHEM runterfahren
- Stick entfernen
- ls /dev/serial/by-id sollte nichts mehr zeigen
- 1sec später Stick anschließen
- ls /dev/serial/by-id sollte Stick zeigen
- FHEM hochfahren
- prüfen ....

Edit:
geprüft, ob es BIOS updates gibt?

Leider werden die Treivber für USB heute meistens in den Kernel einkompiliert. Sonst hätte ich Dir mal empfohlen, die Treiber zu entladen/laden ...

[porty]

Code Auswählen Erweitern

attr initialUsbCheck disable 1

ist aktiv, kein Unterschied.

Könntest Du noch probieren:
- FHEM runterfahren
- Stick entfernen
- ls /dev/serial/by-id sollte nichts mehr zeigen
- 1sec später Stick anschließen
- ls /dev/serial/by-id sollte Stick zeigen
- FHEM hochfahren
- prüfen ....

Das habe ich bereits gemacht, hatte ich weiter oben mal beschrieben. Beim Entfernen ist kein Stick vorhanden, wenn ich ihn wieder anstecke und fhem starte/neustarte funktioniert es wieder.
Es geht geht halt nicht, wenn ich den Nur reboote bzw neu einschalte.

Bios Update wurde vorgestern auch noch gemacht. Die Beführchtung hatte ich nähmlich auch
Im Bios habe ich nun mal das OS auf Linux gesetzt, auch keine Veränderung.

@connormcl
Habe tatsächlich KEINEN zweiten Nuc muss mal schauen ob ich auf die schnelle einen ausgeliehen bekomme zum testen.
Warum ich es eigentlich auschließe (was natrülich total bescheurt ist da ich in meinem Job mehr als genug Geräte in der Hand habe die Neu nicht funktionieren) ist, das der Nuc noch recht neu ist.
Wurde knapp 2Monate als Mediaplayer genutzt, wobei auch das nur sporadisch.
Es wundert mich halt das alles andere Problemlos funktioniert. Logitech Unify Empfänger, Jeelink etc. Auch das Installieren vom USB Stick macht ja keine Probleme.

Evtl sollte ich mal eine ältere Debianversion testen. bei der letzten Installation habe ich die "debian-9.5.0-amd64-netinst.iso" .
Vorher habe ich mal die "debian-9.5.0-i386-xfce-CD-1.iso" genutzt was für mich eigentlich logischer wäre.

die amd64 habe ich anschließend verwendet, da Ubuntu (auch ein test) mit der i386 Version nicht installierbar war. Des Weiteren wollt eich neben FHEM auch Iobroker nutzen und das lässt sich nur auf einem 64bit System installieren.

Evtl liegt ja auch da ein Fehler vor.. wobei es mich wundern würde das es mit den oben beschriebenen Ablauf /ein/Ausstecken/Fhem reboot/ ja funktioniert und ich abgesehen von den beiden CULs keine Probleme habe (scheinbar)

Gruß

[Wernieman]

AMD64 ist nicht für AMD, sondern für 64-Bit-Prozessoren. Kommt historisch, da dieses 64 Bit von AMD entwickelt wurde (und auch von Intel verwendet wird). i386 ist dagegen 32 Bit und nicht mehr Zukunftsfähig im X86 Bereich

[Beta-User]

Irgendwie ist das insgesamt seltsam. Ich würde eher auf ein grunsätzliches Problem des CUL kommen, das Verhalten ist nämlich m.E. nicht standardkonform.

- Er meldet sich als Modem-Device an. Das wäre normal, wenn es ein CUL mit CUL-firmware wäre. ABER: der hätte eine andere Kennung!
- Stattdessen meldet er sich mit der Manufacturer ID eines chinesischen Herstellers, ohne dass das weiter aufgedröselt würde oder die Produktart bestimmt. Sehr seltsam.

Hast du einen anderen Linux-Rechner (optimalerweise mit älterem OS) und kannst da die Angaben vergleichen?

Hast du das Teil selber geflasht? Weißt du, was da für ein Prozessor drauf ist? => Bilder...

Helfen würden ggf. auch mal die Rechte, also ls -l /dev/serial/by-id und ...by-path.

Gruß, Beta-User

[Wernieman]

Du meinst, beim booten werden Rechte gesetzt .... könnnte sein. Aber es wurde oben geschrieben "jungfräuliche Installation"

[Beta-User]

Beim Booten und beim Einstöpseln; das ist doch u.a. eine der Aufgaben von udev, oder?

Irritierend ist aber, dass es Unterschiede zu geben scheint, wo es eigentlich keine geben dürfte. Das würde ich eigentlich eher auf andere Umstände zurückführen, aber trotzdem sollte es egal sein, wann der Stick dazu kommt. Oder weil ACM => Modemmanager (gibt wohl auch einen darunterliegenden Dienste-Teil, der auch ohne GUI aktiv ist), der aber nicht mehr informiert wird, wenn das Teil nach dessen Start eingestöpselt wird (da eben keine Geräteklasse bekannt ist). Deswegen kann dann eine serielle Kommunikation aufgebaut werden (die ja exklusiv ist).

Aber wie bereits gesagt: ziemliches Stochern im Nebel, und die Erkennung der Firmware@USB sieht seltsam aus.

Was mir in dem Zusammenhang grade einfällt: Es handelt sich ja um einen umgeflashten Cube. Vielleicht sollte der Thread in den CUL-Bereich verschoben werden, damit Telekatz (?) sich das ansehen kann? Oder dort einen neuen aufmachen/einen Beitrag in CULFW@ARM mit Hinweis auf hier, Topic etwa: Probleme mit umgeflashtem MAX-Cube und Debian 9.5.

Just my 2ct.

Beta-User

[porty]

Vorab, vielen vielen Dank für eure Beiträge und Hilfestellung!

......

Hast du einen anderen Linux-Rechner (optimalerweise mit älterem OS) und kannst da die Angaben vergleichen?

Hast du das Teil selber geflasht? Weißt du, was da für ein Prozessor drauf ist? => Bilder...

Helfen würden ggf. auch mal die Rechte, also ls -l /dev/serial/by-id und ...by-path.

Gruß, Beta-User

Cul(1) ist ein MaxCube mit a-culfw firmware. Lief am RPi lange Problemlos
Cul(2) ist ein Eingebau mit a-culfw firmware, auch dieser lief problemlos. Habe diesen nur gegen den Cube ausgetauscht da ich anderes mit dem Teilchen vorhatte.
Zur Firmware vom Cube: im 3. Beitrag sind 2 Screens. Im ersten Bild zeigt er unten ja auch die korrekte Firmware an.

habe noch einen Laptop mit Ubuntu liegen, jedoch habe ich soeben auch einen anderen IntelNUC bekommen mit dem ich das nachher nochmal teste.

Was mich jedoch extrem irritiert ist das es wohl ein LINUX und kein Fhem Problem ist.
Ich habe das gleiche verhalten mit dem IOBroker. Wenn ich in IObroker die MaxCul Instanz nutze, muss ich mehr oder weniger genau so vorgehen. Nach einem reboot wird er nicht erkannt, nach dem Trennen und erneutem Verbinden ist er ansprechbar. Hier ist der einzige Unterschied das ich Iobroker nicht neu starten muss. IObroker wird allerdings als root installiert.
----------------------------------
ls -l /dev/serial/by-id hat mir soeben mitgeteilt das sowohl besitzer als auch Gruppe "root" sind. Komisch, da sonst der port der Gruppe "Dialout" zugeordnet war.

Habe nun versuchsweise fhem mal der gruppe root und tty zugeteilt, macht aber keinen Unterschied.

Code Auswählen Erweitern

lrwxrwxrwx 1 root root 13 Sep 12 11:14 pci-0000:00:14.0-usb-0:2:1.0 -> ../../ttyACM0 (abgetippt vom VPN Tablet)

[Beta-User]

Sorry, ich war vermutlich teilweise auf dem Holzweg, aber wenn es bei unter root laufenden Prozessen dasselbe ist, dann war es das ziemlich sicher nicht. Aber dennoch kurz:

root:root ist bei /dev/serial/... vermutlich richtig, erst das "von udev weitergeleitete Ergebnis" "/dev/tty..." sollte dann "root:dialout" sein (die DEF darf trotzdem auf /dev/serial verweisen, ohne dass es Probleme gibt!).

Wenn dort root:tty steht, sollte fhem auch in die tty-Gruppe rein, das Debian-Paket erledigt "nur" dialout.
(Aber das erklärt alles immer noch nicht, warum es mal klappt und mal nicht?!?).

Es ist damit aber m.E. ein Linux-Problem und hat mit FHEM selbst eigentlich nichts zu tun. Evtl. mal Debian-Foren oder Ubuntuusers befragen, Ubuntu ist bei sowas in der Regel voraus.

[Wernieman]

Der Unterschied zwischen boot und nachträglich ist eigentlich nur, das teilbereiche noch nicht geladen sind, bzw. einige bootprozesse nur eben einmal gestartet werden.

Nur mal als Beispiel (auch wenn es konstruiert ist):
Baue Dir ein Service, der /dev/ttyUSB* neue Rechte gibt (chown). Wenn Du jetzt aber den Stick raus/reinsteckst, wird der passende /dev/ttyUSB* neu angelegt und hat damit normale Rechte.

Das Du FHEM neu starten musst, hat am Zugriff zu tuen. FHEM hält einen dauernden Zugriff auf tty-Device, welche Du eben nur mit runter/hochfahren des Service (FHEM) auflösen kannst. Wenn ein anderes Produkt so etwas eben nicht dauerhaft macht, kannst Du das Problem i9m laufenden Betrieb lösen.

Da Du schriebst, das  IOBroker das Problem auch hat .... WAS alles läuft auf dem System?

[porty]

Auf der jetzigen Version läuft lediglich Fhem. (Thin Install und manuell fhem Install)

https://wiki.fhem.de/wiki/Thin_Client_Hardware#Installation_eines_Debian-Grundsystems_und_FHEM
https://debian.fhem.de/ -> Manuell install.

Diesmal extra nach Anleitung um Fehler auszuschließen
Zusäzlich halt noch "Sudo" installiert, das wars. Ach ja, die Wlan NUC Treiber.

Ich habe versuchsweise mal iobroker drauf gehauen wohl gemerkt anstelle von Fhem. Also nach einer Neuinstallation.
Da ich seit einigen Tagen an dem problem hänge, auch schon bevor ich hier einen Thread geöffnet habe, habe ich diverse Sachen versucht.

Ich habe halt parallel auf einem PI getestet ob evtl der CUL einen fehler hat. Auch dort mit einem IObroker PI, sowie einem Fhem PI. Dort ging wie bereits beschrieben alles Problemlos.

Edit: Versucht hatte ich auch schon 2 verschiedene "/etc/udev/rules.d/" Optionen. Einmal mit Gruppenzuweisung, und einmer ID -> Namen Zuweisung

[Beta-User]

Tut mir leid, jedenfalls ich bin mit dem Latein ziemlich am Ende .

Was ähnliches hatte ich nur einmal: Da hat nach einem update plötzlich der Kernel meinen CP2102 (mit dem PI-HM-PCB dahinter) als Braille-Gerät erkannt. Aber da hatte ich dann gar keinen FHEM-Zugriff mehr auf das Gerät, soweit ich mich entsinnen kann. War wohl ein Fehler des Kernels, ich habe damals den Braille-Treiber deinstalliert.

Vielleicht helfen die geladenen Kernel-Module irgendwie weiter, dieser Sache auf die Schliche zu kommen? Es erklärt aber immer noch nicht, warum Abstöpseln hilft?

Weitere Spekulation: Der NUC schubst die mcu im Cube falsch an während des Bootvorgangs? Spannungsspitze oder irgend sowas?

Wenn du irgendwo noch eine alte Festplatte rumliegen hast: Spasseshalber mal ein älteres Debian versuchen? Oder mind. einen älteren Kernel?

Ratlos...

[porty]

Ratlos...

da sind wir schon zwei
Aber vielen Dank für eure Mühen.

Ich Installiere nachher mal den zweiten NUC mit der gleichen OS Version.
Parallel werde ich mal die Debian Jessi "8" auf meinem NUC installieren. Mal schauen ob es was ändert.
Und durchs Bios werde ich nochmal tingeln und schauen was ich noch so finde zum ein/ausschalten

[Otto123]

Keinen Rat zu Lösung aber mir fällt gerade ein:
Ich hatte mal vor einem Jahr mit dem NUC geliebäugelt und war dabei immer wieder darauf gestossen: Dieser NUC wird von debian unterstützt und dieser nicht.
Hast Du mal nach dem System Support geschaut?

Gruß Otto