Soucis ZWAVE-JS après redémarrage

Bonsoir @Fabrice,

Alors oui j’ai beaucoup utilisé la fonction « remplacer », mais par endroit et notamment sur les déclencheurs de scénario la commande « remplacer » n’a pas fonctionnée. J’ai aussi eu un problème avec 1 ou 2 modules que j’ai redéclaré manuellement et là aussi j’ai dû revoir manuellement les #xxxx# que j’ai généré avec mes essais. Certaines commandes zwave ont changées, il a fallut en ajouter manuellement dans les modules pour retrouver mon ancien fonctionnement. J’ai aussi profité pour faire le ménage et améliorer certaines choses. Je voulais arriver à quelque chose de stable avant de passer en debian 11 pour éviter d’incriminer tout et n’importe quoi en cas de problème plus tard.

Bonne soirée,

Ludomo

1 « J'aime »

Thank you all, and especially you, for this response. I migrated from Debian 10 to 11 and from OpenZwave to ZwaveJS, and every few days, the Zwave network stopped working, leaving me with no choice but to re-interview all the devices.

I configured the controller in SIS mode (and took the opportunity to update it), and now it works perfectly. Thanks again!

Bonsoir

Comme promis plus haut, j’ai fini par trouver les pièces et le temps pour démonter ma vielle smart, sortir son controleur gpio Zwave, disposer d’une clef USB=>TTL, la brancher sur le GPIO, avoir le soft zensys evoqué et essayer la config.

Je vous documente l’ensemble presque autant pour vous… que pour moi si je devais le refaire :slight_smile:

Malheureusement, j’ai pas encore fini le test. Je vais pas pouvoir vous dire dans ce post-là si se mettre en SIC résout aussi le problème du ProtocolInfo avec le GPIO zwave de la smart.

Cependant, voici tout le matériel utilisé et la config réalisée et cela me semble avoir fonctionné.

1). La clef usb=>TTL
https://www.amazon.fr/dp/B07TFSZ3ZP

2). Le cablage :
exactement comme ca : Zwave Cloner (Backup / Restore de vos contrôleurs Zwave) - #132 par antislash78

Et j’insiste qu’il faut bien être alimenté sur le +3.3V comme sur le schéma et pas avec le 5V (ca n’a pas marché en 5V et je ne comprenais pas pourquoi…)
Donc il faut bien des fils, ca ne peut pas se brancher en direct avec le pinout de la clef telle qu’elle est soudée face au pinout de ODroid C4 sur le port à 40 pins
Et comme c’est indiqué, la sortie RX de la clef va sur le pin RX du GPIO. (je n’ai pas mis RX sur TX)


3). Le SW : windows n’a pas le driver de la clef usb => TTL. Je l’ai chargé d’ici

4). Le soft ZenSys proposé + haut
https://aeotec.freshdesk.com/helpdesk/attachments/6091420613

Comme dit Madcow

Donc il faut d’abord aller ouvrir le Setting, prendre le bon port comm + Apply
Puis « Set as SIS ».
Voici le résultat.

Maintenant, je dois avoir un controleur bien configurée avec le SIS. Me reste à voir ce qu’il se passe en lui affectant un module et le redémarrer. Si ca marche, cela voudra dire qu’on peut réparer le pb du ProtocolInfo sur la Smart.

3 « J'aime »

PS : je m’interroge sur un point : de base, la carte gpio de smart est elle suc?

J’ai l’impression que c’est ce que j’ai vu, mais je ne suis pas sûr.
En tout cas, je crois pas qu’elle était ‹ none ›.

Mais si elle était deja SIS, alors j’ai perdu mon temps …

Bonjour,

Merci pour ton retour très détaillé :+1:Cela pourra être très utile à d’autres.

Tout part initialement du constat dans les logs de zwave-js que le contrôleur n’était ni en suc ni en SIS. Mais avais-tu toi-même fais ce constat ?

Car en effet initialement le contrôleur devait être en suc très probablement, et cette configuration perdue un moment pour une raison inconnue. Donc le problème ne concerne pas forcément tous les contrôleurs Smart.

Néanmoins dans tous les cas tu as fait un tuto qui sera utile à ceux qui ont ce soucis.

1 « J'aime »

Bonsoir Madcow,

Sur la smart de test, je ne sais pas dans quel état était le controleur (je n’ai pas pensé à le vérifier dans les logs. En fait, je pense meme qu’il n’y avait pas de log car j’ai réinstallé la carte eMMC plusieurs fois dans le cadre de la migration de mes systemes (cf difficultées à monter mon install restée longtemps en v3). Et au départ de l’install de la v4 sur Debian 11, il n’y a pas de plugin installé, donc pas de log - je pense). Bref, j’ai commencé la manip sans savoir l’état du controleur.

Merci pour le retour sur la doc

Je suis en train de tester avec la smart et 1 module fibaro justement.

Flash de la carte eMMC avec la nouvelle version mise à dispo pour les smarts. Donc

  • jeedom 4.4.8.1
  • uname -a => Linux JeedomSmart 6.5.13-arm64 #odroid SMP PREEMPT Thu Dec 7 18:13:19 CET 2023 aarch64 GNU/Linux
  • lsb_release -d ==> Description: Debian GNU/Linux 11 (bullseye)

Dans Jeedom :

  • installation du plugin officiel de MQTT manager + activation + mise à jour des depedances
    MQTT n’était pas ok. il a fallu réinstaller le broker local mosquito (avec le bouton = automatique) => plugin ok
  • installation du plugin officiel de zwave + activation + mise à jour des depedances + configuration du port du controler (=ttyS1 pour OdroidC2 comme proposé) => plugin ok mais… erreur de config pour une smart sur Debian 11 !
    Pour info, version ZwaveJsui = 9.20.0.bf3bdc3
  • redémarrage du système Jeedom / Smart
  • après redémarrage, plugins toujours mqtt et zwave toujours ok sur la page de la config). Mais évidement, sur la page du plugin zwave, « Le driver Z-Wave n'est pas initialisé, veuillez patienter. Si le message reste trop longtemps, veuillez vérifier la configuration du démon »
  • mise à jour en jeedom 4.4.12
  • option smart reset off sur la config du plugin => pas de résultat dans mon cas. Et pour cause…
  • choix d’un autre port serie => /dev/ttyAML1 retrouvé à tatons et confirmé sur Jeedom Smart Debian 11 Bullseye – Jeedom – Le Blog
  • detection du controleur en tant que « 1 - Sigma Designs (Former Zensys) QuickStick Combo HUSBZB-1 »
  • disparition du message « Le driver Z-Wave n'est pas initialisé »
  • démarrage de l’inclusion d’un nouveau module Qubino FGS213- ZW v3.3 => réussie (avec toutes ses commandes)
  • dans l’onglet santé, j’ai bien un interview complet pour le controleur et le module.
  • redemarrage 1 (arret SW de jeedom via le menu)
  • dans l’onglet santé, j’ai bien un interview complet pour le controleur et le module. Commande immédiatement possible.
  • redemarrage 2 (arret HW brutal de jeedom via la prise)
  • dans l’onglet santé, j’ai bien un interview complet pour le controleur et le module. Commande immédiatement possible.
  • dans les logs zwavejsd, j’ai rien d’exploitable sur son démarrage

A mon avis, ca renforce positivement l’hypothèse que ce bug pourrait être résolu si le contrôleur gpio de la smart pouvait être configuré en SIS dans le cadre d’une migration.

Prochaine étape, je vais essayer sur une config complète et opérationnelle sur v4.4 / debian11, et qui a le « bug » de ce fil.
Je regarderai son log zwavejs, sav jeedom et nvm et après c’est toute la manip ci dessus.
Merci pour les conseils s’il y a autre chose à sauvegarder avant.

Suite à J+2 sur une install existante (jeedom version 4.4.19 sur debian 10) et chargée avec +20 modules :

  • dans les logs zwjsd et autres, je n’identifie rien sur l’état SUC ou SIS.
  • par contre, au reboot, on a bien le symptome habituel : protocoleinfo, puis nécessité de faire l’interview général avec ZwaveJSui, puis box opérationnelle.
  • backup jeedom
  • backup nvm
  • je passe sur une nouvelle box : installation du backup jeedom sur la box en 4.4.19 + bullseye « propre » utilisée précédemment (ccelle ci dessus utilisée à J+1 avec le test du controleur + 1 module, voir Soucis ZWAVE-JS après redémarrage - #128 par Christophe27)

Résultat :

  • installation du backup jeedom ok (NB : la fenetre du log du restore ne se rafraichit toujours pas, mais en relancant un autre onglet, on peut aller consulter le log du restore, et ca dit ok)
  • installation du backup nvm : la, y a probleme
    ==> Did not find a matching NVM 500 parser implementation! Make sure that the NVM data belongs to a controller with Z-Wave SDK 6.61 or higher. (ZW0280)

Pourtant, j’ai récupéré un backup nvm entre 2 box jeedom pour 2 controleur gpio de smart de caractéristiques identique. Je ne comprends pas pourquoi ce restore ne fonctionne pas.

Pendant un temps, j’ai titiller la config du plugin zwaveJS : je crois bien que le backup jeedom n’avait pas configuré le bon port serie. En remettant celui nécessaire aux box smart sur bullseye, ca finit par démarrer le plugin. Mais avec 1 seul module : le controleur. La config réseau ZW est donc partie (ou plutôt, elle n’a donc pas été rechargée)

Bref, reboot de la box.
Cosntat identique : backup jeedom ok, mais controleur vide. Toujours impossible de restaurer le backup nvm sur ce nouveau controleur GPIO de smart.

Dans l’histoire, j’ai perdu de vue ce que devient la config SUC / SIS du nouveau controleur, et je n’ai pas de modules pour dire si au démarrage ca marcherait mieux.

Je en comprends pas pourquoi ce restore de nvm ne marche pas.
==> Si qq’un peut m’expliquer pourquoi et quoi faire, je pourrais avancer sur ce test là. Dans l’intervalle, j’ai gardé cette box avec ses backups chargés mais pas opérationnels.

Prochain essai : juste modifier SUC/SIS sur la box actuellement opérationnelle. C’est sans filet, ca m’embête un peu : j’aurai pas de sav, tant que le backup vnm (via jeedom) des gpio de smart ne semble pas fonctionner.

Un retour préalable serait apprécié.
Merci

Bonjour,

C’est sur ce type de log qu’il faut regarder, ce n’est pas le log standard du plugin :

Tu peux essayer de backuper avec Zwave Cloner (tu n’as pas besoin de l’alu dans ton cas) vu que tu disposes du convertisseur usb. Tu peux aussi passer par PC Controler vu que tu l’as installé (encore mieux).

Ce message d’erreur avec nvm a déjà été observé avec même sdk (sdk visible dans la page du contrôleur après avoir cliqué sur le bouton Noeud). Mais je n’ai jamais compris pourquoi malgré mes recherches.

Bonjour @Madcow
Je n’ai pas compris de quel log du parle, et j’ai regardé le lien, mais je ne sais pas ou trouver ce type de log ?
Pour le backup, je n’ai pas réussi avec Zwave Cloner => le logiciel n’arrive pas à acceder au fichier de sauvegarde ?!?!? alors que je mets un nom tout à fait standard. Est ce windows qui a un probleme avec l’accès à un .bin ?
Quant à PC controler, je ne vois pas quel menu activer pour faire une sauvegarde nvm : peux tu m’aiguiller ?

Ci dessous, dans une seconde réponse, la suite des tests…

Le dernier lien dans le post que je cite.

C’est marqué sur la 1ère page de PC Controller 2eme ligne avant-dernière colonne : NVM backup/restore.

Ce n’est pas le même format de backup que dans le plugin par contre. Il faut faire le backup/restore dans PC Controller.

Ca fait quasi 1 an que j’avais besoin de cette réponse :wink: cool, ca marche !

Oui, le fait de passer le controleur GPIO d’une smart en SIS me semble bien résoudre le bug du ProtocoleInfo sur les smart.
En tt cas ca a marché pour moi !

Comme ci dessus,

Au passage

  • tout à l’heure (post précédant) je n’avais rien dans les logs de zwavejsd ni zwavejs. Comme dit plus haut, je ne sais pas trop où regarder. Alors j’ai regardé ce que dit le tool concernant l’état SIS/SUC. Il dit none pour le Network Role :
    Capture d'écran 2025-03-29 004047
    A noter aussi, il n’y a pas de commandClass en bas
    Capture d'écran 2025-03-29 003957

Ensuite, je fais la manip Set as SIS, comme ci dessus.
Cela change effectivement le Network Role de None à SUC, SIS, NodeIdServerPresent


(nb : j’ai cru un moment que je m’étais trompé en mettant SUC, mais j’ai refait : en mettant SIS, j’ai bien eu « SUC,SIS,NodeIdServerPresent »)

Fermeture du programme, on débranche, on remonte la smart. Elle boote.
Le plugin zwave met du temps à démarrer… suspens… puis c’est le server qui met du temps… encore suspens…
==> Et boom, en 2s, tous les noeuds filaires apparaissent en Complete (évidement ceux radio étaient en ProtocolInfo).
==> la commande d’un noeud filaire a été possible immédiatement.

Pour être sûr, j’ai bien rebooté la box, meme constat. Ca me semble ainsi fonctionnel.

Seul bémol, tout ca s’est fait sur une débian 10, (c’est ma box opérationnelle). Entre autres, la différence avec Débian 11, c’est que je ne peux donc pas mettre à jour mon plugin ZwaveJS ni Mqtt ; ils sont dans l’avant derniere version. Je ne pense pas que ca ait joué un rôle.

Dans un test suivant, je vais passer le controleur présent dans la box smart en debian 10, dans l’autre (celle dont je parlais 2 message ci dessus). J’y avais chargé le backup jeedom, et à défaut de pouvoir recharger le backup nvm, j’aurais le controleur original en SIS. Ca devrait marcher…

2 « J'aime »

Merci pour ton retour :+1:
Tu as bien fait de vérifier les rôles dans PC Controller.

La version de Debian n’a pas d’impact dans le cas présent (la version de Zwavejs-UI sous Debian 10 possède la modification qui a révélé le problème de contrôleur).

Oui SIS met également le rôle SUC. C’est comme un « SUC v2 ».
D’ailleurs avec SUC seulement ça aurait fonctionné.

Bonjour à tous

Je viens de faire à nouveau la manip sur une autre Smart passée en Debian 11 (cf migration d’une installation jeedom 3+ en v4.4 postée précédemment)

Après installation de zwaveJS, j’avais bien le bug du ProtocolInfo au démarrage. (Ticket ouvert en sav, solution proposée= hard reset)

Install réalisée avec +40 modules.

Problème finalement résolu avec le trick du controlleur en SIS comme relaté ci dessus.

Ça fait donc un 3e test positif pour ma part.

Plus tard ce printemps, j’aurais l’occasion de basculer un 4e setup smart pour valider encore.

Ça serait sympa si d’ici là l’UI de zwaveJS avait une commande pour forcer l’initialisation du contrôleur en SIS. Peut être l’idée ensuite serait qu’elle soit reprise par le core jeedom lors de l’initialisation…

Merci
Christophe

Bonjour,

Le moteur zwavejs sur lequel se base le plugin ne propose pas cette fonction.
Là tu es passé par le SDK Zwave qui permet de tout faire (logiquement car c’est le kit de développement utilisé par exemple par les fabricants de module et de contrôleurs).

Car il est totalement anormal, et ce n’est pas la configuration d’usine, qu’un contrôleur ne soit pas SUC ou SIS car c’est sa fonctionnalité première.
Le mystère qui persiste donc dans le cas qui nous intéresse est pourquoi certains contrôleurs sur Smart (ou autre je crois me rappeler d’un cas ici sur Aeotec Gen5) ne sont plus SUC ou SIS.

2 « J'aime »

Bonjour,

Un grand merci @Christophe27 pour la manip !
Je viens de faire de même sur ma box smart en debian 11 et jeedom 4.4.19

Le contrôleur était effectivement en Network Rôle : None.
Action : Set as SIS

Au redémarrage, le contrôleur recherche automatiquement l’ensemble des nœuds du réseau.
En moins d’une minute, l’ensemble des modules alimentés sont remontés.
Les modules sur piles remontent au fil de leurs réveils.
Avec un réseau de 44 nœuds, cela me change la vie.

1 « J'aime »

Bonjour,

J’ai peut être une précision à apporter…
Sur les 3 derniers jours, j’ai cherché à basculer 4 contrôleurs zwave de smart.
Sur les 4, 3 étaient bien sur Controler Role : None et il a suffit de les passer en Sis.

Le quatrième était bien configuré dès le départ.

La différence avec les trois autres n’est pas flagrante au niveau de la smart mais une inscription supplémentaire ce trouve sur le PCB du contrôleur qui était déjà bien configuré : RWE 2036.

A gauche sur l’image ci-dessous.

Voilà, je ne sais pas si cela peut aider.

Bonne soirée

Bonjour à tous,

Super, on avance sur ce problème. Mais la solution décrite n’est pas évidente à mettre en place par chaque utilisateur novice… n’y aurait-il pas un moyen de forcer cette configuration de la carte Zwave en SIS par un script qu’on recevrait du support ?? Perso je ne me vois pas faire toute cette manip, pourtant je bricole, mais là ça me parait de la haute voltige quand même.

En attendant, je fais comme tout le monde, un coup de baguette maqique… mais j’ai arrêté le redémarrage auto de la Smart, et ça pose d’autres problèmes…

Un grand merci à tous pour le travail que vous faites, dans l’attente d’avoir une solution plus simple.

François

Bonjour,

On a fait plus qu’avancer : le problème est identifié et le protocole pour mettre en place la solution défini.

Cette manipulation ne peut être réalisée que par l’intermédiaire du SDK Zwave (pas possible sous zwavejs-UI). Et la partie du SDK qui permet de le faire n’est disponible que sous Windows.
Donc pas possible sous Linux.

Avec une clé zwave cela serait plus facile. En effet la manip en elle-même est très facile et nécessite environ 5 clics. Le plus long est d’installer le logiciel :wink:
Mais mettre en place l’adaptateur n’est qu’à peine plus compliqué en suivant pas à pas les branchements.

Honnêtement cela paraît compliqué car le modop est très détaillé. Mais en vrai c’est plus long à lire qu’à faire.

Bonsoir à tous,
Possesseur d’une SMART que je viens de passer en debian 11, j’ai découvert par hasard ce souci.
Après avoir tout lu, c’est chaud le démontage du module zwave pour l’upgrader !
Au cas où je me lance, est ce que ce module est bien OK : Amazon.fr car celui mis dans le post 123 de @Christophe27 n’est plus en appro (tous les jeedomiens smart sont passés par là certainement, lol).
Merci de vos retours.