Recommended Posts

Bonjour à tous,

 

Alors voilà j'utilise xpenology depuis les premières versions voilà le matériel et la version:

dsm.thumb.png.38e8d9569b4e76153400e459663cb14b.png

 

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

  • Like 1
Link to post
Share on other sites

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!

Link to post
Share on other sites

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

Link to post
Share on other sites

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

 

Link to post
Share on other sites

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

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.