J’ai quelques soucis de ZWAVE pour supprimer des devices qui n’existent plus et que je ne peux passer en Echec ou Fantome ou autre pour les supprimer.
Je suis donc aller mettre mon nez dans le fichier de config zwave zwcfg_0xfb2206e4.xml
Mon dernier device a un nodeid de 203 or je ne le trouve pas dans mon fichier de conf zwave.
Je suis donc allé dans le folder backup du plugin openzwave et j’ai pris un backup du 16/01/2021 donc très récent (2021-01-16-09-50-24_stop_zwcfg_0xfb2206e4.xml). Et surprise, tous mes devices y sont !!!
Mon fichier actuel s’arrête donc au nodeid 186. J’aurais donc quelques questions :
Comment puis je ne pas avoir de soucis quand je teste mon réseau avec les nodeid que j’ai créé après. Je suppose qu’il se base sur le fichier à la racine du folder data et non sur les fichiers backups ?
Comment puis je avoir ce fichier qui commence à dater un peu (plus d’1 an et demi) à la racine du folder data mon pluggin zwave ?
A quoi servent ces fichiers backups ? pourquoi ont ils le mot stop dans leur nom ?
Dans la suite de mes recherches, je viens de faire un test. Mon fichier dans le répertoire data s’arrêtant à 186 alors que mon dernier nodeid était à 203, j’ai tenté l’inclusion d’un nouveau device pour voir le n° qui lui serait attribué. Il a pris le n° 204.
Je suis ensuite allé voir le contenu du fichier ZWAVE, et bien il contenait tous mes IDs post 186 !!! donc il s’est régénéré. A partir de quoi, je ne sais pas mais je retrouve bien tous mes devices dans le fichier. Ce qui me fait dire qu’il n’utilise pas que celui là. Cela ressemble aux actions que l’on trouve sur le pluggin
Et le fait de redémarrer le pluggin me rapatrie cet ancien fichier de conf qui s’arrête à mon nodeid 186. Je ne comprend pas du tout ce mode de fonctionnement !!!
Il s’agit du fichier de sauvegarde de la topologie réseau, afin d’accélérer le démarrage du démon.
Par contre je ne comprends pas pourquoi il ne prends pas la dernière version (blabla_stop) qui est normalement sauvegardée à l’arrêt du démon. A voir si cliquer sur le bouton « sauvegarder la configuration réseau » ne corrige pas ce problème
Cependant, cette voie ne réglerera pas ton problème de devices fantômes.
A savoir par contre qu’il existe des softs sous Windows pour modifier notamment les modules présents dans les clés zwave.
Je viens de faire une sauvegarde manuelle et il m’a bien créé un nouveau fichier manual_zwcfg…
J’ai pas mal redémarré le daemon ces derniers jours et aucune sauvegarde sur ces dates. J’en déduis que le redémarrage ne passe pas par un arrêt du daemon sinon j’aurais des fichiers de backup plus récents…
Bref j’ai regardé un peu mes backups et je ne trouve aucun backup correspondant à celui qu’il me restore à chaque redémarrage. Du coup, j’ai redémarré mon daemon ce matin et j’ai inclus un device pour avoir un fichier à jour !!!
Bien vu. Lorsque le réseau est OK, je te conseille d’arrêter le réseau Z-Wave proprement afin que le plugin sauve la dernière version du fichier config. Ne pas hésitez à mettre cette sauvegarde au chaud.
Si on n’y fait pas gaffe, la box plante un moment ou à un autre et le redémarrage du réseau se fait avec une config plus antérieure. Et là, on repart dans des galères déjà passées. D’ailleurs, je me demande si ce n’est pas à cause de ça que certains viennent dire sur ce forum « une partie de mes modules ont disparus ou sont inconnus ». En effet, si la config des derniers modules inclus n’a pas pu être enregistrée dans le fichier. Hop, ils dégagent au redémarrage! Il faudra attendre le réveil de tous les modules pour avoir la config complète du réseau, qui ne sera pas forcément sauvegardée ! Si des modules sont absents du fichier de config du réseau, ceux-ci seront non fonctionnels jusqu’à leurs premiers réveils après le démarrage du réseau. Pour les modules à piles c’est plusieurs heures, donc c’est long. En attendant, c’est le bordel pendant des heures… L’utilisateur de base, étant ignorant à ceci, n’attendra pas plusieurs heures sans toucher à sa box et redémarre intempestivement le réseau croyant bien faire. Ensuite, viennent tous les bons conseils « change de câble USB, débranche ta clé Z-Wave 10 minutes, exclus/reset/ré-inclus ton module » qui n’apportent pas grand chose malheureusement. Sa galère peut durer un bon moment !!!
Je pense que tu as raison, le souci doit venir de ce fichier !!!
J’ai beau arrêter le daemon, relancer la box ou redémarrer le pluggin, aucun fichier n’est généré !!!
Voici la liste de mes backups. Autant dire que je n’ai pas que des trucs récents. Et donc je me demande dans quelles circonstances ils ont été générés (hormis les 2 manuels) puisque je ne fais fait que des redémarrages de daemon ou de box mais très très rarement des arrêts.
Celui qui est utilisé à chaque redémarrage date d’il y a plus d’1 an dont voici le dernier ID
Par contre, dès que j’inclus un device, il se met complétement à jour. C’est comme ca que j’ai pû faire mes 2 sauvegardes manuellement avec l’intégralité de mes devices
La vérité se trouve donc dans le fichier de config que j’ai sauvegardé manuellement
Je constate au passage que beaucoup de locations et de names ne sont pas remplis.
Je vais donc tenter un autre truc puisque depuis hier que je tente la suppression de noeuds fantomes, je n’arrive plus à un statut Topology Loaded (il a tourné toute la nuit pour avoir une queue à 1600 ce matin en « Driver Initialized »), je vais restorer un fichier une des 2 configs completes.
Par contre, ils ne disent rien sur l’ordre des choses dans la doc mais je suppose qu’il faut restorer le fichier et redémarrer le daemon. Je pensais arrêter le daemon et restorer le fichier pour le redémarrer mais les backups ne sont pas accessibles quand le daemon est arrêté !!
J’aimerais au moins arriver à avoir un fichier à jour quand il redémarre !!!
Quand ton fichier de config est jour, tu peux réactiver la Gestion automatique afin qu’il puisse redémarrer au cas où tu n’est pas là.
Dans le même esprit, il faut faire attention aux noms des équipements Z-Wave dans le plugin, ne pas s’amuser à les renommer régulièrement. Il faut plutôt faire une série renommage puis s’assurer que la sauvegarde du fichier de config contienne bien les nouveaux noms. Sinon, au redémarrage, on se retrouve avec des modules qui reprennent leur noms précédents.
Je viens de découvrir cette fonction backup. Merci
La restauration ne fonctionne pas par le menu du plugin ?
Il faut que fichier à jour soit là /var/www/html/plugins/openzwave/dataz/wcfg_0xd0******.xml à l’extérieur du dossier xml_backups sans le préfixe date_stop_
Ne pas oublier de bien arrêter le réseau avant, sinon le bon fichier risque de nouveau d’être écrasé par une ancienne sauvegarde au redémarrage.
J’ai un bon pré-sentiment que dans ce sujet on va apprendre quelques secrets du plugin zwave.
ça commence à me saouler parce que ça n’est pas cohérent du tout.
Pourtant, j’ai vidé la cache au cas ou mais je ne sais vraiment pas d’où viennent ces infos !!! j’attends toujours un retour du support, j’espère qu’ils pourront me donner une explication…
Il y a un truc bizarre, tu as 2 fichiers de config avec des numéros de série différents0xe0ddd0f1 et 0xfb2206e4. Ils doivent tous avoir le même numéro, y compris les sauvegardes.
Tu n’aurais pas eu une autre clé Z-Wave à un moment ?
Pour moi, tu y es presque.
Bon, tu mets au chaud ce fichier.
Ta vielle config a pourtant une date récente par rapport à l’autre du fichier qui date de juillet 2019.
Bref, pour éviter que les vielles sauvegardes reviennent, je te propose de les enlever toutes du dossier /var/www/html/plugins/openzwave/data/xml_backups/ et de laisser le seul bon fichier dans /var/www/html/plugins/openzwave/data/
Comme tu ne sais pas quel numéro de série est bon, tu dupliques ton fichier de config avec les 2 numéros de série, tu lances ton réseau, tu attends bien sûr le redémarrage, tu renommes un des modules, tu arrêtes le réseau et tu cherches lequel des 2 fichiers qui a correctement été modifié et tu regardes ce que le plugin a copié aussi dans le dans xml_bachkups
Ensuite, tu enlèves celui qui n’a pas été modifié et tu recommences le cycle en renommant de nouveau un autre module. Quand le réseau redémarre, tu vérifies si ton module renommé a bien gardé son nom.
Je n’ai jamais eu d’autre clé ZWAVE donc je ne sais pas ce que faisait cet autre fichier. Je l’ai supprimé. Le bon est le 0xfb2206e4, pas de doute la dessus.
La date récente de ma vielle config, c’est juste parce que le fichier au moment du redémarrage du daemon est mis à jour avec cette vieille config d’où la date qui est celle du redémarrage du daemon. Visiblement, il ne copie pas un fichier ancien mais il fait une mise à jour du fichier existant. Ca semble contredire le fait qu’il utilise un fichier de backup pour accélérer le redémarrage (par copie du moins).
J’ai donc fini par restorer un backup de config ZWAVE complet et récent et au redémarrage du daemon, il semble avoir conservé son contenu (pas comme les autres fois ou c’était remplacé par une config qui datait)
Donc ca semble aller pour le moment. Je n’ai pas envie de l’arrêter pour le moment. Hormis 2 augmentations vertigineuse de queue depuis le redémarrage il y a 36h. Ca monte jusqu’à 2000 pour s’effondrer d’un seul coup. Ca ressemble à un goulet d’étranglement qui se libère soudainement. Comme s’il bloquait sur un device peut être foireux et qui bloquait tout le reste.
Sinon pour l’anecdote, j’ai eu le droit hier à une bonne blague encore. Une pile morte sur un motion sensor de Fibaro et les lumières qui se sont mises à clignoter façon strobo dans une pièce !!! Alors que derrière ce capteur, il y a juste d’un scenario qui allume la lumière quand on arrive dans la pièce donc je ne sais pas ce qui s’est passé. Bref le WAF ne s’est pas retenu pour commenter la situation qui la saoule un peu d’ailleurs mais je résiste.
Voilà, le support m’a contacté jeter un oeil à mes soucis. J’attends leur retour, c’est aussi pour ça que je ne redémarre rien pour le moment. C’est dommage qu’ils n’interviennent pas au moment du problème, ca les aiderait sûrement davantage. J’ai suggéré de peut être répondre aussi sur le forum à quelques interrogations puisque dans mon cas, je ne constate pas tout ce qui est remonté. Cela clarifierait certains points
De mon côté j’ai bien un nouveau backup créé à chaque arrêt du démon, lors d’un redémarrage jeedom par exemple. Et c’est bien celui-ci qui est repris automatiquement au démarrage suivant (on peut quand même sélectionner ensuite celui qu’on veut à ce le bouton backup de la config du plugin, tu peux même supprimer les backups de là ).
Ça sent un truc pas clair de ton côté sur ta config…
J’espère que le support pourra m’apporter une réponse… parce que vu le nombre de redémarrage de jeedom et du daemon auquel j’ai procèdé (enfin depuis 1 mois surtout), ca ne fonctionne pas comme cela chez moi, on le voit bien avec les dates de créations des backups
Quand il est repris, il conserve la date du backup ou met à jour le fichier vs celui de backup ?
Merci pour le retour et la confirmation en tout cas
Je n’ai jamais tenté une restauration de backup donc je ne saurais te dire désolé.
Sinon le fichier repris au démarrage correspond à celui du stop précédent. Et à chaque stop c’est un nouveau fichier.
C’est clair que pour le voir, il faudrait se connecter sur sa box en SSH juste après un redémarrage pour voir les dates de fichier si ca matche entre le backup et celui de conf… si on s’y prend trop de temps après, le fichier aura toutes les chances d’avoir été modifié… Et encore, il doit sûrement le renommer pour enlever la date et le _stop_ du nom du backup et donc changer sa date… sinon par sa taille…bref
Mais c’est pas grave,ce que tu dis semble logique, pas comme chez moi
En fait, le plugin met à jour la config dans /var/www/html/plugins/openzwave/data/zwcfg_0xXXXXXXXX.xml lorsque le réseau s’arrête et il copie une sauvegarde dans /var/www/html/plugins/openzwave/data/xml_backups/
Lorsque le réseau démarre, il prend le fichier /var/www/html/plugins/openzwave/data/zwcfg_0xXXXXXXXX.xml mais ne récupère pas un des fichiers des xml_backups.
Si le fichier /var/www/html/plugins/openzwave/data/zwcfg_0xXXXXXXXX.xml est inexistant, il ne semble pas reprendre un ancien. Je me demande même s’il est capable de reconstruire le fichier de config de lui-même lorsque celui est absent. Si on effectue l’action manuelle de regénérer le fichier, là oui il va redémarrer le réseau et redemander les infos de tous les nœuds.
2000, c’est beaucoup, je ne monte pas si haut, moins de 150 pour 68 modules pendant la première minute. Je ne sais pas si je t’as déjà regardé/lu ce post où j’avais étudié les messages d’erreurs dans le log openzwaved
Tu trouveras des infos sur la queue qui se bloque inutilement. Selon ma compréhension, à chaque commande mal supportée par openzwave, ça bloque jusqu’au timeout (4s par défaut) et pendant ce temps là, la queue monte et entraîne potentiellement d’autres problèmes qui n’auraient pas eu lieu s’il n’y avaient pas ces blocages. Bref, c’est le carambolage des problèmes !
Exactement, lorsque le réseau est stable, je conseille de l’arrêter avant d’avoir un crash et bien mettre au chaud la sauvegarde Z-Wave.
J’adore toutes ces histoires de WAF, c’est croustillant ! Je ne connais pas ton installe (il faudra que que tu fasses un autre sujet), mais le côté stoboscope peut simplement venir de parasites dans le secteur (exemple : mes dimmers Fibaro déconnent exactement même temps lors de l’essorage du lave-linge dans les 10 min avant la fin du cycle, lorsque ça tombe pendant le repas du soir en hiver, le WAF « apprécie et commente »).
