Merci @Bison.
J’espère bien recevoir des solutions.
Chapeau une fois de plus pour ton travail d’analyse ! Tu as mis le doigt sur un superbe exemple et en plus reproductible. Je suis sur qu’il sera bientôt corrigé
Hum, dans le doute, j’ai continué mon enquête.
Concernant la COMMAND_CLASS_ALARM AlarmCmd_Get, l’ID de sa classe est le 113. J’ai regardé les commandes des équipements pour les modules
La plupart des modules n’utilisent pas la classe 113 dans leurs commandes, on pourrait s’en passer plutôt que de la corriger.
Modules sur secteur qui N’utilisent PAS la classe 113 dans leurs commandes
- Fibaro Dimmer 2 FGD-212
- Fibaro Double Switch 2 FGS-223
- Fibaro Wall Plug Gen 5
- Qubino SmartPlug ZMNYDx
- Qubino Fil Pilote ZMNHJD1
- Qubino Contact Sec
Modules sur pile Flirs qui N’utilisent PAS la classe 113 dans leurs commandes
- EUROtronic Spirit
Modules sur pile qui N’utilisent PAS la classe 113 dans leurs commandes
- Fibaro Motion Sensor 2 FGMS-001
- Fibaro KeyFob FGKF-601
Modules sur pile qui a besoin de la classe 113 dans la commande principale Etat
(donc ici pas touche à la COMMAND_CLASS_ALARM)
- Fibaro Door Sensor 2 FGDW-002
- Aeotec DoorWindow Sensor 7 ZWA008
- Everspring SP816 Motion Detector
- Aeoec MultiSensor 6 ZW100 (utilisée pour la commande sabotage)
Bonne nouvelle, quasi tous mes modules secteurs ou Flirs n’utilisent pas la classe 113.
Je pense que je peux donc la virer sans risque pour améliorer le temps de démarrage. J’aimerais bien l’avis d’un expert tout de même.
J’ai d’abord fait un essai sur un module en éditant son fichier de config /var/www/html/plugins/openzwave/resources/openzwaved/config/<contructeur>/<module>.xml et en rajoutant ceci
<!-- COMMAND_CLASS_ALARM AlarmCmd_Get not supported -->
<CommandClass id="113" getsupported="false"/>
Pour certains modules, la ligne est déjà présente, c’est super, il suffit d’enlever les commentaires. 
Ensuite, j’ai supprimé le fichier zwcfg_*.xml dans /var/www/html/plugins/openzwave/data/
Il sera re créé entièrement une fois le réveil de tous les modules, ça peut-être long…
Ne m’intéressant qu’aux modules secteur en priorité, j’ai juste besoin d’attendre le démarrage de réseau et j’arrête le daemon. Le nouveau fichier zwcfg_*.xml est sauvegardé, incomplet certes, mais j’ai les infos que je voulais.
La ligne <CommandClass id="113" getsupported="false"/> dans le fichier de config du module fait qu’on obtient automatiquement la bonne option getsupported="false" pour la classe 113 du module dans le fichier zwcfg_*.xml
Ainsi, pour un Dimmer 2 FGD-212 on a
<CommandClass id="113" name="COMMAND_CLASS_ALARM" version="5" request_flags="1" getsupported="false" innif="true">
Pour gagner du temps, j’ai donc repris mon ancien fichier zwcfg_*.xml et rajouté directement à la mano le paramètre getsupported="false" pour les modules n’ayant pas besoin de AlarmCmd_Get
Je n’ai traité que la COMMAND_CLASS_ALARM AlarmCmd_Get, il faudra que je fasse la même chose pour le SwitchAllCmd_Get…
Sur les 27 erreurs, il ne m’en reste plus que 5, dont 4 erreurs avec SwitchAllCmd_Get (pas encore traité)
2020-04-21 22:55:40.177 Error, Node089, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 22:55:46.385 Error, Node109, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 22:55:51.632 Error, Node110, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 22:55:59.345 Error, Node115, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 22:56:04.546 Error, Node120, ERROR: Dropping command, expected response not received after 1 attempt(s)
Donc je viens de gagner 22*4 = 88 secondes. Comme j’étais sur un redémarrage en 188 secondes, je devrais arriver vers 100 secondes. Verdict
95 secondes au lieu de 4 minutes généralement que j’avais à mes débuts du Z-Wave (réseau avec 63 modules dont 20 modules secteur et 5 Flirs). Je redémarre pour vérifier si c’est un coup de chance.
Et là, redémarrage du réseau Z-Wave en 82 secondes, je n’en reviens pas moi-même !!! Je me prends une 
Et dire que je pourrais encore gratter 4*4 = 16 secondes à cause des SwitchAllCmd_Get 
Je pourrais me permettre maintenant d’augmenter le timeout pour les rares cas où la transmission prendrait plus de temps que prévu et ainsi augmenter la stabilité du réseau.
Au niveau des erreurs, je tends vers 0. Je trouve aussi que le nombre de messages non remis au réseau à bien diminué. Peut-être que le fait d’avoir une queue sortante bloquée moins souvent génère moins de problèmes ?
Voilà, le concept me plait ! Encore les modules sur piles à regarder ce qu’on peut faire…
En attendant la version 1.6 d’openzwave ou le SDK, il faudrait trouver une façon élégante pour modifier proprement les fichiers config XML des modules plutôt que de bidouiller directement dans zwcfg_*.xml…
2 « J'aime »
Hello @Domatizer,
Super ! quelle précision alliée à la pédagogie c’est très intéressant à lire et à étudier, j’ai survolé sur le tel mais je suis pressé de tester tout ça !
Après c’est de l’optimisation et je ne suis pas sûr que ce soit dans la ligne de mire de la team jeedom qui va sûrement réécrire entièrement ce plugin comme indiqué dans la roadmap
Merci @Salvialf
Oui, mais avant tout c’était pour corriger des erreurs ZWave, pas pour faire de l’optim, et je n’aime pas les erreurs. Certaines classes ne fonctionnent pas bien, autant les supprimer si on ne s’en sert pas. Je préfère un truc qui supporte moins de choses, mais qui le fait bien.
J’ai modifié plus proprement mes fichiers de config et régénéré en partie le fichier zwcfg_*.xml pour vérifier qu’il sera clean automatiquement par la suite.
C’est fait, attention !
64 secondes !!! Qui dit mieux ?
J’ai corrigé aussi les Fibaro Motion Sensor 2, toujours des erreurs en moins dans les log. En revanche, pour les détecteurs de portes. ils se basent sur la valeur Access Control pour obtenir l’état. Donc impossible de l’enlever mais les requêtes BasicCmd_Get et SensorBinaryCmd_Get ne sont peut-être plus utiles… en même temps, elle ne marchent pas !
Remarque en passant, la valeur Access Control se modifie toute seule (donc l’état binaire avec) lors du premier réveil. Ça m’avait fait ch**r pendant un long moment ce truc. Voir ici Door/Window Sensor 2 se ferme tout seul lors du 1er réveil
Question de néophyte : tu peux faire un exemple tres concret avec un module, quel fichier exactement aller modifier, quelle ligne, etc.
J’ai très envie de démarrer en moins d’une minute aussi (j’ai pleins de modules comme les tiens) mais pas très envie de passer une nuit à remonter un jeedom parce que j’aurai fait une connerie.
Merci ^^
Si tu veux faire vite et sans prendre de risque, tu arrêtes ton daemon, tu sauvegardes le fichier zwcfg_*.xml et tu le modifies manuellement et tu relances le réseau.
Ça te donne ça
Mais pour les nouvelles inclusions, il faudra de nouveau faire la modife. D’où l’utilité de le faire un bonne fois pour toute dans le fichier config du module. Relis bien ce que j’ai écrit.
J’ai bien relu.
J’ai trop peur 
Bien joué, ça me tente aussi !
Je regarderai si j’ai des modules utilisant la classe 113 et je modifierai ce fichier zwcfg_*.xml pour voir ce que ça donne.
C’est plutôt l’inverse, regarder si les équipements n’utilisent pas la classe 113 dans leurs commandes.
J’ai pu supprimer toutes les erreurs de mes modules secteurs et flirs.
Donc juste après le redémarrage, j’admire ce score
Nombre de messages jetés ou non délivrés : 0
En filtrant le log openzwaved avec « AlarmCmd_Get », j’obtiens ceci
2020-04-22 16:03:49.079 Info, Node045, AlarmCmd_Get Not Supported on this node
2020-04-22 16:03:49.796 Info, Node048, AlarmCmd_Get Not Supported on this node
2020-04-22 16:03:50.272 Info, Node076, AlarmCmd_Get Not Supported on this node
2020-04-22 16:03:51.035 Info, Node078, AlarmCmd_Get Not Supported on this node
2020-04-22 16:03:53.111 Info, Node089, Sending (Send) message (Callback ID=0x95, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): AlarmCmd_Get (Node=89): 0x01, 0x10, 0x00, 0x13, 0x59, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0x95, 0x05
2020-04-22 16:03:53.155 Info, Node089, Sending (Send) message (Callback ID=0x96, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): AlarmCmd_Get (Node=89): 0x01, 0x10, 0x00, 0x13, 0x59, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x07, 0x01, 0x25, 0x96, 0x01
2020-04-22 16:03:53.207 Info, Node089, Sending (Send) message (Callback ID=0x97, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): AlarmCmd_Get (Node=89): 0x01, 0x10, 0x00, 0x13, 0x59, 0x09, 0x60, 0x0d, 0x01, 0x02, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0x97, 0x04
2020-04-22 16:03:53.250 Info, Node089, Sending (Send) message (Callback ID=0x98, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): AlarmCmd_Get (Node=89): 0x01, 0x10, 0x00, 0x13, 0x59, 0x09, 0x60, 0x0d, 0x01, 0x02, 0x71, 0x04, 0x00, 0x07, 0x01, 0x25, 0x98, 0x0c
2020-04-22 16:03:53.297 Info, Node089, Sending (Send) message (Callback ID=0x99, Expected Reply=0x04) - MultiChannel Encapsulated (instance=3): AlarmCmd_Get (Node=89): 0x01, 0x10, 0x00, 0x13, 0x59, 0x09, 0x60, 0x0d, 0x01, 0x07, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0x99, 0x0f
2020-04-22 16:03:53.340 Info, Node089, Sending (Send) message (Callback ID=0x9a, Expected Reply=0x04) - MultiChannel Encapsulated (instance=3): AlarmCmd_Get (Node=89): 0x01, 0x10, 0x00, 0x13, 0x59, 0x09, 0x60, 0x0d, 0x01, 0x07, 0x71, 0x04, 0x00, 0x09, 0x01, 0x25, 0x9a, 0x05
2020-04-22 16:03:53.523 Info, Node092, AlarmCmd_Get Not Supported on this node
2020-04-22 16:03:53.902 Info, Node097, AlarmCmd_Get Not Supported on this node
2020-04-22 16:03:54.199 Info, Node101, AlarmCmd_Get Not Supported on this node
2020-04-22 16:03:54.494 Info, Node109, AlarmCmd_Get Not Supported on this node
2020-04-22 16:03:55.874 Info, Node110, AlarmCmd_Get Not Supported on this node
2020-04-22 16:03:58.498 Info, Node111, AlarmCmd_Get Not Supported on this node
2020-04-22 16:03:58.834 Info, Node115, AlarmCmd_Get Not Supported on this node
2020-04-22 16:03:59.211 Info, Node120, AlarmCmd_Get Not Supported on this node
2020-04-22 16:04:02.405 Info, Node130, AlarmCmd_Get Not Supported on this node
2020-04-22 16:04:04.843 Info, Node131, AlarmCmd_Get Not Supported on this node
2020-04-22 16:04:06.757 Info, Node132, AlarmCmd_Get Not Supported on this node
2020-04-22 16:04:12.415 Info, Node133, AlarmCmd_Get Not Supported on this node
2020-04-22 16:04:13.107 Info, Node138, AlarmCmd_Get Not Supported on this node
2020-04-22 16:04:13.492 Info, Node140, AlarmCmd_Get Not Supported on this node
2020-04-22 16:04:13.872 Info, Node141, AlarmCmd_Get Not Supported on this node
2020-04-22 16:04:14.256 Info, Node142, AlarmCmd_Get Not Supported on this node
2020-04-22 16:04:14.623 Info, Node143, AlarmCmd_Get Not Supported on this node
2020-04-22 16:04:14.941 Info, Node144, AlarmCmd_Get Not Supported on this node
2020-04-22 16:04:15.273 Info, Node145, AlarmCmd_Get Not Supported on this node
Sur tous mes modules secteurs, il n’y que le module Fibaro Smart Implant FGBS-222 (Node089) qui n’a pas de problème avec la requête « AlarmCmd_Get »
Oui mais je veux dire qu’il faut regarder ceux qui ont des commandes utilisant la classe 113 pour voir lesquels poseraient en fait des soucis de timeout comme par exemple mes multisensor ZW100
Si j’ai tout compris il doit y avoir du timeout sur ceux là lors du démarrage et en modifiant le fichier pour ne plus prendre en compte la classe 113, le démarrage sera plus rapide.
EDIT :
Le FGBS-222 a une commande de la classe 113. Si on la retire du fichier du coup l’entrée 1 ne sera plus gérée ?
Sur le MultiSensor ZW100, si tu ignores la requête AlarmCmd_Get(classe 113), tu perds la fonction Sabotage
Oui, il faut la garder, mais la bonne nouvelle pour ce module
Est-ce ton cas aussi ?
Remarque : je trouve bizarre que cette classe 113 soit utilisée pour la commande Entrée 2 au lieu de classe=38 avec instance=2 par exemple
Ah mais dans le fichier il y a une option par équipement … forcement (j’ai même pas encore regardé) donc je la garde sur ce qui est important.
Note : je m’étais fais la même réflexion que toi pour le FGBS-222 quand j’essayais de le faire fonctionner et j’avais changé la classe surement comme tu le dis mais ça ne marchait pas. Après j’avais peut être un autre soucis j’ai un peu galéré avec ce module
Sinon le code du plug-in est ouvert, tu peux toujours proposer un pr dessus avec tes changements 
Perso je vais essayer de trouver le temps de relire tout ça en détails et faire plus de test chez moi.
Je suis curieux si je vais « voir » quelque chose;
comme déjà échangé je ne perçois pas de problème à l’usage, le réseau répond quand il doit mais c’est clair qu’il y a matière ici 
Salut @Mips ,
je n’ai pas non plus de soucis avec le réseau zwave par contre j’ai toujours une dizaine de dropping command au démarrage donc si je peux les faire disparaître tant mieux.
1 « J'aime »
Je ne suis pas développeur, je ne sais pas trop comment fonctionne le versionning sur github. Je ne voudrais pas non plus, par la suite, avoir des gens sur les forums dire : « Ah, je n’arrive pas à remonter l’info de ceci ou cela ».
On va attendre un peu d’avoir plus de recul. Pour l’instant, j’effectue des modifications au cas par cas. Seulement lorsque des requêtes sont SYSTÉMATIQUEMENT en timeout pour TOUS les modules identiques. Il arrive aussi des fois que des requêtes supportées ne passe pas exceptionnellement, je me suis déjà fait avoir. J’aurais tendance à conseiller l’augmentation du timeout pour être certain de ne pas considérer à tord une classe comme « non supportée ».
Bonjour,
Dans tous les cas, bravo @Domatizer pour la précision et la clarté des analyses ainsi qu’à tous ceux qui font les tests chez eux avec leurs config, ça fait avancer le mer*ier .
@Domatizer, tu n’es pas en travail/télétravail je suppose avec le temps que tu y passes ? Je vais presque souhaiter que le confinement dure plus longtemps pour que tu puisses encore nous faire de belles analyses ! Non ça va je déconne .
Encore bravo pour votre taf les gars, c’est comme ça qu’on avance ! Moi avec mes 9 modules dont 3 qui dorment et ma dispo de 21h à 23h j’en suis encore pas à ce niveau là ;).
Mais en regardant tes snaphshots, j’admire aussi mon score… à mon niveau
A+
J’ai du temps mais ça ne va pas durer, alors je me dépêche d’avoir un truc qui tourne. Je passe beaucoup beaucoup beaucoup trop de temps à m’occuper de cette domotique. La domotique me fait perdre du temps au lieu de me faciliter la vie…
Voici les modifications apportées dans les fichiers de config :
<!-- COMMAND_CLASS_BASIC BasicCmd_Get (0x20) not supported -->
<CommandClass id="32" getsupported="false"/>
- plugins/openzwave/resources/openzwaved/config/fibaro/fgkf601.xml
<!-- COMMAND_CLASS_SENSOR_BINARY (0x30) SensorBinaryCmd_Get not supported -->
<CommandClass id="48" getsupported="false"/>
- plugins/openzwave/resources/openzwaved/config/everspring/sp816.xml
- plugins/openzwave/resources/openzwaved/config/fibaro/fgbs222.xml
- plugins/openzwave/resources/openzwaved/config/fibaro/fgdw2.xml
<!-- COMMAND_CLASS_ALARM (0x71) AlarmCmd_Get not supported -->
<CommandClass id="113" getsupported="false"/>
- plugins/openzwave/resources/openzwaved/config/eurotronic/eur_spiritz.xml
- plugins/openzwave/resources/openzwaved/config/fibaro/fgd212.xml
- plugins/openzwave/resources/openzwaved/config/fibaro/fgmszw5.xml
<!-- COMMAND_CLASS_SWITCH_ALL (0x27) SwitchAllCmd_Get not supported -->
<CommandClass id="39" getsupported="false"/>
<!-- COMMAND_CLASS_ALARM (0x71) AlarmCmd_Get not supported -->
<CommandClass id="113" getsupported="false"/>
- plugins/openzwave/resources/openzwaved/config/fibaro/fgs223.xml
- plugins/openzwave/resources/openzwaved/config/fibaro/fgwpfzw5.xml
- plugins/openzwave/resources/openzwaved/config/qubino/ZMNHNDx.xml
- plugins/openzwave/resources/openzwaved/config/qubino/ZMNHYDx.xml
Pouvez-vous me confirmer que vous avez aussi les mêmes problèmes de Dropping command (timeout de X seconds) pour ces CommandClass avec ces modules ?
Ces changement s’appliqueront pour les futures inclusions.
Pour les équipements déjà existants, il faut régénérer la config du réseau Z-Wave stocké dans le fichier dans /var/www/html/plugins/openzwave/data/zwcfg_*.xml
Pour régénérer la config d’un module ou d’un type de module, il faut lancer l’action « Régénérer la détection du noeud »
Pour régénérer la config de tout le réseau, il suffit de supprimer le fichier zwcfg_*.xml et de relancer le daemon ! Mais attention, c’est bourrin et c’est long, il faut attendre le réveil de tous les modules. Et pendant ce temps là, les modules ne sont pas fonctionnels, pas de commandes. Il faut lancer ça de préférence quand ça dérange le moins sur un réseau déjà clean. Ceux qui galèrent déjà avec des noeuds fantômes ou des paramètres manquants, je leur déconseille de se lancer la dedans. Enfin, arrêter le réseau afin que le fichier zwcfg_*.xml soit mis à jour et sauvegardé.
J’ai hâte d’avoir des retours de vos essais.