Bonjour,
Il m’est arrivé le même événement sur une VM debian 10.3, clé directement sur 1 USB du PC, …lors d’un reboot de Jeedom.
Je laisse maintenant « auto » dans la configuration de la clé zWave, cela fonctionne très bien.
Ludis
Bonjour,
J’ai une zigate et une aeotec gen5 (en auto dans la config) et un hub usb alimenté depuis plus d’1 an sur pi3B+ et tout va bien donc oui tester avec un auto-alimenté
J ai eut le même problèmes que que toi, j ai pas trouvé la solution
Merci à tous pour vos retours !
@mich0111 @Dreaky @kristobal : je m’attends bien à ce que cela vienne de mon hub. J’aurais d’ailleurs du dès le départ partir sur un hub alimenté 
mais je suis limité en terme de prise électrique dans mon local technique et j’essaie de limiter le nombre de multiprises !
@ludis : je suis bien en auto aussi mais la bascule n’est malheureusement pas auto. Le redémarrage du démon ne se lance pas tout seul malgré l’option cochée. D’ailleurs, peut-on forcé un redémarrage du démon via scénario ? Je ne me suis pas encore intéressé à cette possibilité.
@titof2375 : hub alimenté de ton côté ?
Xav
oui hub alimenté.
1 « J'aime »
Bonjour à tous,
J’ai eu le même souci en utilisant plusieurs clés en même temps (RF Player, Aeotec Gen 5 Z-Wave et Huawei 3G). J’ai changé les câbles usb, j’ai testé avec un hub alimenté ou pas, en direct sur le Pi 3, avec des alim de 3A (une pour le Pi et une autre pour le hub), j’ai mesuré les courants pour vérifier.
En configurant les ports en Auto ou autrement, ça fonctionne au début, mais ça ne tient pas dans le temps. Par défaut les numéros de ports sont attribués dans l’ordre de connexion ttyUSB0 ttyUSB1 ttyUSB2… Dès fois, ils se déconnectent tout seul puis se reconnectent avec un nouveau numéro, le pire, c’est la clé 3G qui prend 3 ports mais seul le 1er fonctionne. Une des clé change de port et prend le numéro d’un autre déjà occupé, résultat, ça plante : les 3 protocoles 433MHz, Z-Wave et 3G tombaient en rade de façon aléatoire. Cela ne tenait pas plus de 3 jours et avec tous les voyants ‹ Santé › au vert dans Jeedom. Un redémarrage et tout rentrait dans l’ordre.
Bref, c’était une vrai galère qui a duré plusieurs semaines !
Une solution est de fixer les ports USB pour que lorsqu’ils se reconnectent, ils reprennent leurs numéros. J’ai encore la clé 3G qui est un peu capricieuse mais c’est rare et elle ne fait plus planter les 2 autres réseaux. Depuis, je suis tranquille.
Pour fixer les ports USB, il faut d’abord déterminer les identifiants des clés avec les commandes suivantes
sudo dmesg | grep 'idVendor\|idProduct\|iProduct\|iSerial'
ou
sudo lsusb -v | grep 'idVendor\|idProduct\|iProduct\|iSerial'
On obtient quelque chose comme ceci
idVendor 0x0658 Sigma Designs, Inc.
idProduct 0x0200 Aeotec Z-Stick Gen5 (ZW090) - UZB
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 Serial (UART) IC
idVendor 0x12d1 Huawei Technologies Co., Ltd.
idProduct 0x1001 E161/E169/E620/E800 HSDPA Modem
Ensuite, il faut créer un fichier 99-usb-serial.rules en mode administrateur dans le répertoire /etc/udev/rules.d/ comme ceci
sudo nano /etc/udev/rules.d/99-usb-serial.rules
On écrit dedans les lignes suivantes,
SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="ttyACM-ZW090"
SUBSYSTEM=="tty", ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="0030", SYMLINK+="ttyACM-CONBEE2", ATTRS{serial}=="DE2xxxxxx"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", SYMLINK+="ttyUSB-TIC" , ATTRS{serial}=="DA1xxxxx"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyUSB-RFP1000", ATTRS{serial}=="A1xxxxxx"
SUBSYSTEM=="tty", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1001", SYMLINK+="ttyUSB-GSM" , ENV{ID_USB_INTERFACE_NUM}=="00"
Les identifiants sont à adapter avec vos résultats obtenus précédemment, un redémarrage est nécessaire ou pas avec les commandes suivantes (c’est la dernière qui marche surtout)
sudo udevadm control --reload
sudo udevadm control --reload-rules
sudo udevadm trigger
De plus, les commandes ‹ udevadm info -a -n /dev/ttyUSBx › ou ‹ udevadm info -n /dev/ttyUSBx › permettent d’obtenir beaucoup d’info pratique
Pour voir les ports série utilisés, il faut taper ls -al /dev/serial/by-id/*, on obtient ceci
/dev/serial/by-id/usb-0658_0200-if00 -> ../../ttyACM1
/dev/serial/by-id/usb-Cartelectronic_Interface_USB_1_TIC_DA1xxxxx-if00-port0 -> ../../ttyUSB0
/dev/serial/by-id/usb-HUAWEI_HUAWEI_Mobile-if00-port0 -> ../../ttyUSB2
/dev/serial/by-id/usb-HUAWEI_HUAWEI_Mobile-if01-port0 -> ../../ttyUSB3
/dev/serial/by-id/usb-HUAWEI_HUAWEI_Mobile-if02-port0 -> ../../ttyUSB4
/dev/serial/by-id/usb-Ziblue_RFPLAYER_A1xxxxxx-if00-port0 -> ../../ttyUSB1
/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2xxxxxx-if00 -> ../../ttyACM0
En fixant les ports, cela fonctionnait pour toutes les clé USB sauf la clé GSM qui a 3 interfaces (3 ports). À chaque déconnexion, le bon port de la clé alternait entre ttyUSB2, ttyUSB3 et ttyUSB4. Et donc mon lien symbolique « ttyUSB-GSM » ne fonctionnait pas à tous les coups (1 chance sur 3). Après moult recherches sur le net, j’espère avoir trouvé la commande magique avec ENV{ID_USB_INTERFACE_NUM}=="00" qui permet de sélectionner la première interface de la clé une bonne fois pour toute.
Le plus simple, je pense, serait de pouvoir choisir le port directement dans la liste donnée par /dev/serial/by-id/ pour le plugin au lieu de /dev/ttyUSB* et /dev/ttyACM* que de se prendre la tête à refaire des liens.
J’espère que ceci vous aidera.
16 « J'aime »
Merci @Domatizer pour cette solution 
Je vais tester cela de mon côté et je te fais un retour !
Xav
1 « J'aime »
Bon finalement pas eu besoin d’attendre 15 jours
Ce matin, nouveau changement de port (ACM0 → ACM1). Ma clé est toujours bien configurée sur mon port ttyUSB-ZWave mais perte complète de communication avec mes modules. Redémarrage du démon et ça repart.
D’autres idées ?
Xav
@Xav-74
Tu ne devrais plus te préoccuper des ports ACM0/ACM1, mais seulement du nouveau ttyUSB-ZWave. Je pense que si tu n’avais pas fixé le port, tu aurais dû changer le port ACM0 en ACM1 pour relancer le daemon. Là, ta clé reste bien configurée sur ton port ttyUSB-ZWave et le redémarrage ce passe bien sur ce port : c’est une bonne nouvelle.
Questions :
As-tu fixé aussi les ports pour les autres clés USB ?
Que disent les fichiers de log openzwave/openzwaved au moment où ça plante ?
As-tu joué avec le Z-wave ? Inclusions, exclusions, mises à jour des voisins, soin du réseau, etc ? Chez moi, ça plante tout le réseau Z-Wave de temps en temps ce genre d’action, un redémarrage et ça repart, mais ce n’est plus un problème USB !
As-tu bricolé quelque chose sur Jeedom ?
Pour le test, il faut vraiment que tu ne touches à rien du tout après le redémarrage du réseau Z-Wave pour vérifier que ça plante bien tout seul.
Merci pour ton aide. Je te confirme que le port est bien resté sur ttyUSB-Zwave et que le redémaarage du démon a suffit. Par curiosité, j’ai juste déroulé la liste des ports et j’ai vu que la clé était sur ACM1 au lieu de ACM0. On est d’accord que cela est normal que ces ports soient toujours visibles dans la liste ?
Pour les logs, rien du tout dans openzwave ! Par contre voici les logs openzwaed (je n’avais pas vu qu’il y en avait 2 et je regardais toujours dans le premier qui était désespérément vide 
)
2020-03-24 07:59:34.606 Always, OpenZwave Version 1.4.0 Starting Up
2020-03-24 08:03:59.407 Error, Node006, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 08:04:03.410 Error, Node006, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 08:04:07.450 Error, Node006, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 08:25:45.478 Error, Node003, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 08:25:49.481 Error, Node003, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 08:25:53.617 Error, Node003, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 08:38:57.396 Error, Node007, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 09:01:13.482 Error, Node005, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 09:01:17.484 Error, Node005, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 09:01:21.487 Error, Node005, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 09:01:26.446 Error, Node005, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 09:05:50.410 Error, Node004, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 09:05:54.413 Error, Node004, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 09:05:58.416 Error, Node004, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 09:05:59.213 Error, Node004, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
2020-03-24 09:06:08.681 Error, Node004, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 09:06:12.683 Error, Node004, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 09:06:16.686 Error, Node004, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 09:06:21.020 Error, Node004, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-24 09:06:25.022 Error, Node004, ERROR: Dropping command, expected response not received after 1 attempt(s)
Je te confirme que depuis l’application de ta méthode pour les ports USB (et donc redémarrage de mon Pi4), je n’ai fait absolument aucune action sur le plugin (inclusions, exclusions, mises à jour des voisins, soin du réseau, etc)
Concernant les horaires :
J’ai ouvert le garage ce matin vers 8h sans aucun souci.
A mon retour, 10 min plus tard environ, je n’ai pas pu l’ouvrir.
J’ai redémarré le démon vers 9h.
Merci encore pour ton aide !
Xav
Oui, c’est normal, ils se retrouvent en double, mais ce n’est pas gênant. Il faut voir ton nouveau port ttyUSB-Z-Wave comme un lien.
Concernant tes log, peux-tu les passer en niveau Warning ou Info ? Augmente aussi le nombre de lignes dans tes fichiers de log si tu veux avoir un peu d’historique. Par exemple, si ça plante et que tu t’en rendes compte quelques heures plus tard, tu risques moins de zapper des infos.
Ne pas supprimer les fichiers log, les vider seulement, sinon les erreurs ne sont plus remontées tant que le daemon n’est pas redémarré !
Peux-tu regarder l’état de la Queue sortante lorsque ça plante. Vérifie qu’elle soit bien à zéro.
Si elle n’est pas à zéro et qu’elle est bloquée ou qu’elle monte, alors les nouveaux ordres se rajouteront à la liste et ne s’exécuteront pas. Dans ce cas, le problème est du côté d’openzwave. Et il faut que ton réseau soit bien clean.
Je vois que tu as les erreurs classiques des gens qui galèrent avec leur réseau, les ordres qui ne passent pas, qui ne sont pas reçus, etc…
J’avais posté des questions sur ce fil si tu veux un peu de lecture
Ça te permettra de te faire un avis sur le Z-Wave avec openzwave
Hello, merci @Domatizer pour cette documentation.
C’est en effet très pratique pour les devices monté en acmX.
De mon côté, il semble que pour le gsm, ça pause problème mais je vais regarder ça gentiment
J’ai remis à jour mon précédent post
Bonjour,
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 ?
Je vous remercie pour votre aide.
Bonjour,
Quel est le type du hub ? 2 ou 3?
Il s’agit d’un hub USB 3 alimenté par une alim de 3A.
Merci
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)