Dysfonctionnement AEOTECK S-Stick GEN5 plus après reboot

vmath54 · Mars 13, 2021, 1:19

Bonjour,

Je rencontre un problème avec la clé z-wave AEOTECK Z-Stick GEN5 plus, achetée récemment en remplacement d’un Z-Stick GEN5, après reboot de la machine (odroid C4).

Le problème constaté : suite à un reboot (commande ‹ reboot ›, ou redémarrage depuis jeedom), Le démon z-wave est bien actif, mais ne communique pas avec la clé.
Dans la log OpenzWaved, on obtient 4 fois l’erreur ‹ Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s) ›
Je joins la log, en niveau débug.
Un redémarrage du démon ne suffit pas.
Si je débranche la clé et que je la rebranche, puis redémarrage du démon, ca marche !
Donc, il semble qu’il soit nécessaire que la clé soit coupée électriquement pour qu’elle puisse refonctionner.

J’ai voulu remplacer la clé, car j’ai changé la machine : je suis passé d’un odroid C2 (ports USB 2.0) à un odroid C4 (ports usb 3.0). L’ancienne clé ne fonctionnait pas avec un port usb 3 (même problème qu’avec un raspberry 4) ; j’était obligé de mettre un hub USB pour que ca fonctionne.

J’ai essayé de déplacer la clé sur un autre port ; j’ai même essayé de débrancher la clé conBee, pour être certain qu’il n’y avait pas de conflit. Ca n’a pas éliminé le problème.
J’ai aussi essayé de mettre la clé derrière le hub USB, sans plus de succès.

Je n’ai pas de problème d’alimentation électrique de l’odroid.
Concernant la clé, J’ai recopié la conf (appairages, …) de l’ancienne clé vers la nouvelle avec l’utilitaire ‹ Z-Stick Gen5 Backup Tool ›. Ca a fonctionné, elle est capable de gérer mes équipements z-wave.

Concernant la conf de l’odroid, j’applique la règle udev suivante, pour que la clé ait toujours le même nom de device :
SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="ttyUSB-zstick1"
Et j’ai déclaré dans jeedom /dev/ttyUSB-zstick1 comme port clé Z-wave.
J’applique ceci depuis mes débuts en jeedom, au moins 6 ans.

Le problème n’est pas jeedom, mais lié à la clé ou au système.
Voici quelques infos complémentaires :

après boot (donc avec le problème)

# lsusb
Bus 002 Device 002: ID 2109:0817 VIA Labs, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 003: ID 1cf1:0030 Dresden Elektronik
Bus 001 Device 002: ID 2109:2817 VIA Labs, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# ls -al /dev/ttyUSB-zstick1
lrwxrwxrwx 1 root root 7 mars  11 14:53 /dev/ttyUSB-zstick1 -> ttyACM1

# dmesg | grep -i voltage
[    1.914218] reg-fixed-voltage regulator-hub_5v: nonexclusive access to GPIO for regulator-hub_5v

# dmesg | grep -i usb
...
[    3.242742] usb 1-1.3: new full-speed USB device number 3 using xhci-hcd
[    3.398654] usb 1-1.3: New USB device found, idVendor=1cf1, idProduct=0030, bcdDevice= 1.00
[    3.398660] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.398664] usb 1-1.3: Product: ConBee II
[    3.398666] usb 1-1.3: Manufacturer: dresden elektronik ingenieurtechnik GmbH
[    3.398668] usb 1-1.3: SerialNumber: DE1965528
[    3.582756] usb 1-1.4: new full-speed USB device number 4 using xhci-hcd
[    3.636253] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
[    3.636820] usbcore: registered new interface driver cdc_acm
[    3.636827] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[    3.731701] usb 1-1.4: New USB device found, idVendor=0658, idProduct=0200, bcdDevice= 0.00
[    3.731710] usb 1-1.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.773496] cdc_acm 1-1.4:1.0: ttyACM1: USB ACM device

Donc, la clé z-wave est bien reconnue par le système, comme /dev/ttyACM1 ; /dev/ttyUSB-zstick1 pointe bien vers la clé

si je débranche et rebranche la clé, sur le même port

Ca va fonctionner, après redémarrage du démon z-wave
La clé Z-Stick a changé de device : de 004 à 005, et a passé de /dev/ttyACM1 à /dev/ttyACM2. /dev/ttyUSB-zstick1 pointe maintenant vers ttyACM2

# lsusb
Bus 002 Device 002: ID 2109:0817 VIA Labs, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 003: ID 1cf1:0030 Dresden Elektronik
Bus 001 Device 002: ID 2109:2817 VIA Labs, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# ls -al /dev/ttyUSB-zstick1
lrwxrwxrwx 1 root root 7 mars  11 15:39 /dev/ttyUSB-zstick1 -> ttyACM2

# dmesg | grep -i usb
...
[ 2759.805732] usb 1-1.4: USB disconnect, device number 4
[ 2764.172464] usb 1-1.4: new full-speed USB device number 5 using xhci-hcd
[ 2764.321314] usb 1-1.4: New USB device found, idVendor=0658, idProduct=0200, bcdDevice= 0.00
[ 2764.321324] usb 1-1.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 2764.380933] cdc_acm 1-1.4:1.0: ttyACM2: USB ACM device

On a donc exactement la même séquence que lors du boot initial.

Je ne sais pas comment traiter ce problème. C’est gênant, mon installation n’est plus fiable, puisqu’il faut une intervention manuelle en cas de reboot du système.

Je vois 2 pistes pour tenter de pallier à ce problème :

faire en sorte de pouvoir couper électriquement le port USB lors du boot ; je n’ai pas trouvé comment faire
la clé est bien reconnue par le système, même si elle ne répond pas au démon. Elle est vue comme un port série ; je me demande s’il n’est pas possible de lui envoyer une séquence qui permettrait de la forcer à se réinitialiser.

J’ai cherché de la doc pour envoyer des commandes directement à la clé par le port série (/dev/ttyUSB-zstick1) ; je n’ai pas trouvé.

Si vous avez des propositions pour tenter de traiter ce problème, je suis preneur.

Merci …

Fabrice · Mars 14, 2021, 9:57

Bonjour,

Et si vous laissez le port en AUTO, cela ne devrait pas poser du problème du coup ?

vmath54 · Mars 14, 2021, 10:20

Bonjour @Fabrice,

Merci de la réponse. Le problème n’est pas à ce niveau : le plugin z-wave reconnait bien /dev/ttyUSB-zstick1, et /dev/ttyUSB-zstick1 est bien toujours mappé vers la clé /dev/ttyACM1 après boot ; /dev/ttyACM2 si je débranche et rebranche la clé pendant que l’odroid est en fonctionnement.

On le voit ici : l’idVendor et l’idProduct de la clé sont bien rattachés à la clé.
zwave

Par acquit de conscience, j’ai passé le port en mode auto et redémarré l’odroid ; même constat.

J’avais oublié de joindre la log openzwaved en mode démode après reboot, la voila. openzwaved.txt (3,3 Ko)

vmath54 · Mars 14, 2021, 5:30

Je pensais avoir un peu avancé : j’ai trouvé le moyen de gérer l’alimentation électrique du port usb, avec l’utilitaire uhubctrl : https://github.com/mvp/uhubctl

Ca semble fonctionner avec l’odroid C4. Par exemple, avec ma clé qui se trouve sur le port usb 1-1.4, les commandes :
./uhubctl -e -l 1-1 -p 4 -a off
puis
./uhubctl -e -l 1-1 -p 4 -a on
génèrent dans le journal système la même séquence que lors du débranchement/rebranchement de la clé :

[10430.331885] usb 1-1.4: USB disconnect, device number 4
[10430.635037] usb 1-1.4: new full-speed USB device number 5 using xhci-hcd
[10430.783841] usb 1-1.4: New USB device found, idVendor=0658, idProduct=0200, bcdDevice= 0.00
[10430.783851] usb 1-1.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[10430.843563] cdc_acm 1-1.4:1.0: ttyACM2: USB ACM device

Malheureusement, ca ne règle pas le problème coté jeedom, après redémarrage du démon ; alors que le débranchement/rebranchement physique de la clé le règle.

Je suis donc toujours bloqué. Si je remets l’ancienne clé (GEN5, pas une GEN5 plus), ca marche. Je ne sais pas si le problème vient d’une nouvelle clé un peu défectueuse, ou d’une incompatibilité de la GEN5 plus avec l’odroid C4 …

Quand j’ai le problème, la clé est hors de communication de jeedom ; elle est pourtant bien reconnue par le système.
J’aiemrais pouvoir la tester à bas niveau, coté port série.
Quelqu’un sait-il comment faire ?

vmath54 · Mars 15, 2021, 1:24

J’ai branche un analyseur de courant sur le port USB de la clé ; la conso est de 0.08A en fonctionnement normal. Ceci pour 5.14V, ce qui donne une conso de 411 mW.
l’utilitaire uhubctl ne coupe pas l’alimentation contrairement à ce que je pensais, la conso reste à 0.08A.
Je suppose qu’il invalide logiquement le port USB vu de l’OS, ce qui expliquerait les indications du journal système.

Ceci explique pourquoi la manip précédente n’était pas identique à un débranchement/rebranchement physique de la clé …

Le problème reste donc entier. Parfois (rarement), le réseau zwave fonctionne quand même après un reboot à chaud ; il y a donc une petite part d’aléatoire, pour simplifier la chose.

Domatizer · Mars 15, 2021, 1:44

Je pense pas que ton problème soit lié au port, que tu as bien fixé

On dirait comme si tu avais une déconnexion de la clé après que le daemon soit lancé. En effet, si tu débranches et tu rebranches à chaud la clé Z-Wave lorsque le Z-Wave est fonctionnel. Le daemon reste actif et la page santé est en vert alors que la clé ne communique plus et que le réseau n’est plus fonctionnel. Normalement, un redémarrage du daemon, ça repart mais il faut intervenir manuellement.

Là, c’est bizarre !

Ok

Tu as essayé avec le hub non alimenté en externe ?

vmath54 · Mars 16, 2021, 10:09

Oui, j’avais essayé avec un hub non alimenté en externe ; en fait, celui que j’utilisais avec l’ancien dongle, puisque c’était nécessaire à cause de l’incompatibilité avec l’USB 3.

Avec la nouvelle clé, je n’avais pas fait l’essai en utilisant un hub alimenté ; je viens de faire, même punition.

Domatizer · Mars 17, 2021, 12:50

Pourquoi tu ne reprends pas l’ancienne clé ?

vmath54 · Mars 18, 2021, 5:30

Désolé pour le retard, je n’avais pas vu ta réponse.
C’est ce que je ferais en dernière solution.
J’avais changé de clé principalement pour ne pas avoir de hub USB.
Ca m’embete bien d’avoir acheté une clé (55€) pour rien.

Je pense que la clé présente un défaut.
Je n’avais pas signalé dans mon post, mais la led ne clignotait pas en fonctionnement normal.
J’avais pourtant bien coché la case ‹ Led ON/OFF › dans l’utilitaire ‹ Z-Stick Gen5 Backup Tool ›, mais ca ne marchait pas.
J’ai enfin fini par y arriver, depuis cet utilitaire, en cochant/décochant plusieurs fois la case ‹ Enable/Disable ›, alors que cette manip marche nickel avec l’ancienne clé.
Et, surprise, la led ne clignote pas avec plusieurs couleurs en fonctionnement normal, mais reste allumée fixe en vert.

Je viens de déposer un ticket auprès du support aeotec ; je vous informe si j’ai du nouveau.

Domatizer · Mars 19, 2021, 9:46

Je comprends, ça fait cher l’essai.

Moralité : quand ça marche, il ne faut plus y toucher.

vmath54 · Mars 19, 2021, 4:17

Je suis quand même capable de revenir avec l’ancienne clé, sans rien casser …

j’ai contacté le support aeotec, qui m’a répondu.

concernant les leds qui ne clgnotent pas en fonctionnement normal :
C’est normal, le comportement a été changé avec la GEN5+ (je n’ai pas vu l’info dans la doc).

As for the LED, the Z-Stick Gen5+ has a different LED status where the LED status is Amber when charging, or Green when the internal battery is fully charged. If there is a large load of communication, it will blink blue. Old Z-Stick Gen5 cycles red, blue, amber/yellow colors.

concernant mon problème
As for the Z-Stick Gen5 tty port, i found that it depends on the driver that is used in the backend, with this issue, i had one other user start their OS fresh and the problem stopped. Unfortunately the assignment of the Z-Stick Gen5 ultimately depends on the driver used to create the tty port.

Je ne suis pas d’accord avec cela : l’armbian utilise le même driver avec la GEN5 et la GEN5+, et je n’ai le problème qu’avec cette dernière.

J’ai fait un nouvel essai : j’ai lu qu’un appui court sur le bouton de reset de la clé correspondait à un ‹ reset soft › ; j’ai donc tenté, lors du problème.
Banco, ca marche. Dans la log système, c’est les mêmes messages que lors de l’extraction - insertion de la clé.

J’ai remonté ceci au support … je vous tiens au courant si ca donne quelque chose.

Un truc bizarre, qui n’a rien à voir : je ne suis pas notifié quand tu répond à ce fil, alors qu’il est bien positionné à ‹ Surveiller ›…
Dans mon profil, j’ai bien activé ‹ M’envoyer un courriel quand quelqu’un me cite, répond à l’un de mes messages, me mentionne ou m’invite à rejoindre un sujet. ›, et ca marche pour les autres sujets.