dln35 Posted February 24, 2021 #1 Posted February 24, 2021 Bonjour à tous, Alors voilà j'utilise xpenology depuis les premières versions voilà le matériel et la version: Depuis que je suis passé à 2 SSD en raid ça tourne nickel! Bon tellemnt c'est fiable j'ai basculé toute mon installation domotique en docker sous jeedom et là aussi j'en suis pleinement satisfait, enfin jusqu'à récemment. En effet j'ai un stick zwave aeon 5 et un rfxcom qui fonctionne très bien. J'ai voulu diversifier mes protocoles et installer la cle conbee 2 pour du zigbee. C'est là que les problèmes commencent: un lsusb sur le nas me donne ceci: Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 002: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP2102/CP2109 UART Bridge Controller [CP210x family] Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 011: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO) Bus 005 Device 101: ID 1cf1:0030 Dresden Elektronik Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 003: ID f400:f400 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub donc clé bien reconnu sur le nas, c'est bus 005 device 101: ID 1cf1:0030 Dresden Electronik Par contre et c'est tout mon problème un dmesg |grep tty me donne ceci: dmesg |grep tty [ 0.000000] Command line: BOOT_IMAGE=/zImage syno_hdd_powerup_seq=0 HddHotplug=0 syno_hw_version=DS3615xs vender_format_version=2 console=ttyS0,115200n8 withefi elevator=elevator quiet syno_port_thaw=1 root=/dev/md0 sn=1130lwn008775 mac1=00240130E0FF netif_num=1 vid=0x03f0 pid=0x2d40 [ 0.000000] Kernel command line: BOOT_IMAGE=/zImage syno_hdd_powerup_seq=0 HddHotplug=0 syno_hw_version=DS3615xs vender_format_version=2 console=ttyS0,115200n8 withefi elevator=elevator quiet syno_port_thaw=1 root=/dev/md0 sn=1130lwn008775 mac1=00240130E0FF netif_num=1 vid=0x03f0 pid=0x2d40 [ 0.000000] console [ttyS0] enabled [ 3.807016] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 3.807215] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 8250 [13349.346809] usb 5-2: FTDI USB Serial Device converter now attached to ttyUSB0 [13360.805107] usb 6-2: cp210x converter now attached to ttyUSB1 il me map (je ne sais pas si c'est le bon terme) ma cle sur un ttyS0 et ttyS1. Normalement cela devrait etre sur un /dev/ttyACM0 ou 1 comme beaucoup. Du coup ma clé est reconnu par l'app deconz comme un raspbee et non comme une clé conbee 2 et bien sûr rien ne marche! Donc si je demande votre aide c'est pour savoir si il est possible de "forcer" la reconnaissance sur un port de type /dev/ttyS0 ou 1 et si oui comment faire, je n'ai rien trouvé à ce propos sur le net. merci à tous ceux qui pourront m'aider et j'espère avoir poster dans la bonne section. Quote
JacquesF Posted February 24, 2021 #2 Posted February 24, 2021 Bonsoir, Je ne connais pas ce type d'installation, et de clef, mais les affectations de ressources aux périphériques se font (en principe) avec les règles udev. Il est possible de configurer udev pour affecter un port, une adresse, un nom, etc... à un périphérique plug & play. Ça vaut peut-être le coup de suivre cette piste. Jacques Quote
dln35 Posted February 25, 2021 Author #3 Posted February 25, 2021 merci JacquesF je vais chercher de ce coté. Dans le même ton, qu'est-ce qui fait qu'un périphérique USB utilise tel ou tel driver? Si je réussi à modifier le port avec une règle Udev est-ce que pour autant la communication pourra se faire avec le périphérique USB? je vais chercher de toute façon en l'état rien ne fonctionne. Quote
JacquesF Posted February 25, 2021 #4 Posted February 25, 2021 Bonjour, Un périphérique USB est identifié par un numéro d'identifiant unique en 2 partie, la première identifiant le constructeur, la seconde le produit. Exemple d'un lsusb sur ma machine linux perso : [jacques@jacques ~]$ lsusb Bus 002 Device 002: ID 8087:8000 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:8008 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 002: ID 174c:3074 ASMedia Technology Inc. Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 006: ID 046d:0825 Logitech, Inc. Webcam C270 Bus 003 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 003 Device 003: ID 0b05:17cf ASUSTek Computer, Inc. Bus 003 Device 002: ID 174c:2074 ASMedia Technology Inc. Bus 003 Device 008: ID 2101:020f ActionStar Bus 003 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 003 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub [jacques@jacques ~]$ J'ai un port série sur un adaptateur USB qui est identifié par 067b:2303 et par exemple une webcam Logitech c270 identifiée 046d:0825. Avec ces codes, le noyau sait quels drivers il doit charger pour mettre en service les périphériques. J'ai eu un problème avec un matériel utilisant un port série USB dont le périphérique créé dans /dev n'avait pas les bons droits. Pour corriger ça, j'ai créé une règle udev qui défini pour le périphérique 0590:0090 des droits d'accès sur le device et appelle un script pour exécuter des commandes nécessaires avant de mettre en service le port. Ceci est placé dans une règle nommée 99-obpm.rules et située dans le dossier /etc/udev/rules.d/ À titre d'exemple, voici cette règle : [jacques@jacques ~]$ cat /etc/udev/rules.d/99-obpm.rules KERNEL=="hidraw*", ATTRS{idVendor}=="0590", ATTRS{idProduct}=="0090", MODE="0666", RUN+="/home/jacques/bin/UpdateUsbOBPM.sh" [jacques@jacques ~]$ Il y a de bons tutos sur les règles udev, mais je n'ai pas gardé les liens quand j'ai du régler mon problème. À partir du moment où le device est créé avec le bon nom et les bons droits, et que le pilote correct est chargé, il n'y a pas de raison de ne pas pouvoir y accéder ensuite. Bons tests Jacques 1 Quote
dln35 Posted February 27, 2021 Author #5 Posted February 27, 2021 bon ben j'ai regardé et essayer mainte et maintes solutions mais il semblerait qu'aucune règle UDEV n'est pris en compte par xpenology. j'ai juste essayer dans un premier temps de modifier le nom d'un périphérique USB avec la commande symlink mais rien n'y fait. Que se soit dans /etc/udev/rules.d ou /lib/udev/rules.d rien ne marche (il y a plein de fichiers rules dans ce dernier mais rien n'y fait) Maintenant une chose que je n'ai pas compris et vu dans les regles udev c'est le lancement d'un script! Pourquoi? comment? que mettre dedans j'ai pas tout saisi! Quote
JacquesF Posted February 27, 2021 #6 Posted February 27, 2021 Bonsoir, C'est difficile de savoir ce qui est réellement utilisé dans Xpenology par rapport à un linux classique. En principe, si le démon udev est lancé au boot, alors les règles devraient être traitées. Sur mon NAS il est actif, donc je pense qu'il faut fouiller encore un peu dans l'écriture des règles. Le lancement d'un script via udev permet de faire ce qu'on veut, dans mon cas, le mode 0666 n'était pas appliqué par la règle, j'ai donc créé ce script qui fait ça : #!/bin/bash # # Script appelé par une règle udev pour corriger les droits du port USB utilisé par le lien série # Le code MODE="0666" ne fonctionne pas # Contenu du script /etc/udev/rules.d/99-obpm.rules : # KERNEL=="hidraw*", ATTRS{idVendor}=="0590", ATTRS{idProduct}=="0090", MODE="0666", RUN+="/home/jacques/bin/UpdateUsbOBPM.sh" # /usr/bin/chmod 0666 /dev/usb/hiddev* 2>/dev/null exit 0 Tu peux peut-être contourner ça de la même façon, en mettant ce que devrait faire la règle dans un script. Pour savoir s'il est appelé, il suffit de créer un fichier via ce script. S'il est présent après l'insertion du périphérique, (s'il n'existait pas avant bien sur), alors le script fonctionne. Reste juste à y placer les bonnes commandes. Jacques Quote
dln35 Posted March 5, 2021 Author #7 Posted March 5, 2021 ben un peu pris en ce moment pas eu trop le temps de m'en occuper, juste aujourd'hui. Rien n'y fait! il est possible que je m'y prenne mal mais bon! je crois que je vais arrêter de chercher et d'installer sur un rasp une image pour deconz, ça va être plus rapide merci à tous pour votre aide Quote
dln35 Posted March 5, 2021 Author #8 Posted March 5, 2021 juste pour signaler, image pour raspberry installer et fonctionnel en 1/4 d'heure. tout fonctionne nickel.le problème vient bien de DSM chez moi. Problème résolu Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.