Vous avez raison tous les 2.
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 »).