Bonjour,
Utiliser à la place « by-id ».
Puis tester avec et sans soft-reset.
Bonjour,
Alors j’ai tester avec le port By/id
avec et sans l’option soft reset mais rien y fait les modules reste en mode protocolinfo
Là je sèche désolé …
merci quand même 
de mon coté aucun changement, je viens de démarrer la box car elle était complètement plantée (je ne comprends pas pourquoi). Après reboot, toujours pareil, aucun zwave qui fonctionne.
J’ai lancé à nouveau un ticket au support, en laissant volontairement un module non interviewé pour qu’ils puissent constater.
Bonsoir à tous,
même problème chez moi sur une Smarthbox passée en bullseye et avec Zwave-JS.
J’en suis à la 3ème réinterrogation générale pour retrouver mes modules ZWAVE après reboot.
Dans l’attente d’une solution stable, quelqu’un sait-il lancer l’interrogation d’un noeud via scénario afin d’automatiser la remonrée des modules secteur ?
Merci
Bonjour,
Alors j’ai vu qu’il existait une mise a jour du firmware pour ma clef Sigma Desings Aeotec Z stick gen 5 ZW090
j’ai fait une sauvegarde de la clef suivant la procédure How to use Z-Stick Gen5 backup software (Backup, and Restore). : Aeotec Help Desk
puis j’ai lancer la mise a jour du firmware tout a l’air de bien se passer mais une fois le flash fini la clef est HS.
Du coup j’ai acheter une nouvelle clef une AEOTEC Z-stick 7 mais comment faire pour récupérer mon réseau Zwave ?
Bonjour,
Faire un backup NVM de la clé série 500, puis restaurer le backup sur la clé série 700.
Je recommande fortement de mettre à jour le firmware de la série 700 au préalable. Surtout sur Aeotec.
Petite contribution pour appuyer qu’il ne s’agit pas d’un cas isolé mais bien d’un problème reproductible chez plusieurs d’entre nous.
Etant dans le même cas suite à la migration d’une SMART en debian 11 et ZwaveJS j’ai fait un ticket toujours en cours …
Bonjour,
Moi aussi j’ai le même problème sur ma smart depuis le passage en debian 11.
Dès que je relance les dépendances ou le démon de Zwave JS ou que je redémarre la box, l’ensemble de mon réseau Z-wave reste en « Protocol Info » et les nœuds sont non fonctionnels.
J’ai 44 modules…
Pour ne pas réinterviewer tous les nœuds, j’avais trouvé dans le forum une astuce.
Il faut se connecter à Zwave-JS UI puis en bas à droite la baguette magique puis « reinterview all nodes » dans le menu affiché.
Cela relance l’action d’interview pour tous les nœuds.
Ca résoud pas le problème mais au moins ça réduit l’opération fastidieuse de réinterroger nœud par nœud.
Si qqn à la solution finale, je suis preneur…
2 « J'aime »
en effet pas besoin d’un redémarrage de la box, il suffit de relancer le démon pour retrouver ce soucis et que tous les noeuds devient inopérants.
Merci @Fishes pour la commande dans Zwave-JS UI, je n’étais pas encore allé trop fouiller dedans et je ne savais pas qu’il y avait la possibilité de tout réinterviewer. Le soucis c’est que si l’on est pas connecté en local on y a pas accès (en tout cas pour ma part je ne peux ouvrir ceci qu’en étant connecté au réseau local, à distance Zwave-JS UI ne répond pas )
L’avancement coté ticket support est très faible, on me demande de tenter d’exclure et réinclure un module pour voir s’il y a du changement. Je suis assez sceptique car suite à la migration j’avais déjà été obligé d’exclure et inclure chaque module sinon ils ne fonctionnaient pas. Je vais retenter quand même tout à l’heure sur l’un d’entre eux
Merci, ça fait des jours que je me casse la tête la dessus sans pouvoir reproduire sachant qu’il y a 3/4 tickets à ce sujet donc 3/4 installations à vérifier en parallèle.
Il n’y a normalement aucune raison de devoir réinclure les modules lors du passage d’openzwave à zwavejs c’est donc qu’il y avait déjà un souci à la base.
Pour conclure, s’il vous a été demandé de réinclure un module c’est qu’il y a une bonne raison sachant que ça ne reste qu’un test du fait que nous sommes incapables de reproduire ce souci en interne.
désolé que ça soit pris comme une critique ce n’est pas le cas. Je dis juste qu’il n’y avait pas de piste évidente supplémentaire coté support pour l’instant. Je vais faire l’exclusion / inclusion comme demandé, mais sachant qu’elle a déjà été réalisée après la migration je ne pense pas que ça résolve ça malheureusement
Je ne sais pas si ça va résoudre mais ça va permettre d’y voir plus clair.
Ce module est le seul qui n’a pas remonté son niveau de sécurité 
et une erreur est présente concernant ce module alors même que la clé S0 est bien configurée côté ZwaveJS:
le soucis est présent sur les autres modules également (c’est juste que j’ai relancé l’interview sur ceux-là donc ils répondent maintenant, mais sinon ils sont dans le même état protocolInfo)
je lance l’exclusion/inclusion sur le module demandé tout à l’heure en espérant que ça apporte des infos utiles
Bonsoir,
@Aurelien
J’ai le même problème donc si je peux aider en faisant des tests je suis dispo.
Ma config :
RPI4 4Go Sticck Zwave Everspring Gen5, installation Zwave JS sur Debian 11 fraiche, migration laborieuse de openzwave sur Zwave JS avec des erreurs de ma part, obligation systémtique de de réinterview de tous les modules en cas de reboot du RPI. Jamais eu de problèmes avec openzwave (du moins apparemment) depuis plusieurs années.
A ta disposition
suite à réinclusion d’un module Zwave hier, j’ai relancé le démon, tous mes modules sont en rouge en protocole info, mais ils sont opérationnels. C’était pas le cas auparavant
Salut,
Tu as vu qu’en npm il faut setter un path ?
Car ce problème ressemble beaucoup à cette issue même si le contexte n’est pas le même :
Bonjour Aurélien,
j’ai le même problème à chaque relance du démon.
De mon côté, j’ai effectivement trouvé une parade en me connectant à Zwave JS UI et en relançant une interview des nœuds.
Je veux bien te donner accès à ma config si cela peut t’aider…
Mon réseau sous openzwave fonctionnait très bien et une fois ce dernier relancé sous zwave JS UI également.
C’est juste que la stabilité à la relance du démon n’est pas là puisque je dois absolument passer à chaque fois par une réinterview du réseau.