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:
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?
Hast du es mit einem solchen Define schon probiert ?
/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
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:
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.
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.
Wenn es "nicht" geht, reicht also nicht den CUL rausziehe, 10 sec. warten und wider reinstecken?
was sagt dmesg nach dem wieder einstecken?
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)
[ 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:
[ 341.767550] usb 1-4: USB disconnect, device number 4
Verbinde ich den Cul wieder:
[ 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.
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 ....
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)
Also scheinbar Hardwareproblem ......
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
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.
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
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 ...
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.
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 :)
Mal ganz nebenbei die Idee:
attr initialUsbCheck disable 1
???
Gruß Otto
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...
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 ...
attr initialUsbCheck disable 1ist aktiv, kein Unterschied.
Zitat von: Wernieman am 12 September 2018, 07:39:01
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ß
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
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
Du meinst, beim booten werden Rechte gesetzt .... könnnte sein. Aber es wurde oben geschrieben "jungfräuliche Installation"
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
Vorab, vielen vielen Dank für eure Beiträge und Hilfestellung! Zitat von: Beta-User am 12 September 2018, 10:27:50
......
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.
lrwxrwxrwx 1 root root 13 Sep 12 11:14 pci-0000:00:14.0-usb-0:2:1.0 -> ../../ttyACM0 (abgetippt vom VPN Tablet)
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.
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?
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
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...
Zitat von: Beta-User am 12 September 2018, 14:29:59
Ratlos...
da sind wir schon zwei :D
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 :)
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
Hmm; würde aber nicht erklären, warum es mal geht und mal nicht.
Eines wäre evtl. noch einen Test wert: Kannst du mal testweise einen USB2-Hub dazwischenklemmen?
Naja USB3 Treiber ...
Nabend,
so nächste Test.
zweiten NUC installiert, selbe Problem.
Zum NUC Support, beide werden nicht gelistet.
Nun kommts..
ich habe @Beta-User ´s Idee mal befolgt.. aktiven USB2 Hub angeschlossen, läuft. X Mal reboot, lauft. Ausgeschaltet, eingeschaltet, läuft.
CUL direkt angeschlossen, reboot -> geht nicht.
am Hub angeschlossen, Netzteil vom Hub getrennt (also Passiver Hub), läuft. Reboot, läuft. Fhem reboot, Läuft...
Jaaa.. recht oft läuft :P
Ich glaube echt daran lag es.
Setze den NUC nun neu auf, da ich recht viel dran rum gespielt habe. mal schauen ob es dann noch immer klappt :)
Was ein abartiger Mist....
Schön, dass es jetzt läuft. (Kann sein, dass du das schon geschrieben hast) Gibt es BIOS-Updates für die NUCs?
Ansonsten bei Gelegenheit ggf. noch ein [irgendwie gelöst] hinzufügen...
Schönen Abend noch, Beta-User
Würde dann auf die Idee von Otto Hinweisen: USB3 Problem?
Du könntest ansonsten für die Fehlersuche auch Probieren, wenn noch nicht neu gebaut, den USB auf 2 zu Tackern.
z.B. (ungetestet) mit:
https://www.systutorials.com/241533/how-to-force-a-usb-3-0-port-to-work-in-usb-2-0-mode-in-linux/ (https://www.systutorials.com/241533/how-to-force-a-usb-3-0-port-to-work-in-usb-2-0-mode-in-linux/)
https://ubuntuforums.org/showthread.php?t=2190597 (https://ubuntuforums.org/showthread.php?t=2190597)
Alternativ: Blacklisting vom XHCI
Hinweis: Wie angedeutet, habe es bei Ubuntu/Debian bisher nur in der Theorie gemacht.
Hinweis: Beim googeln aufgefallen, das solche Probleme scheinbar bekannt, unter Linux und Windows. Liegt meistens scheinbar an der USB3.0 des Chipsatzes. Weißt Du, welches USB3 Dein Chipsatz hat?
Edit:
Nette Info beim Googeln gefunden:
http://www.ubuntubuzz.com/2016/06/reset-usb-20-ehci-usb-30-xhci-without-reboot-linux.html (http://www.ubuntubuzz.com/2016/06/reset-usb-20-ehci-usb-30-xhci-without-reboot-linux.html)
Sieh mal einer an. Das scheint irgendwie verwandt mit meinem Problem zu sein:
https://forum.fhem.de/index.php/topic,90872.0.html
Ist auch ein Laptop mit 64er-Architektur, und bisher habe ich es noch nicht gelöst.
LG
pah
danke für die Ideen & suche @Wernieman
habe es nur mal kurz versucht, allerdings erfolglos. Werde es nun aber auch nicht weiter verfolgen. Morgen kommt ein billiger USB2.0 Hub und dann wirds schon klappen :)
Danke nochmal an alle!
Danke für die Rückmeldung und das als [gelöst] markieren.
Ist leider nur ein [hotfix/Würgaround], wäre vermutlich für alle zukünftigen Leidtragenden (die in der Lage sind, die Suche zu bedienen) hilfreich, du würdest den einen oder anderen von Werniemann's Links ausprobieren. Das mit USB3 scheint ja nicht nur ein Problem bei den NUC's zu sein, sondern eben auch bei anderer Hardware...
(@pah: Bitte um Verständnis, wenn weniger Linux-Erfahrene darauf vertrauen, dass Leute mit mehr Kenntnissen evtl. Vorreiter machen ;) . Wie wäre es?)
Von meiner Seite war das an porty jedenfalls nur als Bitte gemeint ;) .
Schönen Abend allseits,
Beta-User
Aloa,
einen Link hatte ich bereits versucht:
https://www.systutorials.com/241533/how-to-force-a-usb-3-0-port-to-work-in-usb-2-0-mode-in-linux/
lspci -nn | grep USB
| cut -d '[' -f3 | cut -d ']' -f1
| xargs -I@ setpci -H1 -d @ d0.l=0
# lspci -nn | grep USB
00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05)
00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 05)
00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 05)
# setpci -H1 -d 8086:8c31 d0.l=0
# setpci -H1 -d 8086:8c26 d0.l=0
# setpci -H1 -d 8086:8c2d d0.l=0
wobei bei mir im falle von "lspci -nn | grep USB" lediglich ein USb controller angezeigt wurde.
00:14.0 USB controller [0c03]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller [8086:22b5] (rev 21)
habe es mit "setpci -H1 -d 8086:22b5d0.l=0 " gesetzt, was jedoch keinen erfolg brachte.
-----------------------
Zum Link: http://www.ubuntubuzz.com/2016/06/reset-usb-20-ehci-usb-30-xhci-without-reboot-linux.html
Glaube das bringt mir in der Form nichts, da ich es ja bei jedem reboot auftritt. Einzige Option wäre es evtl als Autostart laufen zu lassen und direkt nach dem Booten das Script auszuführen.
Edit: Wobei ich gestern wohl überlesen habe: Bios Mode
Ich habe UEFI aktiviert.
Danke!
Eine Anregung noch: Vielleicht könntest du in den Thread-Titel noch den Hinweis aufnehmen, dass es (auch) ein USB3-Problem ist?
Vielleicht so:
[GELÖST] IntelNuc und (u.a.) Max_CUL: Problem mit USB3
Wie gesagt, habe bei mir es nicht Probiert, auf USB2 zu forcen.
Die Bessere (und saubere) Lösung ist ein USB2 Hub. Nur für die Fehlersuche ist eine Softwareumschalten heufig einfacher.
Möchte hier nochmals sagen:
ZitatHinweis: Beim googeln aufgefallen, das solche Probleme scheinbar bekannt, unter Linux und Windows. Liegt meistens scheinbar an der USB3.0 des Chipsatzes. Weißt Du, welches USB3 Dein Chipsatz hat?
Hmmm. Bei dem genannten Laptop ist ein USB 2.0 Hub dran...
LG
pah
Ich glaube bei Dir auch nicht an ein HW-Problem. Die Fehlermeldung ist doch eher eine SF seitige ....
Kann nur damit nichts anfangen (mit Deiner Fehlermeldung), weshalb ich in dem Thread noch nichts geschrieben habe ...
Edit:
Was ich auch nicht kann. Was mir dabei einfällt: Hast Du mal probiert, ob das letzte Zeichen eventuell ein "Unsichtbares" Zeichen wie eben CR oder LF ist?
Ja, das war das Erste. Ich verstehe es noch in keiner Weise...
LG
pah
Wenn es an dem Laptop nie funktioniert hat, ist das m.E. ein anderer Sachverhalt als hier:
Da funktionierte der Cube, wenn er nach dem Booten eingesteckt wurde. Es steht zwar "gelöst" über den Thread, aber tatsächlich gibt es nur einen Workaround.
Sollte man dann nicht diesen Thread für die NUC-Thematik belassen und das Laptop im anderen besprechen? Wenn es am Ende doch dasselbe gewesen sein sollte, schadet das ja auch nicht, es lesen im Zweifel alle an beiden Stellen mit, oder?
EDIT: ich seh' grad, dass ich da nichts schreiben könnte...
Wäre denn ein Kerneldowngrade möglich?
Das will ich nun wieder nicht, so lange die Ursache nicht klar ist.
LG
pah
Schon klar, dass ein Downgrade nicht als Dauerlösung taugt...
Ziel sollte ja eher sein, das eigentliche Problem zu finden, und nach einem allg. Update/Upgrade kann das halt alles Mögliche sein. Wenn es mit einem älteren (oder neueren) Kernel liefe, wären jedenfalls weder Perl noch das allg. Bootumfeld im Kreis der engeren Verdächtigen, oder? Das mit dem älteren war nur der Vorschlag, weil man da eher davon ausgehen kann, dass nicht derselbe Fehler immer noch drinne ist.
Zitat von: Wernieman am 14 September 2018, 11:17:36
Wie gesagt, habe bei mir es nicht Probiert, auf USB2 zu forcen.
Die Bessere (und saubere) Lösung ist ein USB2 Hub. Nur für die Fehlersuche ist eine Softwareumschalten heufig einfacher.
Möchte hier nochmals sagen:
Habe es im Betrieb versucht. Habe den USB 2.0 Hub abgezogen, den CUL eingesteckt und gestartet. Wurde wieder als OPEN gesetzt. dann habe ich es versucht den Port auf 2.0 zu forcen, kein Unterschied. FHEM restart auch keine Änderung. Habe angeschließend im laufendem betrieb einfach den USB Hub zwischen geklemmt, lief ohne Reboot.
Aber wie gesagt, nutze UEFI, damit könnte es evtl zusammen hängen.
Wobei ich nachher mal UEFI Boot deaktivieren kann zum testen. Habe zwar angefangen einzurichten aber .. das neueinrichten würde mich im Notfall maximal 30min kosten von daher versuche ich es nochmal :)
----
ich ändere mal den Thread-Titel damit es eindeutiger wird.
Ich würde denken, das es an UEFI nicht liegt. Würde es wirklich als USB3-Fehler bezeichnen ... und das Betriebssystem unabhängig, da so etwas (laut Google) auch bei Windows passieren kann.
Blöde ist heute beim Testen, das es nicht "das" USB3 gibt, sondern 3 3.0 3.1 3.2 3 und das ganze noch mit Profil Audio, Video, ... etc. ....)
(Hinweis: 3 und 3.0 sind in der Hardware unterschiedliche Versionen ..)