J’ai areté le daemon , deconnecté ma clé Zwave , déconnecté puis reconnecté la clé Bticino puis taper la cde sur la console :
sudo lsusb
Bus 001 Device 025: ID 1cb0:0020
Bus 001 Device 008: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 1cb0:0020
Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
En passant , j’ai vérifié la puissance de mon alim au secondaire : 2A
Peut être mais la communication ne doit pas être complète car le descripteur du périphérique n’est pas reconnu. Donc pas de com possible entre clef et RPI.
L’alimentation est par contre clairement sous dimensionnée.
J’ai aussi comme box de test un RPI3B+ et une clef Bticino, une clez Aeotec Gen5 et une clef ConbeeII II et j’y ai collé une alimentation de 4A . Tout fonctionne parfaitement. Avant avec l’alimentation de base j’avais beaucoup de problèmes dont certains ressemblent au tien.
En prod j’ai une box qui tourne sur un Intel NUC I5 et je n’ai aucun problème.
Bon à savoir : tous mes dongles USB sont reliés à la box par des rallonges USB de 50cm ou de 1m.
sudo lsusb
Bus 001 Device 006: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 008: ID 1cb0:0020
Bus 001 Device 007: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
sudo lsusb -v (Extrait sur ID 1cb0:0020) ; voici
Bus 001 Device 008: ID 1cb0:0020
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x1cb0
idProduct 0x0020
bcdDevice 0.00
iManufacturer 1 Legrand
iProduct 2 OpenWebNet ZigBee Gateway
iSerial 3 649B75000074040
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0043
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 0
iInterface 0
CDC Header:
bcdCDC 1.20
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
La fin je pense parle d’elle même … (Bus powered). Ton dernier avis stp.
Bus Powered oui mais pas de descripteur donc à priori pas de communication stable. cela étant tu peux essayer de sélectionner dans le plug in le port usb correspondant qui devrait être en standard /dev/tty/USB0
un petit coup de ls -l /dev | grep USB pour lister les ports tty/USB
C’est bien ce que je pensais pas de port USB donc pas de communication entre RPI et la Clef.
Il se peut que l’alimentation ne soit pas suffisante pour donner les 100 mA nécessaires au bon fonctionnement de la clef.
Bonjour,
Nouveau chargeur arrivé (Modèle UGREEN) … Pouvant délivré 4,5A ! Rallonges USB ajoutés sur Clef Z-Wave & clef Bticino
Je suis donc empressé de tester. Et là , toujours pareil ; la clef Bticino ne semble pas reconnu . En tapant les Cdes sudo lsusb & sudo lsusb -v ; les informations sont identiques à celles déjà postées plus haut.
Donc, je suis au point mort. Je prends encore toutes les bonnes idées pour progresser.
Merci
Bonjour. Chargeur connecté au RPI via quel connecteur d’aliementation ?
Sinon il peut s’agir potentiellement d’un pb de dongle USB : levée de doute en mettant le dongle sur une station PC sous win 10 et en utilisant l’application Bticino Myhome Discovery Tool ou bien JClient-Zigbee-OWN
Ou bien d’un pb de configuration Linux : levée de doute a faire après test du dongle sur PC par une sauvegarde préalable de l’installation Linux courante et une réinstallation from scratch
Le point d’alim. sur le RPI est assuré par la connectique Micro USB type B (A gauche sur la photo)
Le test du dongle via PC a déjà été réalisé & concluant. Je l’avais déjà évoqué .
le 21 Mars 2020 / "J’ai fait des essais à partir du logiciel Jclient Zigbee. Le pilotage des volets fonctionne en mode UniCast ou Broadcast. Par contre le mode « Auto » reste en echec. C’était un bon début pour m’assurer que cette clef pouvait bien piloter mes volets.(J’avais un doute sur la compatibilité des mes Inter de Volets ; NILOE 665112) /
Alimentation micro USB = limitation à 3A maxi et encore.
Pour ma part afin que mon alimentation soit full performance je suis passé par une platine SupTronics support de disque SSD connectée au RPI. Cette platine dispose d’un gros connecteur d’alimentation, laquelle alimentation est ensuite transmise au RPI via le port GPIO et un port USB.
A vue de nez je pencherais pour tes pb plutôt sur une installation Debian incomplète ou buguée. Es tu passe sus Debian 10 ?
OK . Je posais cette question car avec une mise à jour Debian 10 tu aurais pu saisir l’occasion de réinstaller LINUX.
Reste le pb alimentation. Tu as bien changé la source mais c’est la « grosseur du tuyau » qui alimente les composants du RPI qui constitue la limitation (selon la norme 2.5 A pour du micro USB). Théoriquement en cas de pb alimentation tu devrais avoir une alerte remontée par le RPI mais j’ai pu constater par le passé que ça n’était pas le cas. Nos dongles USB consomment 100mA et en pointe (émission prolongée par exemple) deux fois plus.
Pour solutionner ce sujet deux possibilités: :
celle que tu as adoptée mais qu’il faut pousser jusqu’au bout comme je l’ai fait avec une platine SSD
passer par un hub USB2alimenté sur lequel tu branches tes dongles USB.
Ce n’enlève pas encore un doute sur la configuration LINUX . En effet l’absence de descripteur retourné par le dongle ou reconnu par Debian lors de la commande lsusb m’interpelle. Cela veut dire que le Dongle n’est pas correctement installé au niveau logiciel. Et là j’atteins les limites de ma maigre compétence en driver UNIX (il y a 30 ans j’aurais fait mais les longueurs du temps ont fait leur œuvre de RAZ)
OK , merci encore. J’ai pris connaissance de la solution platine SupTronics et par conséquent d’avoir un autre point d’alim … pas mal mais nécessite de la modif Hardware , le tout tient-il dans un boitier ?
Je vais faire davantage d’autres tests pour approfondir … Je ne manquerais pas de vous tenir au courant.
Si quelqu’un d’autre passe par là , il peut apporter son expérience. Tout est bon à entendre …