Merci pour ton analyse. Maintenant que j’ai arrêté le chauffage je vais pouvoir analyser tout ca en détail. La semaine de boulot redémarre, il faut juste que je trouve un moment.
Je te tiens au courant
Des nouvelles, des bonnes en plus.
Suite à un petit souci décrit ici SensorBinary report non reçu avec Fibaro Motion Sensor
J’ai utilisé l’info Burglar (classe 113) au lieu du Sensor Binary (classe 48) pour connaître l’état du capteur de mouvement de façon plus sûre que 99.5% 
Ensuite, je me suis rappelé que pour ces modules Fibaro Motion Sensor, j’avais rajouté dans le fichier config ceci
<!-- COMMAND_CLASS_ALARM (0x71) AlarmCmd_Get not supported -->
<CommandClass id="113" getsupported="false"/>
Et bien, il n’y a pas de AlarmCmd_Get lors du réveil du module comme prévu mais openzwave continue de recevoir les valeurs des paramètres de la classe 113. Donc, avec un getsupported="false dans la config du module, ça fonctionne tout de même 
Ainsi, j’ai fait de même pour tous les capteurs de portes. Même avec un getsupported="false pour la classe 113, les valeurs 22 et 23 du paramètre Acces Control remontent bien. D’ailleurs, cela solutionne le problème des portes qui se ferment toutes seules lors du premier réveil en évitant que Access Control prenne la valeur foireuse de 254 Door/Window Sensor 2 se ferme tout seul lors du 1er réveil - #2 par Domatizer
Lors du permier réveil, je vois bien l’info dans le log indiquant que ce n’est pas supporté, logique.
Info, NodeXXX, AlarmCmd_Get Not Supported on this node
Mais, ensuite, openzwave récupère de tout même ces infos.
Je ne comprends vraiment pas bien la logique.
Finalement, le nombre d’erreurs qui font bloquer la queue plusieurs secondes se rapproche de zéro…
Remarque : j’ai fait la dernière mise à jour openzwave croyant qu’il ne s’agissait que de la doc. Tous mes modifs des fichiers config on été écrasées ! Je m’en sui aperçu plus tard lorsque j’ai refait des inclusions. Les dépendances n’ont pourtant pas été relancées. Arrff
Ca, ca m’aurait LEGEREMENT énervé.
Bonjour,
Il ne s’agit bien que de la doc (donc pas besoin de s’enerver) mais juste a chaque mise a jour les fichiers sont remis dans le meme état que le plugin donc tout modification sera forcement perdu a chaque mise à jour
Donc ca va, on ne s’énerve pas ^^
D’t"facon, m’en fout, je mets plus à jour ^^
Épisode de fin
Comme je l’ai écrit précédemment, si on indique dans le fichier config du module que certaines classes ne sont pas supportées, les informations concernant ces classes remontent tout de même.
J’ai rajouté la ligne suivante pour les classes qui bloquent systématiquement et inutilement la queue Z-Wave lors du premier réveil après le redémarrage Z-Wave.
<CommandClass id="xxx" getsupported="false"/>
Liste des fichiers que j’ai modifié
zwa008.txt (7,1 Ko)
eur_spiritz.txt (5,5 Ko)
sp816.txt (760 Octets)
fgbs222.txt (12,2 Ko)
fgd212.txt (21,9 Ko)
fgdw2.txt (8,0 Ko)
fgmszw5.txt (16,3 Ko)
fgs223.txt (16,7 Ko)
fgwpfzw5.txt (15,5 Ko)
ZMNHNDx.txt (6,4 Ko)
ZMNHYDx.txt (8,3 Ko)
ZMNHJD1.txt (4,9 Ko)
Liste des fichiers que je N’ai PAS modifié (inutile de les copier 
)
zw100.txt (23,9 Ko)
fgkf601.txt (12,4 Ko)
Ces fichiers de config sont à renommer en .xml au lieu de .txt (j’ai dû changer l’extension pour les mettre sur le forum) et à placer dans
`/var/www/html/plugins/openzwave/resources/openzwaved/config/xxx/’
Attention, ils seront écrasés à chaque mise à jour du plugin openzwave. 
Ne pas oublier de vérifier avant de faire une inclusion.
- Ces modifications sont à effectuer avant de faire l’inclusion du(des) module(s).
- Si les modules ont déjà été inclus, il faut régénérer le fichier de config du réseau
/var/www/html/plugins/openzwave/data/zwcfg_*.xml
Attention, l’opération est très lourde, les modules ne seront pas fonctionnels jusqu’au premier réveil. - Si votre réseau est plutôt stable et que vous ne voulez pas régénérer ce fichier au risque de tout casser, alors arrêtez le réseau puis modifiez directement celui-ci en rajoutant le paramètre
getsupported="false"pour les classes qui posent problème comme ceci
<CommandClass id="113" name="COMMAND_CLASS_ALARM" version="5" request_flags="1" getsupported="false" innif="true">
Actuellement, j’ai 32 modules secteur, le réseau démarre en 80 secondes en moyenne.
Ainsi, avec toutes ces modifications de fichier config, le nombre de message jetés ou non délivrés est quasi nul à la fin du redémarrage complet du réseau Z-Wave, soit au bout de 24h.
Depuis presque 1 mois que le réseau Z-Wave tourne (c’est la première que ça m’arrive, alors je ne touche plus à rien), j’ai entre 2 et 3 erreurs par jours. Ces message jetés ou non délivrés sont causés par 2 modules extérieurs un peu éloignés du réseau et 2 autres modules intérieurs trop proches entre eux (dans le même interrupteur).
Maintenant, je préfère rester avec openzwave 1.4 qui a beaucoup de défauts mais que je maîtrise que de sauter dans l’inconnu avec openzwave 1.6 et de repartir pour de nouvelles galères. Quand je pense que j’avais choisi le Z-Wave pour ne pas avoir à bidouiller !
EDIT : mise à jour du fichier de config du module ZMNHJD1, c’est le dernier module qui posait des problèmes et qui avait beaucoup de commandes non supportées. Je n’avais pas osé enlever toutes les commandes non supportées il y a quelques mois. Maintenant, c’est chose faite et ça ne semble pas perturber le fonctionnement du capteur (remarque, je n’ai pas vérifier de fonctionnement ni de la sonde ni des 3 entrées), les valeurs des commandes non supportées remontent bien. Dans ma compréhension, c’est seulement l’interview des commandes non supportées qui n’est pas effectué lors du premier réveil du module.
Enfin, après tout ce travail, il ne me reste plus aucune erreur de commande non supportée. Je peux donc me permettre d’augmenter fortement le timeout (4s par défaut) à 20 secondes. Cela laisse énormément de temps au réseau pour bien fonctionner. Le nombre de message jetés ou non délivrés a encore diminué. Il ne reste plus que les vannes Spirit qui font encore des caprices. Je devrais pouvoir améliorer un peu les choses en espaçant de quelques secondes les ordres…
Fichier log openzwaved en 15 jours !
2021-02-16 19:08:59.001 Always, OpenZwave Version 1.4.0 Starting Up
2021-02-16 20:40:27.535 Error, Node123, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-17 14:00:22.108 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-17 16:20:22.299 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-17 19:50:08.083 Warning, Node133, WARNING: Device is not a sleeping node.
2021-02-17 19:50:13.530 Warning, Node131, WARNING: Device is not a sleeping node.
2021-02-17 19:50:29.529 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-18 11:50:22.314 Error, Node131, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-18 12:40:24.005 Error, Node131, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-18 14:50:22.341 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-18 22:00:13.713 Error, Node130, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
2021-02-18 22:00:29.711 Error, Node130, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-19 05:40:21.899 Error, Node131, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-19 08:50:22.072 Error, Node131, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-19 19:00:23.245 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-19 21:22:53.587 Error, Node115, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-20 17:50:23.073 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-21 09:40:20.853 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-21 10:00:23.664 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-21 11:00:14.216 Warning, Node133, WARNING: Device is not a sleeping node.
2021-02-21 21:40:08.274 Warning, Node133, WARNING: Device is not a sleeping node.
2021-02-22 08:20:20.075 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-22 09:40:21.089 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-22 15:10:08.380 Warning, Node133, WARNING: Device is not a sleeping node.
2021-02-22 15:10:24.379 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-23 23:55:21.940 Error, Node131, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-24 06:30:22.059 Error, Node131, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-24 08:20:22.522 Error, Node131, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-24 17:00:25.724 Error, Node130, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-25 02:20:22.851 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-25 05:35:22.408 Error, Node131, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-25 05:55:19.998 Error, Node131, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-02-28 17:00:31.003 Error, Node131, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-03-01 08:00:23.783 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2021-03-01 09:40:28.221 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
Remarque : les vannes 131 et 133 sont en mode manuel et reçoivent environ 200 ordres de % par jour, donc elle ont statisquement plus d’erreurs par rapport à la vanne 130 qui reçoit 4 ordres de consigne par jour.
Conclusion, pour faire fonctionner un truc soi disant fiable, ben y a du boulo !!!
2 « J'aime »
C’est énorme ! Merci.
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.
Bonjour
Domatizer : c’est dingue le boulot que tu as fais, c’est quand même dommage que le plugin n’ait jamais été optimisé comme tu l’as fais.
J’ai investi + de 5000 € dans environ 90 modules zwave sur 3-4 ans, mais comme je souhaites rester sur jeedom car j’ai beaucoup d’autres choses qui tournent bien, je me tourne vers d’autres protocoles.
Au final c’est un beau gâchis, j’aurais du prendre une box « pro » pour le zwave, mais rien n’équivaut jeedom pour son ouverture sur un tas d’autres protocoles.
Aucune nouvelle récente sur la refonte de openzwave, je verrais bien d’ici quelques mois ce que je fais de mon zwave bancal, au prochain confinement, lol ?
Trop de temps a passer là-dessus
1 « J'aime »
Merci. Pour trouver les trucs qui vont pas, ouais, c’est une vraie galère de chercher. Surtout quand on lit que d’autres n’ont pas de souci, on croit que les problèmes viennent de nous, mais nan en fait.
Au final, il faut juste avoir fait les corrections dans les fichiers de config des modules avant de faire les inclusion ou alors régénérer partiellement ou totalement le fichier de config du réseau si les inclusions sont déjà faites.
Ensuite tout roule…
Ça n’existe pas vraiment à part la Home Center 3.
Ah si, openzwave 1.6 est train d’être abandonné…
Il existe un projet plus propre Z-waveJS
Le driver
La version MQTT (fonctionnement et interface très similaires à openzwave2mqtt)
https://zwave-js.github.io/zwavejs2mqtt/#/README
https://zwave-js.github.io/zwavejs2mqtt/#/getting-started/why
La version Home Assistant
Les mecs, ils ont mis 1 mois pour intégrer ZWaveJS à Home Assistant !
Ok, merci, je viens d’aller voir le projet, ça à l’air prometteur
Me reste a surveiller le sujet et attendre que d’autres l’utilise avec jeedom, j’espere sans devoir ré inclure les modules et se retaper la correction des scénarios…wait and see
En tous cas je pense que ça va bouger favorablement dans les mois qui viennent
Non, j’ai essayé le zwavejs2mqtt et je l’ai laissé tourner, il a juste de fait de la découverte du réseau à partir du contenu (qui pour moi est ok) dans le contrôleur. La première fois, ça prend du temps (il faut que tous les modules se réveillent) de tout régénérer le fichier de config du réseau.
C’est quoi le concept, ça va créer des nouveaux équipements dans jmqtt ?
Tu pourrais expliquer la manip pour utiliser zwavejs avec jeedom ?
J’ai déjà mqtt, quand j’aurais le temps faudrait que j’essaie en VM sur mon proxmox i7, mais je n’ai qu’une clé zwave…comme un con j’avais l’ancienne clé aeon que j’ai jeté quand je l’ai remplacée par gén5…Mais je pourrais tester quand même
Là, on passe hors sujet, merci de créer un autre sujet
Pour répondre vite fait, j’ai juste fait essai de zwavejs2mqtt sur un RPi zero sans récupérer les infos sur Jeedom en suivant les consignes de leur site pour voir comment ça tourne et j’ai visualisé les résultats dans MQTT Explorer. Dans mon cas, j’ai plus à perdre qu’à gagner en changeant de solution !
Pour revenir au sujet principal, j’ai demandé la réouverture de ce fil afin de permettre à d’autres utilisateurs de donner un retour d’expérience sur les modifications de fichiers de config des modules.
1 « J'aime »
Bonjour @Domatizer
bravo et merci pour ce gros travail unique et très bien imaginé.
je suis intéressé, moi aussi, par l’optimisation du démarrage de mon réseau qui comporte 48 noeuds et qui prend 375 s sur jeedom 4.1.24 / gen stick 5 / VM SYNO
voici la liste des modules regroupé par id fabriquant que j’ai extrait de la DB
Mais plutot que de tout recommencer, serais tu disposé à me communiquer des fichiers de conf, optimisé par tes soins, de modules figurant dans ma liste ? 
Et si oui, pourquoi ne pas ouvrir un dépo sur GitHub afin que ts les utilisateurs du plugin Z-Wave puissent en profiter ?
Il est vrai que ce plugin ZWAVE/Jeedom, tjs basé sur openzwave 1.4, tarde à évoluer.
Il me semble que le mieux serait qu’il soit ré-écrit en utilisant le SDK officiel, libre de fee dorénavant.
Ca doit etre un travail énorme, mais qui peut s’y coller ? un ou plusieurs contributeurs ? l’équipe Jeedom SAS ?
Si je dis cela c’est que je n’en ai pas les compétence, mais je suis pret à mettre une somme. Pourquoi ne pas lancer un sondage ? ouvrir une cagnote en ligne pour en assurer le financement du dev. ? meme si ce n’est pas du tout dans l’esprit opensource. Mais j’ai bien peur que ZigBee, très actif, éclipse Zwave si celui n’évolue pas…
J’ai regardé pour passer sur MQTT, mais c’est qd même un peu usine à gaz, pourtant il parait que c’est un super protocole.
voilà en espérant que mon post recoive un bon accueil de toi et des autres utilisateurs Zwave 
Bonjour,
L’équipe jeedom semble travailler sur ce nouveau plugin si on lit entre les lignes sur différents posts présents sur le forum, néanmoins, ils n’ont rien annoncé d’officiel pour le moment si ce n’est la refonte du plugin Zwave dans la roadmap de … 2020.
Les fichiers modifiés sont disponibles ici
A chaque mise à jour du plugin, ces fichiers seront écrasés.
Donc, avant de faire une nouvelle inclusion, ne pas oublier de vérifier si le fichier de config.
J’ai désactivé les commandes soit disant non supportées pour ne plus avoir d’erreur. Même en désactivant des commandes utilisées, ça fonctionne correctement. Ça m’arrange, mais je n’ai rien compris. C’est pourquoi, je ne sais pas si mes modifications sont correctes et je ne comprend pas ce que je fais exactement. Donc, je ne peux pas me permet de dire que c’est ce qu’il faut faire et de faire télécharger aux gens des fichiers sur un github.
Même après tout ça, on n’est jamais à l’abri d’un redémarrage qui parte en vrille un jour ou l’autre sans avoir rien touché au réseau.
Quand je pense que j’ai choisi ce protocole bien cher pour justement ne pas avoir à bidouiller !