Optimisation du temps de démarrage du réseau Z-Wave

Domatizer · Avril 21, 2020, 2:06

Bonjour,

A force d’analyser les erreurs dans les fichiers log d’openzwave pour debugger mon réseau, je me suis rendu compte qu’il existe certaines requêtes qui ne semblent pas ou mal être supportées et qui nous font perdre vraiment du temps lors du redémarrage

4 secondes à chaque fois ! Compter le nombre de modules que vous avez et faites le calcul !

Ces erreurs sont toutes dans la catégorie Nombre de messages jetés ou non délivrés :

Exemple avec la commande AlarmCmd_Get qui est mal supportée avec tous les modules
Pour les Fibaro Dimmer 2 il y a 4 requêtes et à chaque fois la première des 4 n’aboutit pas

2020-04-20 20:54:24.137 Info, Node045, Sending (Send) message (Callback ID=0x92, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): AlarmCmd_Get (Node=45): 0x01, 0x10, 0x00, 0x13, 0x2d, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0x92, 0x76
2020-04-20 20:54:24.168 Info, Node045, Request RTT 30 Average Request RTT 30
2020-04-20 20:54:28.138 Error, Node045, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 20:54:28.140 Info, Node045, Sending (Send) message (Callback ID=0x93, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): AlarmCmd_Get (Node=45): 0x01, 0x10, 0x00, 0x13, 0x2d, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x04, 0x01, 0x25, 0x93, 0x73
2020-04-20 20:54:28.171 Info, Node045, Request RTT 30 Average Request RTT 30
2020-04-20 20:54:28.187 Info, Node045, Response RTT 47 Average Response RTT 46
2020-04-20 20:54:28.188 Info, Node045, Received a MultiChannelEncap from node 45, endpoint 1 for Command Class COMMAND_CLASS_ALARM
2020-04-20 20:54:28.188 Info, Node045, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Heat event:254, status=255
2020-04-20 20:54:28.190 Info, Node045, Sending (Send) message (Callback ID=0x94, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): AlarmCmd_Get (Node=45): 0x01, 0x10, 0x00, 0x13, 0x2d, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x94, 0x78
2020-04-20 20:54:28.220 Info, Node045, Request RTT 30 Average Request RTT 30
2020-04-20 20:54:28.237 Info, Node045, Response RTT 46 Average Response RTT 46
2020-04-20 20:54:28.237 Info, Node045, Received a MultiChannelEncap from node 45, endpoint 1 for Command Class COMMAND_CLASS_ALARM
2020-04-20 20:54:28.237 Info, Node045, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Power Management event:254, status=255
2020-04-20 20:54:28.240 Info, Node045, Sending (Send) message (Callback ID=0x95, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): AlarmCmd_Get (Node=45): 0x01, 0x10, 0x00, 0x13, 0x2d, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x09, 0x01, 0x25, 0x95, 0x78
2020-04-20 20:54:28.272 Info, Node045, Request RTT 31 Average Request RTT 30
2020-04-20 20:54:28.287 Info, Node045, Response RTT 47 Average Response RTT 46
2020-04-20 20:54:28.287 Info, Node045, Received a MultiChannelEncap from node 45, endpoint 1 for Command Class COMMAND_CLASS_ALARM
2020-04-20 20:54:28.287 Info, Node045, Received Alarm report: type=0, level=0, sensorSrcID=0, type:System event:1, status=255

Idem avec un autre Dimmer 2, ça plante au même endroit

2020-04-20 20:54:28.603 Info, Node048, Sending (Send) message (Callback ID=0x9b, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): AlarmCmd_Get (Node=48): 0x01, 0x10, 0x00, 0x13, 0x30, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0x9b, 0x62
2020-04-20 20:54:28.629 Info, Node048, Request RTT 25 Average Request RTT 24
2020-04-20 20:54:32.603 Error, Node048, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 20:54:32.605 Info, Node048, Sending (Send) message (Callback ID=0x9c, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): AlarmCmd_Get (Node=48): 0x01, 0x10, 0x00, 0x13, 0x30, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x04, 0x01, 0x25, 0x9c, 0x61
2020-04-20 20:54:32.631 Info, Node048, Request RTT 25 Average Request RTT 24
2020-04-20 20:54:32.644 Info, Node048, Response RTT 38 Average Response RTT 37
2020-04-20 20:54:32.644 Info, Node048, Received a MultiChannelEncap from node 48, endpoint 1 for Command Class COMMAND_CLASS_ALARM
2020-04-20 20:54:32.644 Info, Node048, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Heat event:254, status=255
2020-04-20 20:54:32.647 Info, Node048, Sending (Send) message (Callback ID=0x9d, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): AlarmCmd_Get (Node=48): 0x01, 0x10, 0x00, 0x13, 0x30, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x9d, 0x6c
2020-04-20 20:54:32.672 Info, Node048, Request RTT 25 Average Request RTT 24
2020-04-20 20:54:32.685 Info, Node048, Response RTT 38 Average Response RTT 37
2020-04-20 20:54:32.685 Info, Node048, Received a MultiChannelEncap from node 48, endpoint 1 for Command Class COMMAND_CLASS_ALARM
2020-04-20 20:54:32.685 Info, Node048, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Power Management event:254, status=255
2020-04-20 20:54:32.688 Info, Node048, Sending (Send) message (Callback ID=0x9e, Expected Reply=0x04) - MultiChannel Encapsulated (instance=1): AlarmCmd_Get (Node=48): 0x01, 0x10, 0x00, 0x13, 0x30, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x09, 0x01, 0x25, 0x9e, 0x6e
2020-04-20 20:54:32.713 Info, Node048, Request RTT 25 Average Request RTT 24
2020-04-20 20:54:32.726 Info, Node048, Response RTT 38 Average Response RTT 37
2020-04-20 20:54:32.726 Info, Node048, Received a MultiChannelEncap from node 48, endpoint 1 for Command Class COMMAND_CLASS_ALARM
2020-04-20 20:54:32.726 Info, Node048, Received Alarm report: type=0, level=0, sensorSrcID=0, type:System event:1, status=255

Pour un Fibaro Wall Plug Gen 5 c’est aussi la première des 2 commandes AlarmCmd_Get qui pose pose souci.

2020-04-20 20:55:41.806 Info, Node120, Sending (Send) message (Callback ID=0x20, Expected Reply=0x04) - AlarmCmd_Get (Node=120): 0x01, 0x0c, 0x00, 0x13, 0x78, 0x05, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0x20, 0xec
2020-04-20 20:55:41.911 Info, Node120, Request RTT 104 Average Request RTT 105
2020-04-20 20:55:45.807 Error, Node120, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 20:55:45.810 Info, Node120, Sending (Send) message (Callback ID=0x21, Expected Reply=0x04) - AlarmCmd_Get (Node=120): 0x01, 0x0c, 0x00, 0x13, 0x78, 0x05, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x21, 0xe5
2020-04-20 20:55:45.862 Info, Node120, Request RTT 51 Average Request RTT 78
2020-04-20 20:55:45.940 Info, Node120, Response RTT 130 Average Response RTT 157
2020-04-20 20:55:45.941 Info, Node120, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Power Management event:254, status=255

Avec des Fibaro Dimmer 2 inclus en sécurisé, c’est pareil après décodage. Je ne le met pas ici pour ne pas alourdir mon post.

Si vous regardiez bien le temps, il se passe 4 secondes (timeout par défaut) à chaque erreur et la queue sortante reste bloquée inutilement

Au cours d’un redémarrage, j’ai toujours 27 erreurs de ce type

2020-04-21 00:12:54.553 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:13:01.901 Error, Node045, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:13:07.375 Error, Node048, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:13:13.452 Error, Node050, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:13:19.167 Error, Node076, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:13:24.619 Error, Node078, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:13:30.564 Error, Node089, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:13:36.288 Error, Node092, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:13:41.967 Error, Node097, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:13:47.267 Error, Node109, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:13:52.460 Error, Node109, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:13:57.502 Error, Node110, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:14:03.613 Error, Node110, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:14:11.917 Error, Node111, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:14:19.283 Error, Node115, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:14:24.597 Error, Node115, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:14:29.679 Error, Node120, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:14:34.876 Error, Node120, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:14:40.422 Error, Node130, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:14:48.568 Error, Node131, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:14:56.785 Error, Node132, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:15:06.145 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:15:13.894 Error, Node138, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:15:19.358 Error, Node140, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:15:24.803 Error, Node141, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:15:30.285 Error, Node142, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-21 00:15:35.731 Error, Node143, ERROR: Dropping command, expected response not received after 1 attempt(s)

Pour vous convaincre des 4 secondes de timeout, il vous suffit de modier le fichier

/var/www/html/plugins/openzwave/resources/openzwaved/config/option.xml

et de mettre 8s comme ceci <Option name="RetryTimeout" value="8000" />
Et bien, vous aller vous prendre 8 secondes, soit 4 secondes de plus à chaque erreur.


2020-04-20 23:14:07.486 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:14:16.481 Error, Node045, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:14:24.958 Error, Node048, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:14:34.502 Error, Node050, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:14:43.222 Error, Node076, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:14:51.654 Error, Node078, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:15:00.608 Error, Node089, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:15:09.410 Error, Node092, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:15:17.855 Error, Node097, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:15:26.148 Error, Node109, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:15:34.348 Error, Node109, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:15:42.390 Error, Node110, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:15:51.453 Error, Node110, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:16:02.704 Error, Node111, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:16:10.706 Error, Node111, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:16:20.425 Error, Node115, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:16:28.747 Error, Node115, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:16:36.839 Error, Node120, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:16:45.032 Error, Node120, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:16:54.814 Error, Node130, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:17:07.198 Error, Node131, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:17:18.346 Error, Node132, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:17:30.804 Error, Node133, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:17:41.046 Error, Node138, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:17:49.482 Error, Node140, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:17:57.914 Error, Node141, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:18:06.378 Error, Node142, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-20 23:18:14.837 Error, Node143, ERROR: Dropping command, expected response not received after 1 attempt(s)

Ainsi :

Le réseau démarre en 298 secondes avec un timeout de 8s
Le réseau démarre en 188 secondes avec un timeout de 4s

Alors la différence est de 110 secondes, ce qui correspond à mes 27 erreurs car 27*4=108

Maintenant, si ces commandes étaient bien supportées, ça devrait prendre au max 200ms environ, soit un gain de 3.8s à chaque erreur et mon réseau Z-Wave devrait démarrer en 188-27*3.8 = 85 secondes.

Ensuite, au cours des 6 heures qui suivent, tous les modules sur piles vont se réveiller et avoir des erreurs similaires. J’ai 62 modules et certains ont 1 ou plusieurs commandes (toujours les mêmes) qui ne passent pas. J’ai dressé le tableau suivant : Nombres de commandes non supportées par type de module
Timeout

En thérorie, j’aurais 105 erreurs et en pratique j’en suis 107 messages jetés ou non délivrés au bout d’une journée.

La liste des commandes non supportées ou partiellement pour chaque module (non sécurisé par défaut)

Fibaro Motion Sensor 2 : AlarmCmd_Get
Fibaro Dimmer Sensor 2 (sécurisé ou pas) : AlarmCmd_Get
Fibaro Door Sensor 2 : SensorBinaryCmd_Get / AlarmCmd_Get
Fibaro Door Sensor 2 (sécurisé) : BasicCmd_Get / SensorBinaryCmd_Get / AlarmCmd_Get
Aeotec Door Sensor 7 : BasicCmd_Get / SensorBinaryCmd_Get / AlarmCmd_Get
Fibaro Double Switch : SwitchAllCmd_Get / AlarmCmd_Get
Fibaro Wall Plug Gen 5 : SwitchAllCmd_Get / AlarmCmd_Get
Quibino Smart Plus : SwitchAllCmd_Get / AlarmCmd_Get
Tous les autres : AlarmCmd_Get

La question pour un expert est :
Comment supprimer ou ignorer ces requêtes mal supportées pour que la queue sortante soit bloquée moins longtemps ?

Faut-il bidouiler les fichiers XML dans /var/www/html/plugins/openzwave/resources/openzwaved/config/<contructeur>/<module>.xml ?

Exemple avec le fichier du module Wall Plug Gen 5 car j’y vois les trucs commentés suivants

        <!-- COMMAND_CLASS_ALARM AlarmCmd_Get not supported -->
        <!-- CommandClass id="113" action="remove" /> -->

        <!-- COMMAND_CLASS_SENSOR_ALARM not supported -->
        <!-- CommandClass id="156" action="remove" /> -->

        <!-- COMMAND_CLASS_SWITCH_ALL not supported -->
        <!-- CommandClass id="39" action="remove" /> -->

EDIT : mise à jour de mon dernier post

Bison · Avril 21, 2020, 2:17

Beau travail Domatizer. A suivre en espérant que d’autres auront des réponses à t’apporter.

Domatizer · Avril 21, 2020, 2:40

Merci @Bison.

J’espère bien recevoir des solutions.

PHB_fr · Avril 21, 2020, 6:21

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é

Domatizer · Avril 21, 2020, 10:14

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
ResumeZWave95min

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.
ResumeZWave82min

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…

axelpg · Avril 21, 2020, 11:09

Salvialf · Avril 21, 2020, 11:17

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

Domatizer · Avril 22, 2020, 12:14

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

axelpg · Avril 22, 2020, 12:17

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 ^^

Domatizer · Avril 22, 2020, 12:25

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.

axelpg · Avril 22, 2020, 12:36

J’ai bien relu.
J’ai trop peur

Bison · Avril 22, 2020, 6:19

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.

Domatizer · Avril 22, 2020, 1:18

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

Domatizer · Avril 22, 2020, 2:12

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 »

Bison · Avril 22, 2020, 2:23

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 ?

Domatizer · Avril 22, 2020, 2:42

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

Bison · Avril 22, 2020, 2:47

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

Mips · Avril 22, 2020, 9:32

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

Salvialf · Avril 22, 2020, 9:44

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.

Domatizer · Avril 23, 2020, 12:49

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 ».