Jeelink wird am NUC nicht angezeigt

[Christian72D]

Ich bin jetzt vom RasPi auf einen Intel NUC umgestiegen.

An den USB Port hängt mein ZWAVE Adapter, mein HM USB Adapter und mein Jeelink.

Code Auswählen Erweitern

christian@fhem:~$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 005: ID 8087:07dc Intel Corp.
Bus 002 Device 009: ID 1b1f:c00f
Bus 002 Device 003: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 002 Device 008: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Was ist jetzt was? Der Jeelink wird natürlich mit der alten Config vom RasPi nicht gefunden.

Code Auswählen Erweitern

Internals:
   Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
   DEF        /dev/ttyUSB1@57600
   DeviceName /dev/ttyUSB1@57600
   FD         15
   NAME       myJeeLink
   NR         338
   PARTIAL   
   RAWMSG     OK 9 8 1 4 151 106
   STATE      initialized
   TYPE       JeeLink
   initMessages
   model      LaCrosseITPlusReader.10.1s
   myJeeLink_MSGCNT 4
   myJeeLink_TIME 2018-09-16 09:43:28
   settings   (RFM69CW f:868300 r:17241)
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1537084667.11403
           VALUE      initialized
   MatchList:
     1:PCA301   ^\S+\s+24
     2:EC3000   ^\S+\s+22
     3:RoomNode ^\S+\s+11
     4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     5:AliRF    ^\S+\s+5
     6:EMT7110  ^OK\sEMT7110\s
     7:KeyValueProtocol ^OK\sVALUES\s
   READINGS:
     2018-09-16 09:57:47   state           initialized
Attributes:
   flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
   initCommands 0a v
   timeout    120,30

[rudolfkoenig]

Was ist jetzt was?

Ich wuerde den vielgescholtenen "usb scan" einsetzen.

[Beta-User]

...oder die "by-id"-Variante in der DEF _aller_ USB-Devices verwenden.

Ziemlich sicher funtioniert auch was anderes nicht richtig.

(Wiki, irgendwo bei "Trick der Woche")

[connormcl]

Deine USB Reihenfolge hat sich am NUC geändert. Und du benutzt bei USB die Namen, wie sie in der Einsteckreihenfolge vergeben werden und nicht by-id oder by-path.
Die Reihenfolge ist nach jedem Neustart u.U. anders und auf jeden Fall anders über Systeme hinweg.

Am besten wäre es, du würdest dir einen UDEV Regelsatz erstellen, der die Dinger anhand ihrer ID auf eigene Namen mappt. Bspw. /dev/JeeLink_EC3000 oder sowas.

Wenns nur darum geht jetzt schnell alles hochzufahren: alles vom USB abziehen und nach jedem einzelnen Anstecken schauen, welche /dev/ttyUSBx dazugekommen ist und das entsprechende Device so in die fhem.cfg eintragen.

[Beta-User]

Deine USB Reihenfolge hat sich am NUC geändert. Und du benutzt bei USB die Namen, wie sie in der Einsteckreihenfolge vergeben werden und nicht by-id oder by-path.
Die Reihenfolge ist nach jedem Neustart u.U. anders und auf jeden Fall anders über Systeme hinweg.

Am besten wäre es, du würdest dir einen UDEV Regelsatz erstellen, der die Dinger anhand ihrer ID auf eigene Namen mappt. Bspw. /dev/JeeLink_EC3000 oder sowas.

Der erste Teil stimmt, aber kannst du mir erklären, welchen Vorteil genau die udev-Variante genau bietet gg. "by-id" (bzw. ersatzweise "by-path")? Mit udev sind es zwei Stellschrauben, an denen man drehen muß...

Wenns nur darum geht jetzt schnell alles hochzufahren: alles vom USB abziehen und nach jedem einzelnen Anstecken schauen, welche /dev/ttyUSBx dazugekommen ist und das entsprechende Device so in die fhem.cfg eintragen.

Teste das mal selbst und stecke bitte zuerst nur den ein, der jetzt an ...USB1 ist . Bin mal gespannt, ob die Anleitung dann so funktioniert...

[Christian72D]

WICHTIG ist keins der drei USB Devices. 

Daher würde ich es lieber dauerhaft und RICHTIG einrichten.

Das die "Reihenfolge" jetzt nicht mehr stimmt hatte ich mir auch schon gedacht.

Wie mach ich das jetzt "by-id" am sinnvollsten?

[pc1246]

WICHTIG ist keins der drei USB Devices. 

Daher würde ich es lieber dauerhaft und RICHTIG einrichten.

Das die "Reihenfolge" jetzt nicht mehr stimmt hatte ich mir auch schon gedacht.

Wie mach ich das jetzt "by-id" am sinnvollsten?

Moin
Wie Beta schon geschrieben hat! https://wiki.fhem.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden
Gruss Christoph

[Wernieman]

Und wenn ein Device keine Seriennummer hat (weil der "Hersteller" Schlampte), geht es über "by-path", also im Pfad anstatt "by-id" das "by-path" schreiben ...

[Beta-User]

Und wenn ein Device keine Seriennummer hat (weil der "Hersteller" Schlampte), geht es über "by-path", also im Pfad anstatt "by-id" das "by-path" schreiben ...

Auch das geht mit "by-id"; schwierig wird es _nur_, wenn man dann auch noch mehrere gleiche solcher Schlamper-Geräte nutzt (oder die Individualisierung als zu schwierig empfindet bei den Geräten, bei denen das nachträglich noch gehen würde). Steht aber auch an der von Christoph dankenswerter Weise korrekt verlinkten Stelle.

Wird echt Zeit, dass es dazu einen ausführlicheren Wiki-Artikel gibt (bastle grad dran rum, das Thema kommt ja grade alle paar Tage mal ).

Würde als Titel "Mehrere USB-Geräte einbinden" vorschlagen und Platz lassen für Windo.*-User.

[connormcl]

zu UDEV:

Es gibt Systeme, bei denen gibt es kein "by-id" oder "by-path" in /dev

Dann benutzt man UDEV und geht im Prinzip den ähnlichen Weg und die Regeln triggern dann auf die ID oder auf den Path, wenn die ID doppelt ist.

Mit UDEV legt man am besten einen "sprechenden Namen" in /dev an. Das hat den Vorteil, dass man auch gleich sieht, wenn etwas nicht dort auftaucht bzw. nicht funktioniert... sonst muss man entweder die Ansteckplätze oder die IDs auswendig kennen oder diese erst in der dann anzulegenden Doku finden...

[Beta-User]

So, Artikel ist online: https://wiki.fhem.de/wiki/Mehrere_USB-Ger%C3%A4te_einbinden

@connormcl:
Du darfst das gerne dort direkt einpflegen oder im Wiki-Bereich eine entsprechende Ergänzung posten. (Neugierig wäre ich allerdings, welche Distri das ist, die keine "by-id" oder Variante davon kennt).

Die ID wiederzufinden (auf Systemen, die das kennen) sehe ich nicht als Problem an, das ist ein einfaches "ls -l /dev/serial/..."... Und ob ein Gerät funktioniert, sieht man ja; ist dort die by-id-Angabe in der DEF, findet man (hoffentlich) auch den notwendigen Befehl wieder .

Und für "sprechende" Namen verwende ich gerne gleich die Tools, um die EEPROMs der USB-Wandler zu manipulieren, da weiß ich dann auch gleich, was für was zuständig ist; der Aufwand ist ähnlich wie für udev, aber die Angaben sind dann auf den Geräten. Das funktioniert dann auch wieder nach einem FHEM-Umzug auf andere Hardware oder einer OS-Neuinstallation .

[Wernieman]

@connormcl

Nur mal als Info .. die by_id/by-path Sache geht auch über UDEV Regeln.  Habe es eigentlich auf allen mir bekannten Systemen mit UDEV gefunden. Mir sind aktuell keine Gegenbeispiele Bekannt ....

Nur mit UDEV kann man auch viel falsch machen. Weshalb ich einen Anfänger immer empfehle, über by-id bzw. by-path zu gehen, bevor UDEV überhaupt angedacht wird.