Changement inopiné port USB clé ZWave

Merci @Domatizer pour cette solution :+1: :+1:
Je vais tester cela de mon côté et je te fais un retour !

Xav

1 « J'aime »

Procédure mise en place, merci @Domatizer !!
Je te tiens au courant d’ici 15 jours :wink:

@Domatizer

Bon finalement pas eu besoin d’attendre 15 jours :frowning:
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.

@Domatizer

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 :face_with_hand_over_mouth:)

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)

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 !

Ravi pour toi.
Pense à clore ton sujet.
Bon weekend

:sweat_smile: 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…

:joy: :joy:

Sorry

Hello

Confronte a ceci sur ma vm mqtt avec 2 clés (zwave et zigbee) j’ai donc appliqué ta procédure.

Merci bcp !!!