Bonjour Madcow
Pourquoi est-ce que disposer d’un backup NWM permettrait de résoudre le problème du protocoleinfo (+ réinterview à chaque reset)?
Dis autrement faut-il simplement faire un backup/restore NWM pour se débarrasser de ce problème de réinterview ?
Merci
Ou dit encore autrement, faut-il simplement changer de contrôleur ZWave après avoir réussi un export NVM pour remplacer le contrôleur interne ?
Merci
Bonjour,
Ce n’est pas ce que j’ai écrit.
Pour le moment la seule solution qui semble fonctionner est un hard reset du contrôleur.
Cependant, celui-ci efface totalement le contrôleur.
Le raisonnement est que le restore d’un backup NVM pourrait permettre d’éviter de réinclure les modules après le hard reset.
Il faut tester c’est la seule façon de savoir si cette méthode (qui en théorie fonctionne) est applicable.
1 « J'aime »
Bonjour,
premier feedback sur l’hypothèse du resore NVM :
Je rappel que je test avec une Box SMART avec antenne Zwave interne d’origine.
Ok, j’ai pris mon courage à 2 mains mais avec un peu de réflexion avant le hard reset,
Pourquoi ne pas tester si mon restore NVM fonctionne avant de vider mon antenne :
Et bien ma sauvegarde n’est pas compatible et refusée par la fonction de ZwaveJS_UI
Je n’ai pas eu la présence d’esprit de faire une capture du message d’erreur dans la fenêtre rouge qui n’a durée que quelques secondes.
Il y a bien une option que je n’ai pas activé pour ignorer la vérification de la sauvegarde, mais pour moi je passe mon tour en attendant d’avoir du temps à perdre pour gérer toutes les ré inclusions …
Bonjour,
Le backup NVM avait bien été réalisé avec le plugin ?
Tu pourrais retester pour nous donner le message d’erreur ?
Bonjour madcow
Est-ce que le test suivant serait intéressant pour vous :
J’ai deux smart, installer sur devianne 11 avec un jeedom 4.4 (de mémoire, je le vérifierai).
Sur la première j’ai donc zwavejs qui tourne avec l’ensemble de mes modules (la Smart de production).
Puisque je peux faire une sauvegarde NVM et un backup de l’instal jeedom, pourquoi ne pas charger tout ça dans la seconde smart ?
Je précise que la seconde smart disposerait d’une install toute propre avec l’image à flasher produite par le support. Du coup je me dis qu’il n’y a même pas besoin de faire ce hard reset.
Que pensez-vous de ce raisonnement et est-ce que le test vous intéresse ?
Merci Christophe
1 « J'aime »
Bonjour,
En effet cela permettrait déterminer dans un 1er temps si un backup NVM réalisé sur un contrôleur qui a le problème est viable.
Et ensuite en effet une fois la 2eme smart remontée avec le backup Jeedom de la 1ère smart on pourrait tester en réel si l’idée est bonne (hard reset puis remontage backup NVM sur la 1ère smart). Si cela ne fonctionne pas il y a la 2ème smart opérationnelle.
Donc 2 tests 
On peut donc en déduire que le contrôleur Zwave de la Smart n’est pas compatible avec les fonctionnalités proposées par ZWaveJS_UI ?
J’avais mis de coté un Retex de Akenad qui traite de ce sujet de compatibilité :
J’ai même acheté d’ocase une clef ZStick5 mais n’ai encore rien testé avec …
Bonjour à tous,
partagez vous le même constat ?
Après reboot de ma Smart, j’ai bien tous mes équipement Zwave en « Protocolinfo » comme plusieurs d’entre nous
MAIS
Tout mes équipements fonctionnent : Je peux les commander via dashboard ou design et les retours d’états sont rafraichis ???
En fait, pour moi, seul les statuts de la page Santé Zwave m’oblige à faire un réinterview global pour faire propre, mais je ne constate aucun dysfonctionnement.
Je vais laisser dans cet état pour voir, tant que je ne constate pas de problèmes …
Ce n’était pas le cas au départ du constat de Bug, est-ce un effet bénéfique de la dernière mise à jour ??? …
1 « J'aime »
je crois déjà avoir eu ce cas : après un reboot (ou redémarrage du plugin je ne me rappelle plus) j’avais mes équipements en protocol infos, et ils marchaient.
Enfin je me suis rendu compte que certains marchaient (un fibaro pour la lumière, pour une porte de garage), mais les wallplug eux ne marchaient pas. Ils étaient tous dans le même état protocol info.
J’ai attendu un long moment mais l’état protocol info n’a pas changé, j’ai relancé l’interview et tout est rentré dans l’ordre (jusqu’au prochain reboot)
Bonjour,
Désolé pour ma réponse tardive.
Merci pour les infos.
Quelle est la version de Zwavejs-UI (pas celle du plugin) ?
C’est bizarre. Normalement il n’est pas possible de backup/restore d’un contrôleur à un autre si l’un est avec un sdk inférieur à 6.61 et l’autre supérieur à 6.61. Mais tant que tu restais du même côté de sdk (comme ici en sdk 6.51) c’était possible.
Or, d’après ton message, ce n’est plus possible du tout réalisable si le SDK est inférieur à 6.61.
Ca peut être dû aussi au « blocage » du contrôleur que tu rencontres.
Il y a bien d’autres possibilités mais il faut pour cela un adaptateur usb pour brancher le contrôleur de la smart sur un PC.
@Aurelien : vous avez fait des tests de votre côté pour savoir si la fonctionnalité nvm est toujours utilisable sur Smart ?
Salut,
Si ceci peut aider:
1 « J'aime »
Bonjour, je viens rajouter ma pierre à l’édifice et reporter exactement le même problème.
J’ai mis à jour mon RPI (Raspberry Pi 4 Model B Rev 1.2) sur Debian 11 et migré mon installation de openzwave à zwavejs. Mon contrôleur Zwave est une clé USB Aeotec Z-Stick Gen5 (ZW090).
À chaque redémarrage de mon RPI, tous les périphériques restent bloqués sur ProtocolInfo. Aucun ne répond aux ordres du contrôleur. C’est parfaitement reproductible à chaque redémarrage. La seule solution de dépannage que j’ai trouvé est de ré-interviewer tous les périphériques, ce qui n’est pas une solution pérenne.
Je n’avais absolument aucun problème avec openzwave (comme quoi les nouveautés ne sont pas toujours bonnes à adopter).
Je vois beaucoup de messages ici concernant les boxes Jeedom mais très peu à propos d’une installation custom sur RPI. J’ai lu des choses sur le hard-reset mais je suis frileux à devoir tout ré-inclure mes périphériques. Quelqu’un a-t-il essayé de faire un backup avec l’outil de Aeotec, puis un hard-reset et un restauration ?
Bonjour,
Il faudrait jeter un coup d’œil au driver log au démarrage du démon du plugin pour voir s’il n’y a pas un module qui met le bazar.
Pour info, zwavejsui existe depuis 4-5 ans donc ce n’est pas vraiment nouveau. Tous les systèmes domotique Zwave l’utilisent actuellement (hormis Fibaro). Ils utilisent le SDK officiel et font partie du consortium Zwave. Tout le contraire d’OZW qui était basé sur du reverse-engineering.
Bonjour Sydidelot,
tu pourrais tester de faire une sauvegarde puis une restauration sans le Hard reset.
J’ai l’impression que le risque d’être obligé de tout réinclure est plus faible (mais jamais nul)
Si cela fonctionne, tu pourra intégrer le hard reset avec moins de risques (de mon point de vue)
Dans mon cas, avec ma Smart et Zwave interne, je l’ai fait mais le restore refuse mon Backup.
Du coup je n’ai pas pu aller au bout mais je n’ai pas été obligé de tout réinclure en vivant avec le bug …
Je te remercie pour ta réponse et pour ton aide ! J’ai activé les logs et redémarré le RPI :
zwavejs.log (59,8 Ko)
Je n’ai rien vu qui m’a sauté aux yeux mais je n’ai certainement pas l’entraînement nécessaire pour lire ce genre de logs.
Je peux fournir d’autres infos si nécessaire.
Merci pour ta réponse ! Je vais attendre un peu pour voir si des informations utiles peuvent être extraites des logs avant de faire le reset.
Merci.
Comme ça avec un œil absolument pas d’expert je vois 2 anomalies potentielles :
- ton contrôleur n’est ni SIS ni SUC.
Il faudrait le configurer en SIS :
My Z-Stick Gen5 cannot be put into Inclusion Mode (Primary Controller) : Aeotec Help Desk - tes clés S0 et S2 ne sont pas trouvées.
Hello,
Je peux me tromper mais selon moi si les clés de sécurité ne sont pas trouvées c’est parce que le contrôleur n’a pas le rôle primaire (ni SUC etc… comme déjà évoqué).
1 « J'aime »