Je rebondis sur ce post car, j’ai une clé 3G Huawei sur un hub USB alimenté connecté à un Raspberry Pi 3B, et au bout de quelques jours, tout fonctionne parfaitement pendant quelques jours puis Jeedom ne trouve plus la clé.
Elle n’apparaît plus dans les ports proposés dans le plugin SMS et lorsque je fais sudo lsusb -v | grep 'idVendor\|idProduct\|iProduct\|iSerial' sur le Raspberry, la clé 3G n’apparaît plus (elle apparaissait avant) et voici ce que j’obtiens :
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 Serial (UART) IC
iProduct 2 Interface USB -> Compteur
iSerial 3 C10335
idVendor 0x0658 Sigma Designs, Inc.
idProduct 0x0200 Aeotec Z-Stick Gen5 (ZW090) - UZB
iProduct 0
iSerial 0
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
idVendor 0x05e3 Genesys Logic, Inc.
idProduct 0x0610 4-port hub
iProduct 2 USB2.0 Hub
iSerial 0
can't get debug descriptor: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
idVendor 0x2341 Arduino SA
idProduct 0x0010 Mega 2560 (CDC ACM)
iProduct 2 Arduino Mega 2560
iSerial 220 8543035363135110E1D2
can't get debug descriptor: Resource temporarily unavailable
idVendor 0x0424 Standard Microsystems Corp.
idProduct 0xec00 SMSC9512/9514 Fast Ethernet Adapter
iProduct 0
iSerial 0
idVendor 0x0424 Standard Microsystems Corp.
idProduct 0x9514 SMC9514 Hub
iProduct 0
iSerial 0
can't get debug descriptor: Resource temporarily unavailable
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
iProduct 2 DWC OTG Controller
iSerial 1 3f980000.usb
Sur le hub alimenté, j’ai la clé 3G, une clé Aeotec Zwave+ et un module teleinfo.
J’ai également un RFLink connecté directement sur le Raspberry.
Pensez-vous qu’il puisse s’agir d’un problème de ports comme décrit ci-dessus, sachant qu’il n’y a que la clé 3G qui pose problème et qu’elle disparaît complètement des périphériques USB de mon Raspberry ?
Possible que ce soit ça le problème.
Il vaut mieux prendre un hub en USB 2.
Je viens de faire le test sur un NUC. Sur un USB 3 ça ne marche pas alors que sur un USB 2 ça marche.
Merci pour ton retour @mich0111.
Saurais-tu ce qui pourrait faire que ça cloche avec ma clé 3g, le raspberry et un hub usb 3.0 ?
Ce qui est bizarre c’est que ça fonctionne pendant un certain temps…
La plupart des clefs Aeotoc Gen5 vendues avant le mois de mai 2020 sont incompatibles avec le sport USB3. Pour avoir une clef compatible il faut en acheter une qui le mentionne explicitement. Hélas Aeotec n’a ni modifie ses références ni son serial number pour permettre de distinguer les clefs last release des clefs ancienne release.
Et pourtant il y a bien une modification hardware de ces clefs (résistance de pull au 3.3V plutôt qu’au 5V)
Pas mieux que @jebidouille.
Tu n’as qu’à faire l’essai, directement sur ta machine (si tant est que l’alim le supporte) puis sur port USB3.
Résultat, ça marche, ça marche pas.
Je l’ai connecté directement sur le RPi pour voir si ça fonctionne.
J’ai acheté la clé Aeotec ZWave il y a 1 mois et j’avais déjà ce soucis avant…
Je vais quand même pouvoir voir si en direct sur le RPi ça fonctionne mieux, sinon, je tenterai un hub USB2.0…
Merci pour vos réponses en tout cas !
Quand je disais « ça marche », je voulais dire « c’est noté », c’est vrai que dans le contexte et vu ton dernier message, ça peut porter à confusion…
Du coup, j’ai édité mon message…
Avec les programmes 2mqtt, il est possible de renseigner dans le fichier config directement le chemin de la clé avec leur ID. Et donc ne pas avoir besoin de créer des alias. Voir dans Autre méthode ici
Salut @Domatizer,
j’ai appliqué ta méthode pour fixer les ttyUSB, c’est top, merci pour le tuto très clair
J’ai juste une question:
Après reboot du Pi, je vois toujours dans les menus déroulants des plugins Jeedom, pour le chois des passerelles USB, les versions ttyUSBX (chiffres) + les versions renommées ttyUSB-XXX (lettres),
est-ce normal d’avoir ces doublons ?
Je pensais qu’avec ta méthode il n’y aurait que les « SYMLINK » de visibles dans les menus côté interface utilisateur… Mais peut-être que je me trompe ?
Merci pour tes lumières !
cf. ci-dessous:
Il y a à chaque fois les x2 possibilités pour un même dongle.
EDIT:
je suis sur Rpi 4b 8Go rev. 1.4 (Alim 3A) Buster 10 Jeedom 4.1.28, avec Hub USB 2 (alim dédiée 2A)
Merci. C’est super de voir que cette méthode aide de nombreuses personnes.
Malheureusement, tous ceux qui ont plusieurs clés USB sur du matériel DIY sont confrontés à ce problème et même ceux qui disent qu’il n’ont pas (encore eu) de soucis. Et ils vont tous devoir passer par ici…
Oui, c’est normal. La méthode ne fait que rajouter des ttyUSB supplémentaires. Donc, ils sont tous présents dans la liste.
Ah ! tu me rassures Merci. J’avais peur d’avoir oublié un truc.
Du coup, j’ai quand même sélectionné à chaque fois la nouvelle version « lettre » du ttyUSB dans les config de chaque plugin concerné, en laissant les version « chiffre » de côté…
Oui, ils ne s’en sont pas encore rendu compte en simulant une panne de courant par exemple.
Ta méthode pourrait d’ailleurs faire parti d’une sorte de super tuto « check-list » pour montage de config DIY. Quand je vois tout le chemin parcouru pour monter ma propre config DIY, qui heureusement est stable maintenant, je me dis que ça vaudrait le coup de synthétiser les étapes clefs comme celle-ci.
C’est toujours une question de temps, tic - tac - tic - tac
Il y a quelques jours encore je figeais l’IP dans le Raspberry pour m’éviter d’autres soucis (je pensais bêtement que le DHCP du routeur avec enregistrement IP fixes suffisait, mais non en cas de reboot après une panne de jus, si le Rpi redémarre avant le routeur - ce qui est en pratique toujours le cas - alors il s’auto-assigne une IP exotique et n’est plus accessible sur le réseau local… )
Et il y aurait tant de choses à faire à lister: désactiver Bluetooth et wifi du Pi, prévoir alim 3A, prévoir hub USB2 avec alim 2A, …
Bref !
EDIT:
je me demande d’ailleurs comment cela se passe avec les box « officielles », la dernière Atlas par exemple. L’équipe Jeedom a-t-elle mis au point quelquechose pour éviter le changement d’affectation des ttyUSB ? A priori cela va dépendre de la configuration de chaque utilisateur, des différents dongle reliés, etc…
Oui, tout a fait. J’avais pensé faire une présentation de ma domotique en référençant mes différentes galères avec ce genre de posts. Je trouve que j’ai bien ramé à chaque étape. Et c’est pas fini.
Étant un utilisateur exigeant, je ne veux pas de limite, il me faut toutes les options PRO. Et s’il a un truc bancale ou qui n’est pas tip-top, je suis sûr de me prendre des poteaux ou des nids de poules.
Bref, utiliser un NUC et oublier tout le reste.
Avec la box seule, ça doit passer, les contrôleurs intégrés Z-Wave/ZigBee ne sont pas en USB. C’est lorsqu’on commence à rajouter plein de clés que les ennuis commencent. Pour peu que certaines se déconnectent toutes seules, c’est la fin. Ça part dans les discussions : ton hub est-il alimenté ? , est-il en USB2, as-tu un RPi4, as-tu blablabla ?
A propos des hubs, je suis revenu à des modèles non alimentés : j’en ai 2 de 4 ports comme celui-ci https://www.amazon.fr/Sabrent-HB-MCRM-480Mbit-Noir-concentrateur/dp/B00L2442H0 et plus de souci depuis quelques mois. Avec 7 dongles, j’atteins tout juste les 500mA, donc en faisant 2 groupes, c’est bon je suis bien en dessous et avec des vrais ports USB sur NUC.
Bonjour @alexcrp,
J’ai une clé Huawei E3372h-153.
Il se trouve que ça marche, mais je ne sais plus pas quel miracle… J’ai mis des documents de côté et notamment ce tuto, je crois que c’est celui que j’avais utilisé…
Merci en tout cas.
Quand je disais « ça marche », je voulais dire « c’est noté », c’est vrai que dans le contexte et vu ton dernier message, ça peut porter à confusion…
: