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

[Emlivyo]

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+

[Domatizer]

@Emlivyo

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

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.

[Bison]

Personnellement j’ai finalement très peu de CommandClass qui ont ces id et dont je n’utilises pas les fonctions.

A part sur l’ID 113 qui qui n’est pas déjà désactivé pour les smokesensor sur la commande alerte test, les autres sont soit déjà « getsupported=false » soit j’utilise les fonctions.

Apparemment j’ai un peu de chance et je ne vais pas y gagner beaucoup … ou alors j’ai rien capté car j’ai un réseau qui démarre en 213 secondes pour 19 modules.

[Domatizer]

@Bison

ou alors j’ai rien capté car j’ai un réseau qui démarre en 213 secondes pour 19 modules.

Maintenant que je suis arrivé à 1 minute pour 25 modules, je trouve ça long ! Lors du redémarrage note bien tous les modules dont les messages sont jetés ou non délivrés c’est-a-dire avec l’erreur suivante

ERROR: Dropping command, expected response not received after 1 attempt(s)

Puis regarde les requêtes qui ont posé problème comme celle-ci

2020-04-24 04:39:30.572 Info, Node156, Sending (Send) message (Callback ID=0x7a, Expected Reply=0x04) - AlarmCmd_Get (Node=156): 0x01, 0x0c, 0x00, 0x13, 0x9c, 0x05, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0x7a, 0x52
2020-04-24 04:39:38.571 Error, Node156, ERROR: Dropping command, expected response not received after 1 attempt(s)

Ici, le timeout=8secondes donc pénalité de 8 secondes à chaque erreur

J’ai identifié 4 requêtes mal supportées sur l’ensemble de mes modules

• BasicCmd_Get : COMMAND_CLASS_BASIC (0x20) 32
• SwitchAllCmd_Get : COMMAND_CLASS_SWITCH_ALL (0x27) 39
• SensorBinaryCmd_Get : COMMAND_CLASS_SENSOR_BINARY (0x30) 48
• AlarmCmd_Get : COMMAND_CLASS_ALARM (0x71) 113

Ensuite, tu vérifies sur l’équipement Jeedom si la classe en question qui pose souci est utilisée, exemple ici un Dimmer 2

Pas de classe 113 utilisée dans les commandes du Dimmer 2, je n’exploite pas la gestion des alarmes du modules. Je peux donc rajouter sans problème dans son fichier de config la ligne
<CommandClass id="113" getsupported="false"/>

[Bison]

Ahhhhhhhhh mais je croyais que l’on devait retrouver les ID dans les équipements et voir si on les utilisaient ou pas.
J’avais mal pigé, il faut bel et bien analyser les logs au démarrage et voir si on a des timeout puis vérifier sur l’équipement en question. Merci je pense que je verrais du coup bien plus de problème

[Domatizer]

Une trouvaille concernant la classe 113.

Je reprend l’exemple du Fibaro Dimmer 2. En observant bien, il y a différentes requêtes AlarmCmd_Get et seule la première plante !

2020-04-24 04:39:30.572 Info, Node156, Sending (Send) message (Callback ID=0x7a, Expected Reply=0x04) - AlarmCmd_Get (Node=156): 0x01, 0x0c, 0x00, 0x13, 0x9c, 0x05, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0x7a, 0x52
2020-04-24 04:39:38.571 Error, Node156, ERROR: Dropping command, expected response not received after 1 attempt(s)

2020-04-24 04:39:38.573 Info, Node156, Sending (Send) message (Callback ID=0x7b, Expected Reply=0x04) - AlarmCmd_Get (Node=156): 0x01, 0x0c, 0x00, 0x13, 0x9c, 0x05, 0x71, 0x04, 0x00, 0x04, 0x01, 0x25, 0x7b, 0x57
2020-04-24 04:39:38.618 Info, Node156, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Heat event:254, status=255

2020-04-24 04:39:38.621 Info, Node156, Sending (Send) message (Callback ID=0x7c, Expected Reply=0x04) - AlarmCmd_Get (Node=156): 0x01, 0x0c, 0x00, 0x13, 0x9c, 0x05, 0x71, 0x04, 0x00, 0x06, 0x01, 0x25, 0x7c, 0x52
2020-04-24 04:39:38.666 Info, Node156, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Access Control event:254, status=255

2020-04-24 04:39:38.669 Info, Node156, Sending (Send) message (Callback ID=0x7d, Expected Reply=0x04) - AlarmCmd_Get (Node=156): 0x01, 0x0c, 0x00, 0x13, 0x9c, 0x05, 0x71, 0x04, 0x00, 0x07, 0x01, 0x25, 0x7d, 0x52
2020-04-24 04:39:38.714 Info, Node156, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:254, status=255

2020-04-24 04:39:38.717 Info, Node156, Sending (Send) message (Callback ID=0x7e, Expected Reply=0x04) - AlarmCmd_Get (Node=156): 0x01, 0x0c, 0x00, 0x13, 0x9c, 0x05, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x7e, 0x5e
2020-04-24 04:39:38.762 Info, Node156, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Power Management event:254, status=255

Les valeurs sont bien remontées pour 4 d’entre elles sur les 5

• Heat
• Access Control
• Burglar
• Power Management

Ce qui change, c’est bien l’index de la classe 113 (jeu des 5 diférences)

2020-04-24 04:39:30.572 Info, Node156, Sending (Send) message (Callback ID=0x7a, Expected Reply=0x04) - AlarmCmd_Get (Node=156): 0x01, 0x0c, 0x00, 0x13, 0x9c, 0x05, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0x7a, 0x52
2020-04-24 04:39:38.573 Info, Node156, Sending (Send) message (Callback ID=0x7b, Expected Reply=0x04) - AlarmCmd_Get (Node=156): 0x01, 0x0c, 0x00, 0x13, 0x9c, 0x05, 0x71, 0x04, 0x00, 0x04, 0x01, 0x25, 0x7b, 0x57
2020-04-24 04:39:38.621 Info, Node156, Sending (Send) message (Callback ID=0x7c, Expected Reply=0x04) - AlarmCmd_Get (Node=156): 0x01, 0x0c, 0x00, 0x13, 0x9c, 0x05, 0x71, 0x04, 0x00, 0x06, 0x01, 0x25, 0x7c, 0x52
2020-04-24 04:39:38.669 Info, Node156, Sending (Send) message (Callback ID=0x7d, Expected Reply=0x04) - AlarmCmd_Get (Node=156): 0x01, 0x0c, 0x00, 0x13, 0x9c, 0x05, 0x71, 0x04, 0x00, 0x07, 0x01, 0x25, 0x7d, 0x52
2020-04-24 04:39:38.717 Info, Node156, Sending (Send) message (Callback ID=0x7e, Expected Reply=0x04) - AlarmCmd_Get (Node=156): 0x01, 0x0c, 0x00, 0x13, 0x9c, 0x05, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x7e, 0x5e

Les index demandés sont :

• 0x00
• 0x04
• 0x06
• 0x07
• 0x08

La description se cache dans ces 2 fichiers :

• plugins/openzwave/resources/openzwaved/config/Localization.xml
• plugins/openzwave/resources/openzwaved/configNotificationCCTypes.xml

Et la correspondance est la suivante

• 4 = Heat
• 6 = Access Control
• 7 = Burglar
• 8 = Power Management

Ces 4 demandes fonctionnent bien mais il n’y a rien de défini pour l’index 0 et justement la commande qui foire envoie l’index 0x00 !!!

Pour résoudre le souci, il faudrait trouver un moyen pour éviter l’envoi de l’index 0x00 avec AlarmCmd_Get. Y a-t-il un expert openzwave dans le coin ?

C’est con, sans ce problème d’index 0, la classe 113 semble bien supportée autrement.

[Domatizer]

@Bison

il faut bel et bien analyser les logs au démarrage

Tout part de là ! Bon courage !

[Domatizer]

Analyse du jour : problèmes d’ACK en conséquence des timeout

Maintenant que j’ai de moins en d’erreurs, je vois de plus en plus clair et donc je progresse de plus en plus vite. Je me suis intéressé aux quelques/rares messages suivants :

• Nombre de messages non-sollicités alors qu’en attente d’ACK
• Nombre de ACK retournés en erreur
• Nombre de retours inattendus

Voici le log lors du 1er réveil du module Aeotec Doos Sensor 7 pour lequel je n’ai pas vraiment pu enlever les command class qui ont des souci car elles sont utilisées dans les commandes de l’équipement.

2020-04-24 02:13:16.968 Info, Node099, Received Battery report from node 99: level=100
2020-04-24 02:13:17.014 Info, Node099, Received Wakeup Notification from node 99
2020-04-24 02:13:17.014 Info, Node099,   Node 99 has been marked as awake
2020-04-24 02:13:17.018 Info, Deleting all return routes from node 99
2020-04-24 02:13:17.020 Info, Node099, Sending (Command) message (Callback ID=0xf8, Expected Reply=0x47) - ControllerCommand_DeleteAllReturnRoutess (Node=99): 0x01, 0x05, 0x00, 0x47, 0x63, 0xf8, 0x26
2020-04-24 02:13:17.028 Info, Node099, Received reply to FUNC_ID_ZW_DELETE_RETURN_ROUTE - command in progress
2020-04-24 02:13:17.176 Info, Node099, Received Wakeup Notification from node 99
2020-04-24 02:13:17.599 Info, Node099, Received reply to FUNC_ID_ZW_DELETE_RETURN_ROUTE for node 99 - SUCCESS
2020-04-24 02:13:17.601 Info, Assigning return route from node 99 to node 1
2020-04-24 02:13:17.603 Info, Node099, Sending (Command) message (Callback ID=0xf9, Expected Reply=0x46) - ControllerCommand_AssignReturnRoute (Node=99): 0x01, 0x06, 0x00, 0x46, 0x63, 0x01, 0xf9, 0x24
2020-04-24 02:13:17.616 Info, Node099, Received reply to FUNC_ID_ZW_ASSIGN_RETURN_ROUTE - command in progress
2020-04-24 02:13:18.470 Info, Node099, Received reply to FUNC_ID_ZW_ASSIGN_RETURN_ROUTE for node 99 - SUCCESS
2020-04-24 02:13:18.473 Info, Node099, Sending (WakeUp) message (Callback ID=0x15, Expected Reply=0x13) - NoOperation_Set (Node=99): 0x01, 0x09, 0x00, 0x13, 0x63, 0x02, 0x00, 0x00, 0x25, 0x15, 0xb4
2020-04-24 02:13:18.538 Info, Node099, Request RTT 65 Average Request RTT 65
2020-04-24 02:13:18.542 Info, Node099, Number of association groups reported for node 99 is 4.
2020-04-24 02:13:18.543 Info, Node099, Get MultiChannelAssociation for group 1 of node 99
2020-04-24 02:13:18.544 Info, Node099, Sending (Send) message (Callback ID=0xfa, Expected Reply=0x04) - MultiChannelAssociationCmd_Get (Node=99): 0x01, 0x0a, 0x00, 0x13, 0x63, 0x03, 0x8e, 0x02, 0x01, 0x25, 0xfa, 0xd4
2020-04-24 02:13:18.631 Info, Node099, Request RTT 87 Average Request RTT 76
2020-04-24 02:13:18.713 Info, Node099, Response RTT 168 Average Response RTT 168
2020-04-24 02:13:18.713 Info, Node099, Received Multi Instance Association report from node 99, group 1
2020-04-24 02:13:18.713 Info, Node099,   The group contains:
2020-04-24 02:13:18.713 Info, Node099,     Node 1
2020-04-24 02:13:18.713 Info, Node099, Get MultiChannelAssociation for group 2 of node 99
2020-04-24 02:13:18.713 Info, Node099, Sending (Send) message (Callback ID=0xfb, Expected Reply=0x04) - MultiChannelAssociationCmd_Get (Node=99): 0x01, 0x0a, 0x00, 0x13, 0x63, 0x03, 0x8e, 0x02, 0x02, 0x25, 0xfb, 0xd6
2020-04-24 02:13:18.823 Info, Node099, Request RTT 109 Average Request RTT 92
2020-04-24 02:13:18.902 Info, Node099, Response RTT 188 Average Response RTT 178
2020-04-24 02:13:18.902 Info, Node099, Received Multi Instance Association report from node 99, group 2
2020-04-24 02:13:18.902 Info, Node099,   The group contains:
2020-04-24 02:13:18.902 Info, Node099, Get MultiChannelAssociation for group 3 of node 99
2020-04-24 02:13:18.907 Info, Node099, Sending (Send) message (Callback ID=0xfc, Expected Reply=0x04) - MultiChannelAssociationCmd_Get (Node=99): 0x01, 0x0a, 0x00, 0x13, 0x63, 0x03, 0x8e, 0x02, 0x03, 0x25, 0xfc, 0xd0
2020-04-24 02:13:19.012 Info, Node099, Request RTT 106 Average Request RTT 99
2020-04-24 02:13:19.093 Info, Node099, Response RTT 186 Average Response RTT 182
2020-04-24 02:13:19.093 Info, Node099, Received Multi Instance Association report from node 99, group 3
2020-04-24 02:13:19.093 Info, Node099,   The group contains:
2020-04-24 02:13:19.093 Info, Node099, Get MultiChannelAssociation for group 4 of node 99
2020-04-24 02:13:19.097 Info, Node099, Sending (Send) message (Callback ID=0xfd, Expected Reply=0x04) - MultiChannelAssociationCmd_Get (Node=99): 0x01, 0x0a, 0x00, 0x13, 0x63, 0x03, 0x8e, 0x02, 0x04, 0x25, 0xfd, 0xd6
2020-04-24 02:13:19.203 Info, Node099, Request RTT 105 Average Request RTT 102
2020-04-24 02:13:19.282 Info, Node099, Response RTT 184 Average Response RTT 183
2020-04-24 02:13:19.282 Info, Node099, Received Multi Instance Association report from node 99, group 4
2020-04-24 02:13:19.282 Info, Node099,   The group contains:
2020-04-24 02:13:19.282 Info, Node099, Querying associations for node 99 is complete.
2020-04-24 02:13:19.287 Info, Node099, Sending (Command) message (Callback ID=0x00, Expected Reply=0x80) - Get Routing Info (Node=99): 0x01, 0x07, 0x00, 0x80, 0x63, 0x00, 0x00, 0x03, 0x18
2020-04-24 02:13:19.291 Info, Node099, Received reply to FUNC_ID_ZW_GET_ROUTING_INFO
2020-04-24 02:13:19.292 Info, Node099,     Neighbors of this node are:
2020-04-24 02:13:19.292 Info, Node099,     Node 1
2020-04-24 02:13:19.292 Info, Node099,     Node 45
2020-04-24 02:13:19.292 Info, Node099,     Node 48
2020-04-24 02:13:19.292 Info, Node099,     Node 76
2020-04-24 02:13:19.292 Info, Node099,     Node 78
2020-04-24 02:13:19.292 Info, Node099,     Node 82
2020-04-24 02:13:19.292 Info, Node099,     Node 89
2020-04-24 02:13:19.292 Info, Node099,     Node 92
2020-04-24 02:13:19.292 Info, Node099,     Node 97
2020-04-24 02:13:19.293 Info, Node099, CentralScene RequestState: 2
2020-04-24 02:13:19.293 Info, Node099, CentralScene: Not a StaticRequest
2020-04-24 02:13:19.293 Info, Node099, Sending (Query) message (Callback ID=0xfe, Expected Reply=0x04) - PowerlevelCmd_Get (Node=99): 0x01, 0x09, 0x00, 0x13, 0x63, 0x02, 0x73, 0x02, 0x25, 0xfe, 0x2e
2020-04-24 02:13:19.392 Info, Node099, Request RTT 98 Average Request RTT 100
2020-04-24 02:13:19.472 Info, Node099, Response RTT 178 Average Response RTT 180
2020-04-24 02:13:19.472 Info, Node099, Received a PowerLevel report: PowerLevel=Normal, Timeout=0
2020-04-24 02:13:19.475 Info, Node099, Sending (Query) message (Callback ID=0xff, Expected Reply=0x04) - WakeUpCmd_IntervalGet (Node=99): 0x01, 0x09, 0x00, 0x13, 0x63, 0x02, 0x84, 0x05, 0x25, 0xff, 0xdf
2020-04-24 02:13:19.582 Info, Node099, Request RTT 107 Average Request RTT 103
2020-04-24 02:13:19.663 Info, Node099, Response RTT 187 Average Response RTT 183
2020-04-24 02:13:19.663 Info, Node099, Received Wakeup Interval report from node 99: Interval=21600, Target Node=1
2020-04-24 02:13:19.665 Info, Node099, CentralScene RequestState: 4
2020-04-24 02:13:19.665 Info, Node099, CentralScene: Not a StaticRequest
2020-04-24 02:13:19.666 Info, Node099, Sending (Send) message (Callback ID=0x0a, Expected Reply=0x04) - BasicCmd_Get (Node=99): 0x01, 0x09, 0x00, 0x13, 0x63, 0x02, 0x20, 0x02, 0x25, 0x0a, 0x89
2020-04-24 02:13:19.770 Info, Node099, Request RTT 103 Average Request RTT 103
2020-04-24 02:13:27.666 Error, Node099, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-24 02:13:27.669 Info, Node099, Sending (Send) message (Callback ID=0x0b, Expected Reply=0x04) - SensorBinaryCmd_Get (Node=99): 0x01, 0x09, 0x00, 0x13, 0x63, 0x02, 0x30, 0x02, 0x25, 0x0b, 0x98
2020-04-24 02:13:27.720 Info, Node099, Request RTT 50 Average Request RTT 76
2020-04-24 02:13:35.669 Error, Node099, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-24 02:13:35.673 Info, Node099, Sending (Send) message (Callback ID=0x0c, Expected Reply=0x04) - AlarmCmd_Get (Node=99): 0x01, 0x0c, 0x00, 0x13, 0x63, 0x05, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0x0c, 0xdb
2020-04-24 02:13:43.673 Error, Node099, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-04-24 02:13:43.676 Info, Node099, Sending (Send) message (Callback ID=0x0d, Expected Reply=0x04) - AlarmCmd_Get (Node=99): 0x01, 0x0c, 0x00, 0x13, 0x63, 0x05, 0x71, 0x04, 0x00, 0x06, 0x01, 0x25, 0x0d, 0xdc
2020-04-24 02:13:45.666 Info, Node099, WARNING: ZW_SEND_DATA failed. No ACK received - device may be asleep.
2020-04-24 02:13:45.666 Info, Node099,   Node 99 has been marked as asleep
2020-04-24 02:13:45.667 Info, Node099, Node not responding - moving message to Wake-Up queue: AlarmCmd_Get (Node=99): 0x01, 0x0c, 0x00, 0x13, 0x63, 0x05, 0x71, 0x04, 0x00, 0x06, 0x01, 0x25, 0x0d, 0xdc
2020-04-24 02:13:45.667 Info, Node099, Node not responding - moving message to Wake-Up queue: AlarmCmd_Get (Node=99): 0x01, 0x0c, 0x00, 0x13, 0x63, 0x05, 0x71, 0x04, 0x00, 0x07, 0x01, 0x25, 0x0e, 0xde
2020-04-24 02:13:45.667 Info, Node099, Node not responding - moving message to Wake-Up queue: BatteryCmd_Get (Node=99): 0x01, 0x09, 0x00, 0x13, 0x63, 0x02, 0x80, 0x02, 0x25, 0x0f, 0x2c
2020-04-24 02:13:45.667 Info, Node099, Node not responding - moving QueryStageComplete command to Wake-Up queue
2020-04-24 02:13:51.467 Warning, WARNING: Unexpected Callback ID received

Lors du réveil, les 3 commandes mal supportées BasicCmd_Get SensorBinaryCmd_Get et AlarmCmd_Get font perdre ici beaucoup trop de temps (3x8=24 secondes). La conséquence est que le module se rendort avant la fin de l’interview et donc on se reprend des warning supplémentaires du style

Node099, WARNING: ZW_SEND_DATA failed. No ACK received - device may be asleep.
Warning, WARNING: Unexpected Callback ID received

Il faudra donc attendre le prochain réveil pour terminer l’interview.

Ainsi le %OK ne peut pas commencer à 100% lors du 1er réveil (moi qui cherche du 100% vert)
L’interview devrait pouvoir se terminer entièrement du premier coup.
D’où l’intéret de ne pas avoir ces commandes non supportées.
C’est pire en sécurisé car les communication sont plus longues.

EDIT: J’ai modifié le fichier config zwa008.xml pour virer la classe COMMAND_CLASS_BASIC, ainsi l’erreur avec le BasicCmd_Get a disparu.
De plus, j’avais 3 modules identiques dont 1 qui n’avait pas de problème avec SensorBinaryCmd_Get. Un espoir ! En fait, c’était dû à l’inclusionen faite en mode sécurisé (ce module gère le niveau S2) alors que le module fonctionnait pourtant en non sécurisé (je n’avais pas de cadenas quelque soit le mode d’inclusion). L’inclusion normale m’a fait disparaitre l’erreur SensorBinaryCmd_Get. Ainsi, je ne perds pas la fonction Tilt de ce module et il ne me reste plus que l’erreur avec AlarmCmd_Get. Par conséquent, en évitant 2 timeouts, je n’ai plus le problème d’ACK que je viens d’expliquer dans ce post.

[Bison]

Salut,

Bon je viens de redémarrer le Daemon et je suis en debug info.
Les seules lignes « Not Supported on this node » sont celles-ci :

Line 1790: 2020-04-25 16:42:01.004 Info, Node007, AlarmCmd_Get Not Supported on this node
Line 1859: 2020-04-25 16:42:03.320 Info, Node012, AlarmCmd_Get Not Supported on this node
Line 3285: 2020-04-25 16:43:52.755 Info, Node025, AlarmCmd_Get Not Supported on this node

C’est pas énorme je crois pas que ça vaille le coup que je fasse comme toi pour peut-être gagner 3*8=24 secondes seulement.

Réseau démarré le 25/04/2020 16:40:08 opérationnel en 291 secondes
Le réseau contient **23** noeuds, actuellement **2** dorment

Il y a quand même un truc qui me chiffonne puisque ton réseau démarre en 64 secondes de mémoire et avec bien plus de modules. Qu’est-ce que j’ai pas compris ?

[naboleo]

Salut…

Jete un oeil aux nouvelles versions de ces fichiers, il y a justement des index 0 pour les multisensor dedans

https://raw.githubusercontent.com/OpenZWave/open-zwave/master/config/Localization.xml
https://raw.githubusercontent.com/OpenZWave/open-zwave/master/config/NotificationCCTypes.xml

[Domatizer]

@Bison

C’est pas énorme je crois pas que ça vaille le coup que je fasse comme toi pour peut-être gagner 3*8=24 secondes seulement.

Oui ce n’est pas beaucoup, et encore si tu as augmenté le timeout à 8 secondes sinon tu viens de gagné seulement 3x4=12 secondes !

J’avais des erreurs sur tous mes modules. J’ai pu corrigé les soucis pour mes 25 modules secteurs, ainsi j’ai pu gagné 25*4=100 secondes, ça se voit.

@Bison

Il y a quand même un truc qui me chiffonne puisque ton réseau démarre en 64 secondes de mémoire et avec bien plus de modules. Qu’est-ce que j’ai pas compris ?

Je suppose que tu n’avais pas que 3 modules qui produisaient des erreurs mais bien plus.
Tu n’as corrigé que 3 modules secteurs.
Peut-être que tu pouvais ou pas en corriger plus ?
Tu as quoi comme modules secteurs ?

Mon record est à 57 secondes !

Si un ou plusieurs modules à piles qui ont encore des problèmes se réveillent pendant le redémarrage, je me prends vite 8s, 16s, 24s de pénalité…

@naboleo

Jete un oeil aux nouvelles versions de ces fichiers, il y a justement des index 0 pour les multisensor dedans

Merci mais ce n’est pas la COMMAND_CLASS_NOTIFICATION (ex COMMAND_CLASS_ALARM). Le souci concernent la <CommandClass id="113"> où il n’y a pas de <Value index="0"> or AlarmCmd_Get est envoyé avec l’index 0x00 et ça plante !

2020-04-24 04:39:30.572 Info, Node156, Sending (Send) message (Callback ID=0x7a, Expected Reply=0x04) - AlarmCmd_Get (Node=156): 0x01, 0x0c, 0x00, 0x13, 0x9c, 0x05, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0x7a, 0x52
2020-04-24 04:39:38.571 Error, Node156, ERROR: Dropping command, expected response not received after 1 attempt(s)

Pour moi, il n’y à rien à définir pour l’index 0. Ceux sont les modules qui ne comprennent pas cette requête. Et il ne faut pas demander quelque chose à un module qui ne comprend pas.

Ou alors je n’ai pas compris

[naboleo]

Si tu es certain que c’est la requête au module qui n’est pas correcte alors effectivement ça ne changera rien.
Ce que je veux dire, c’est que tu pouvais essayer de te baser sur cet exemple pour ajouter un index 0 dans la classe 113. Celui de la classe 94 par exemple

		<Label>COMMAND_CLASS_ZWAVE_PLUS_INFO</Label>
		<Value index="0">
			<Help>ZWave+ Version Supported on the Device</Help>
			<Label>ZWave+ Version</Label>
		</Value>

Les valeurs ne seront pas bonnes, mais ça peux peut-être éliminer le cas d’une réponse du module qui n’est pas comprise.

[Bison]

@Domatizer

Je suppose que tu n’avais pas que 3 modules qui produisaient des erreurs mais bien plus.
Tu n’as corrigé que 3 modules secteurs.
Peut-être que tu pouvais ou pas en corriger plus ?
Tu as quoi comme modules secteurs ?

Je n’ai rien corrigé encore et pas touché à la valeur du timeout. Ce sont les seules erreurs « commandes non supportées » que j’ai après un redémarre.

En module alimentés en permanence j’ai des : FGR-223, MultiSensor 6 (ZW100), Smartplug, FGS-222 Double charge, FGBS-222 Smart Implant.
En module sur pile uniquement des FGSD-002 Smoke Sensor

Donc ça m’intrigue car vu le nombre de module que tu as et vu que tu as réussi à démarrer le zwave en 57 secondes, je devrais au pire être à 57+3*4= 69 donc il reste 222 secondes de trop.

Où alors c’est à cause des problèmes de dialogues que j’ai sur mon réseau (l’autre sujet sur lequel j’avais essayé de mettre mon dongle sur un PC avec Jeedom V4 sortit du carton).
Si 20% des commandes ne passent pas du 1er coup il doit perdre pas mal de temps à attendre et retenter. Enfin je sais pas, qu’est-ce que tu en penses ?

Exemple des logs d’un FGR-223 que j’ai séparé par bloc pour voir les temps qui pourrait sembler perdu (mais qui sont sans doute parfois normaux). Il n’y a finalement qu’une vraie erreur et pourtant il faut déjà 2mn 41 pour « démarrer ce module » :

	Line 36: 2020-04-25 16:40:08.542 Info, Node019, Central Scene - Created 1
	Line 88: 2020-04-25 16:40:08.589 Info, Node019, Node Identity Codes: 010f:0303:1000
	Line 89: 2020-04-25 16:40:08.589 Info, Node019, NoOperation::Set - Routing=true
	
-> 9 secondes
	Line 208: 2020-04-25 16:40:17.599 Info, Node019, Sending (NoOp) message (Callback ID=0x11, Expected Reply=0x13) - NoOperation_Set (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x00, 0x00, 0x25, 0x11, 0xc0
	Line 209: 2020-04-25 16:40:17.628 Info, Node019, Request RTT 27 Average Request RTT 27

-> 10 secondes
	Line 263: 2020-04-25 16:40:27.813 Info, Node019, Sending (Command) message (Callback ID=0x28, Expected Reply=0x47) - ControllerCommand_DeleteAllReturnRoutess (Node=19): 0x01, 0x05, 0x00, 0x47, 0x13, 0x28, 0x86
	Line 264: 2020-04-25 16:40:27.823 Info, Node019, Received reply to FUNC_ID_ZW_DELETE_RETURN_ROUTE - command in progress
	Line 265: 2020-04-25 16:40:28.070 Info, Node019, Received reply to FUNC_ID_ZW_DELETE_RETURN_ROUTE for node 19 - SUCCESS
	Line 267: 2020-04-25 16:40:28.074 Info, Node019, Sending (Command) message (Callback ID=0x29, Expected Reply=0x46) - ControllerCommand_AssignReturnRoute (Node=19): 0x01, 0x06, 0x00, 0x46, 0x13, 0x01, 0x29, 0x84
	Line 268: 2020-04-25 16:40:28.090 Info, Node019, Received reply to FUNC_ID_ZW_ASSIGN_RETURN_ROUTE - command in progress
	Line 269: 2020-04-25 16:40:28.729 Info, Node019, Received reply to FUNC_ID_ZW_ASSIGN_RETURN_ROUTE for node 19 - SUCCESS
	
-> 48 secondes
	Line 826: 2020-04-25 16:41:16.698 Info, Node019, Number of association groups reported for node 19 is 3.
	Line 827: 2020-04-25 16:41:16.698 Info, Node019, Get MultiChannelAssociation for group 1 of node 19
	Line 828: 2020-04-25 16:41:16.698 Info, Node019, Sending (Send) message (Callback ID=0x52, Expected Reply=0x04) - MultiChannelAssociationCmd_Get (Node=19): 0x01, 0x0a, 0x00, 0x13, 0x13, 0x03, 0x8e, 0x02, 0x01, 0x25, 0x52, 0x0c
	Line 832: 2020-04-25 16:41:16.727 Info, Node019, Request RTT 28 Average Request RTT 27
	Line 833: 2020-04-25 16:41:16.742 Info, Node019, Response RTT 43 Average Response RTT 43
	Line 834: 2020-04-25 16:41:16.742 Info, Node019, Received Multi Instance Association report from node 19, group 1
	Line 835: 2020-04-25 16:41:16.743 Info, Node019,   The group contains:
	Line 836: 2020-04-25 16:41:16.743 Info, Node019,     Node 1
	Line 837: 2020-04-25 16:41:16.743 Info, Node019, Get MultiChannelAssociation for group 2 of node 19
	Line 838: 2020-04-25 16:41:16.743 Info, Node019, Sending (Send) message (Callback ID=0x53, Expected Reply=0x04) - MultiChannelAssociationCmd_Get (Node=19): 0x01, 0x0a, 0x00, 0x13, 0x13, 0x03, 0x8e, 0x02, 0x02, 0x25, 0x53, 0x0e
	Line 839: 2020-04-25 16:41:16.771 Info, Node019, Request RTT 27 Average Request RTT 27
	Line 840: 2020-04-25 16:41:16.791 Info, Node019, Response RTT 47 Average Response RTT 45
	Line 841: 2020-04-25 16:41:16.791 Info, Node019, Received Multi Instance Association report from node 19, group 2
	Line 842: 2020-04-25 16:41:16.791 Info, Node019,   The group contains:
	Line 843: 2020-04-25 16:41:16.791 Info, Node019, Get MultiChannelAssociation for group 3 of node 19
	Line 844: 2020-04-25 16:41:16.792 Info, Node019, Sending (Send) message (Callback ID=0x54, Expected Reply=0x04) - MultiChannelAssociationCmd_Get (Node=19): 0x01, 0x0a, 0x00, 0x13, 0x13, 0x03, 0x8e, 0x02, 0x03, 0x25, 0x54, 0x08
	Line 845: 2020-04-25 16:41:16.820 Info, Node019, Request RTT 27 Average Request RTT 27
	Line 846: 2020-04-25 16:41:16.834 Info, Node019, Response RTT 42 Average Response RTT 43
	Line 847: 2020-04-25 16:41:16.835 Info, Node019, Received Multi Instance Association report from node 19, group 3
	Line 848: 2020-04-25 16:41:16.835 Info, Node019,   The group contains:
	Line 849: 2020-04-25 16:41:16.835 Info, Node019, Querying associations for node 19 is complete.
	
-> 12 secondes
	Line 1337: 2020-04-25 16:41:24.620 Info, Node019, Sending (Command) message (Callback ID=0x00, Expected Reply=0x80) - Get Routing Info (Node=19): 0x01, 0x07, 0x00, 0x80, 0x13, 0x00, 0x00, 0x03, 0x68
	Line 1341: 2020-04-25 16:41:26.128 Info, Node019, Received reply to FUNC_ID_ZW_GET_ROUTING_INFO
	Line 1342: 2020-04-25 16:41:26.128 Info, Node019,     Neighbors of this node are:
	Line 1343: 2020-04-25 16:41:26.128 Info, Node019,     Node 1
	Line 1344: 2020-04-25 16:41:26.128 Info, Node019,     Node 2
	Line 1345: 2020-04-25 16:41:26.128 Info, Node019,     Node 3
	Line 1346: 2020-04-25 16:41:26.128 Info, Node019,     Node 4
	Line 1347: 2020-04-25 16:41:26.128 Info, Node019,     Node 7
	Line 1348: 2020-04-25 16:41:26.128 Info, Node019,     Node 12
	Line 1349: 2020-04-25 16:41:26.128 Info, Node019,     Node 18
	Line 1350: 2020-04-25 16:41:26.128 Info, Node019,     Node 20
	Line 1351: 2020-04-25 16:41:26.128 Info, Node019,     Node 21
	Line 1352: 2020-04-25 16:41:26.128 Info, Node019,     Node 22
	Line 1353: 2020-04-25 16:41:26.128 Info, Node019,     Node 23
	Line 1354: 2020-04-25 16:41:26.128 Info, Node019,     Node 24
	Line 1355: 2020-04-25 16:41:26.128 Info, Node019,     Node 26
	Line 1356: 2020-04-25 16:41:26.128 Info, Node019,     Node 27
	Line 1357: 2020-04-25 16:41:26.129 Info, Node019,     Node 31
	Line 1358: 2020-04-25 16:41:26.129 Info, Node019,     Node 36
	Line 1359: 2020-04-25 16:41:26.129 Info, Node019,     Node 37
	Line 1360: 2020-04-25 16:41:26.129 Info, Node019,     Node 38
	Line 1567: 2020-04-25 16:41:28.340 Info, Node019, CentralScene RequestState: 2
	Line 1568: 2020-04-25 16:41:28.340 Info, Node019, CentralScene: Not a StaticRequest

-> 8 secondes
	Line 2180: 2020-04-25 16:42:36.680 Info, Node019, Sending (Query) message (Callback ID=0x8e, Expected Reply=0x04) - PowerlevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x73, 0x02, 0x25, 0x8e, 0x2e
	Line 2181: 2020-04-25 16:42:36.707 Info, Node019, Request RTT 26 Average Request RTT 26
	Line 2182: 2020-04-25 16:42:36.722 Info, Node019, Response RTT 41 Average Response RTT 42
	Line 2183: 2020-04-25 16:42:36.722 Info, Node019, Received a PowerLevel report: PowerLevel=Normal, Timeout=0
	Line 2184: 2020-04-25 16:42:36.724 Info, Node019, Sending (Query) message (Callback ID=0x8f, Expected Reply=0x04) - ProtectionCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x75, 0x02, 0x25, 0x8f, 0x29
	Line 2185: 2020-04-25 16:42:36.751 Info, Node019, Request RTT 26 Average Request RTT 26
	Line 2186: 2020-04-25 16:42:36.766 Info, Node019, Response RTT 41 Average Response RTT 41
	Line 2187: 2020-04-25 16:42:36.766 Info, Node019, Received a Protection report: Unprotected
	Line 2188: 2020-04-25 16:42:36.768 Info, Node019, CentralScene RequestState: 4
	Line 2189: 2020-04-25 16:42:36.768 Info, Node019, CentralScene: Not a StaticRequest
	Line 2190: 2020-04-25 16:42:36.769 Info, Node019, Sending (Send) message (Callback ID=0xcf, Expected Reply=0x04) - SwitchBinaryCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x25, 0x02, 0x25, 0xcf, 0x39
	Line 2191: 2020-04-25 16:42:36.796 Info, Node019, Request RTT 26 Average Request RTT 26
	Line 2208: 2020-04-25 16:42:39.550 Info, Node019, Request RTT 2781 Average Request RTT 1403
	Line 2221: 2020-04-25 16:42:40.389 Info, Node019, Request RTT 3621 Average Request RTT 2512
	Line 2234: 2020-04-25 16:42:40.510 Info, Node019, Request RTT 3742 Average Request RTT 3127
	Line 2247: 2020-04-25 16:42:40.669 Info, Node019, Request RTT 3901 Average Request RTT 3514
	Line 2265: 2020-04-25 16:42:44.773 Info, Node019, Sending (Send) message (Callback ID=0xd0, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xd0, 0x25
	Line 2266: 2020-04-25 16:42:44.801 Info, Node019, Request RTT 27 Average Request RTT 1770
	Line 2267: 2020-04-25 16:42:44.844 Info, Node019, Response RTT 71 Average Response RTT 56
	Line 2268: 2020-04-25 16:42:44.844 Info, Node019, Received SwitchMultiLevel report: level=99
	Line 2269: 2020-04-25 16:42:44.846 Info, Node019, Sending (Send) message (Callback ID=0xd1, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): SwitchMultilevelCmd_Get (Node=19): 0x01, 0x0d, 0x00, 0x13, 0x13, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x02, 0x25, 0xd1, 0x49
	Line 2270: 2020-04-25 16:42:44.874 Info, Node019, Request RTT 27 Average Request RTT 898
	Line 2271: 2020-04-25 16:42:44.918 Info, Node019, Response RTT 71 Average Response RTT 63
	Line 2272: 2020-04-25 16:42:44.918 Info, Node019, Received a MultiChannelEncap from node 19, endpoint 1 for Command Class COMMAND_CLASS_SWITCH_MULTILEVEL
	Line 2273: 2020-04-25 16:42:44.918 Info, Node019, Received SwitchMultiLevel report: level=99
	Line 2274: 2020-04-25 16:42:44.918 Info, Node019, Sending (Send) message (Callback ID=0xd2, Expected Reply=0x04) - MultiChannel Encapsulated (instance=3): SwitchMultilevelCmd_Get (Node=19): 0x01, 0x0d, 0x00, 0x13, 0x13, 0x06, 0x60, 0x0d, 0x01, 0x02, 0x26, 0x02, 0x25, 0xd2, 0x49
	Line 2275: 2020-04-25 16:42:44.947 Info, Node019, Request RTT 28 Average Request RTT 463
	Line 2276: 2020-04-25 16:42:44.990 Info, Node019, Response RTT 71 Average Response RTT 67
	Line 2277: 2020-04-25 16:42:44.990 Info, Node019, Received a MultiChannelEncap from node 19, endpoint 2 for Command Class COMMAND_CLASS_SWITCH_MULTILEVEL
	Line 2278: 2020-04-25 16:42:44.990 Info, Node019, Received SwitchMultiLevel report: level=99
	Line 2279: 2020-04-25 16:42:44.990 Info, Node019, Sending (Send) message (Callback ID=0xd3, Expected Reply=0x04) - MeterCmd_Get (Node=19): 0x01, 0x0a, 0x00, 0x13, 0x13, 0x03, 0x32, 0x01, 0x00, 0x25, 0xd3, 0x33
	Line 2280: 2020-04-25 16:42:45.018 Info, Node019, Request RTT 28 Average Request RTT 245
	Line 2281: 2020-04-25 16:42:45.069 Info, Node019, Response RTT 79 Average Response RTT 73
	Line 2282: 2020-04-25 16:42:45.070 Info, Node019, Received Meter report from node 19: Energy=0.32kWh
	Line 2283: 2020-04-25 16:42:45.072 Info, Node019, Sending (Send) message (Callback ID=0xd4, Expected Reply=0x04) - MeterCmd_Get (Node=19): 0x01, 0x0a, 0x00, 0x13, 0x13, 0x03, 0x32, 0x01, 0x10, 0x25, 0xd4, 0x24
	Line 2284: 2020-04-25 16:42:45.100 Info, Node019, Request RTT 27 Average Request RTT 136
	Line 2285: 2020-04-25 16:42:45.148 Info, Node019, Response RTT 75 Average Response RTT 74
	Line 2286: 2020-04-25 16:42:45.148 Info, Node019, Received Meter report from node 19: Power=0.0W
	Line 2287: 2020-04-25 16:42:45.150 Info, Node019, Sending (Send) message (Callback ID=0xd5, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): MeterCmd_Get (Node=19): 0x01, 0x0e, 0x00, 0x13, 0x13, 0x07, 0x60, 0x0d, 0x01, 0x01, 0x32, 0x01, 0x00, 0x25, 0xd5, 0x58
	Line 2288: 2020-04-25 16:42:45.179 Info, Node019, Request RTT 27 Average Request RTT 81
	Line 2289: 2020-04-25 16:42:45.231 Info, Node019, Response RTT 80 Average Response RTT 77
	Line 2290: 2020-04-25 16:42:45.231 Info, Node019, Received a MultiChannelEncap from node 19, endpoint 1 for Command Class COMMAND_CLASS_METER
	Line 2291: 2020-04-25 16:42:45.232 Info, Node019, Received Meter report from node 19: Energy=0.32kWh
	Line 2292: 2020-04-25 16:42:45.236 Info, Node019, Sending (Send) message (Callback ID=0xd6, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): MeterCmd_Get (Node=19): 0x01, 0x0e, 0x00, 0x13, 0x13, 0x07, 0x60, 0x0d, 0x01, 0x01, 0x32, 0x01, 0x10, 0x25, 0xd6, 0x4b
	Line 2293: 2020-04-25 16:42:45.264 Info, Node019, Request RTT 28 Average Request RTT 54
	Line 2294: 2020-04-25 16:42:45.313 Info, Node019, Response RTT 76 Average Response RTT 76
	Line 2295: 2020-04-25 16:42:45.313 Info, Node019, Received a MultiChannelEncap from node 19, endpoint 1 for Command Class COMMAND_CLASS_METER
	Line 2296: 2020-04-25 16:42:45.313 Info, Node019, Received Meter report from node 19: Power=0.0W
	Line 2297: 2020-04-25 16:42:45.316 Info, Node019, Sending (Send) message (Callback ID=0xd7, Expected Reply=0x04) - AlarmCmd_Get (Node=19): 0x01, 0x0c, 0x00, 0x13, 0x13, 0x05, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0xd7, 0x70
	Line 2298: 2020-04-25 16:42:45.344 Info, Node019, Request RTT 27 Average Request RTT 40
	Line 2299: 2020-04-25 16:42:45.359 Info, Node019, Response RTT 42 Average Response RTT 59
	
-> 4 secondes
	Line 2300: 2020-04-25 16:42:49.317 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)
	Line 2301: 2020-04-25 16:42:49.319 Info, Node019, Sending (Send) message (Callback ID=0xd8, Expected Reply=0x04) - AlarmCmd_Get (Node=19): 0x01, 0x0c, 0x00, 0x13, 0x13, 0x05, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0xd8, 0x77
	Line 2302: 2020-04-25 16:42:49.347 Info, Node019, Request RTT 28 Average Request RTT 34
	Line 2303: 2020-04-25 16:42:49.363 Info, Node019, Response RTT 43 Average Response RTT 51
	Line 2304: 2020-04-25 16:42:49.363 Info, Node019, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Power Management event:254, status=255
	Line 2305: 2020-04-25 16:42:49.367 Info, Node019, Sending (Send) message (Callback ID=0xd9, Expected Reply=0x04) - AlarmCmd_Get (Node=19): 0x01, 0x0c, 0x00, 0x13, 0x13, 0x05, 0x71, 0x04, 0x00, 0x09, 0x01, 0x25, 0xd9, 0x77
	Line 2306: 2020-04-25 16:42:49.395 Info, Node019, Request RTT 27 Average Request RTT 30
	Line 2307: 2020-04-25 16:42:49.411 Info, Node019, Response RTT 43 Average Response RTT 47
	Line 2308: 2020-04-25 16:42:49.411 Info, Node019, Received Alarm report: type=0, level=0, sensorSrcID=0, type:System event:254, status=255
	Line 2309: 2020-04-25 16:42:49.415 Info, Node019, Sending (Send) message (Callback ID=0xda, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): AlarmCmd_Get (Node=19): 0x01, 0x10, 0x00, 0x13, 0x13, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0xda, 0x00
	Line 2310: 2020-04-25 16:42:49.443 Info, Node019, Request RTT 28 Average Request RTT 29
	Line 2311: 2020-04-25 16:42:49.459 Info, Node019, Response RTT 44 Average Response RTT 45
	Line 2312: 2020-04-25 16:42:49.459 Info, Node019, Received a MultiChannelEncap from node 19, endpoint 1 for Command Class COMMAND_CLASS_APPLICATION_STATUS
	Line 2314: 2020-04-25 16:42:49.460 Info, Node019, Sending (Send) message (Callback ID=0xdb, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): AlarmCmd_Get (Node=19): 0x01, 0x10, 0x00, 0x13, 0x13, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0xdb, 0x09
	Line 2315: 2020-04-25 16:42:49.489 Info, Node019, Request RTT 29 Average Request RTT 29
	Line 2316: 2020-04-25 16:42:49.505 Info, Node019, Response RTT 45 Average Response RTT 45
	Line 2317: 2020-04-25 16:42:49.505 Info, Node019, Received a MultiChannelEncap from node 19, endpoint 1 for Command Class COMMAND_CLASS_ALARM
	Line 2318: 2020-04-25 16:42:49.505 Info, Node019, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Power Management event:254, status=255
	Line 2319: 2020-04-25 16:42:49.509 Info, Node019, Sending (Send) message (Callback ID=0xdc, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): AlarmCmd_Get (Node=19): 0x01, 0x10, 0x00, 0x13, 0x13, 0x09, 0x60, 0x0d, 0x01, 0x01, 0x71, 0x04, 0x00, 0x09, 0x01, 0x25, 0xdc, 0x0f
	Line 2320: 2020-04-25 16:42:49.538 Info, Node019, Request RTT 28 Average Request RTT 28
	Line 2321: 2020-04-25 16:42:49.554 Info, Node019, Response RTT 44 Average Response RTT 44
	Line 2322: 2020-04-25 16:42:49.554 Info, Node019, Received a MultiChannelEncap from node 19, endpoint 1 for Command Class COMMAND_CLASS_ALARM
	Line 2323: 2020-04-25 16:42:49.554 Info, Node019, Received Alarm report: type=0, level=0, sensorSrcID=0, type:System event:254, status=255

[JcDenis]

Ne vous plaignez pas !

747 secondes pour démarrer en journée
Je vais essayer de me pencher sur la question, et reviendrais ici le cas échéant.

[Domatizer]

@naboleo

Si tu es certain que c’est la requête au module qui n’est pas correcte alors effectivement ça ne changera rien.
Ce que je veux dire, c’est que tu pouvais essayer de te baser sur cet exemple pour ajouter un index 0 dans la classe 113. Celui de la classe 94 par exemple

Je vois l’idée, mais pourquoi ces 2 fichiers n’auraient pas été mis à jour et il n’y pas d’index 0 avec la version 1.6 d’openzwave. Je crains que ce soit la requête au module qui n’est pas correcte. Comment éviter d’envoyer une requête précise ?

@Bison

Je n’ai rien corrigé encore et pas touché à la valeur du timeout.

Donc tu es à 4 secondes de trop par erreur comme on peut le voir dans ton log.

@Bison

Donc ça m’intrigue car vu le nombre de module que tu as et vu que tu as réussi à démarrer le zwave en 57 secondes, je devrais au pire être à 57+3*4= 69 donc il reste 222 secondes de trop.

J’ai 62 modules dont 25 sur secteurs. Ces 25 modules avait tous des erreurs que j’ai corrigé, donc c’est là que j’ai gagné les 25*4 = 100 secondes. Le temps des modules sur piles n’est pas compté.

Lorsque j’effectue des modifs sur le réseau, le temps de redémarrage est bien plus long que la minute.
C’est lorsque le réseau est clean que j’obtiens un bon temps puisqu’il fait le minimum truc.
Tu peux enchaîner les redémarrage pour comparer.

@Bison

Exemple des logs d’un FGR-223 que j’ai séparé par bloc pour voir les temps qui pourrait sembler perdu (mais qui sont sans doute parfois normaux). Il n’y a finalement qu’une vraie erreur et pourtant il faut déjà 2mn 41 pour « démarrer ce module » :

2mn41, c’est le temps cumulé avec tous les autres modules.
Pendant les pauses où tu as noté les temps, soit 1m27, il s’occupe de tous les autres modules

Le réseau procède en plusieurs passes: il met à jour les scènes, le test du nœud, les routes, les associations, les voisins puis les infos du nœuds.

Si tu regardes le temps du module seul, c’est correct. C’est la mise à jour des infos du nœud où il perd du temps, il galère 8 secondes avec SwitchBinaryCmd_Get (Les valeurs du ping ne sont pas bonnes RTT 2781 RTT 3621 RTT 3742 RTT 3901). Dans la page santé, le ping doit est rouge ?Ton module capte mal ? Refais un redémarrage pour voir si c’est toujours pareil.

Line 2190: 2020-04-25 16:42:36.769 Info, Node019, Sending (Send) message (Callback ID=0xcf, Expected Reply=0x04) - SwitchBinaryCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x25, 0x02, 0x25, 0xcf, 0x39
Line 2191: 2020-04-25 16:42:36.796 Info, Node019, Request RTT 26 Average Request RTT 26
Line 2208: 2020-04-25 16:42:39.550 Info, Node019, Request RTT 2781 Average Request RTT 1403
Line 2221: 2020-04-25 16:42:40.389 Info, Node019, Request RTT 3621 Average Request RTT 2512
Line 2234: 2020-04-25 16:42:40.510 Info, Node019, Request RTT 3742 Average Request RTT 3127
Line 2247: 2020-04-25 16:42:40.669 Info, Node019, Request RTT 3901 Average Request RTT 3514
Line 2265: 2020-04-25 16:42:44.773 Info, Node019, Sending (Send) message (Callback ID=0xd0, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=19): 0x01, 0x09, 0x00, 0x13, 0x13, 0x02, 0x26, 0x02, 0x25, 0xd0, 0x25

Ensuite, tu as la même erreur que moi, la première AlarmCmd_Get bloque la queue 4 seconde ici

Line 2297: 2020-04-25 16:42:45.316 Info, Node019, Sending (Send) message (Callback ID=0xd7, Expected Reply=0x04) - AlarmCmd_Get (Node=19): 0x01, 0x0c, 0x00, 0x13, 0x13, 0x05, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0xd7, 0x70
Line 2298: 2020-04-25 16:42:45.344 Info, Node019, Request RTT 27 Average Request RTT 40
Line 2299: 2020-04-25 16:42:45.359 Info, Node019, Response RTT 42 Average Response RTT 59
-> 4 secondes
Line 2300: 2020-04-25 16:42:49.317 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)

C’est celle-ci que tu peux enlever en modifiant le fichier config comme je l’ai détaillé plus haut.

@Bison Donc, je dirais que tu perds 12 secondes de trop avec ce module lorsqu’il s’agit de mettre à jour les infos du nœud.

Pour mettre à jour les infos de tous les nœuds, mon réseau met 17 secondes en tout,
Pour info, je mets le log de mon démarrage en 57s openzwaved_57s.log (300,3 Ko)

Une vrai Formule 1 Là, je vérifier la tenue de route, pas un seul dérapage depuis
Nombre de messages non remis au réseau : 0
Encore quelques chicanes.
Avec ce que j’ai expliqué dans ce sujet, j’ai divisé par 3 le nombres d’erreurs de queue sortante bloquées
Nombre de messages jetés ou non délivrés : 37 (encore dans les modules sur piles au lieu de plus d’une centaine avant)

[Bison]

Le truc de dingue c’est que j’avais pas eu de plantage (la queue ne dépile plus) depuis au moins 2 semaines et là ça fait 3 fois en 2 jours depuis que j’ai redémarré pour voir les logs et chercher les erreurs. Je suis deg.

[Domatizer]

@naboleo

Ce que je veux dire, c’est que tu pouvais essayer de te baser sur cet exemple pour ajouter un index 0 dans la classe 113. Celui de la classe 94 par exemple

J’ai lu à plusieurs reprises que l’index 0 correspondait à « General Alarm » comme ici

Alarm Command Class

enum { Alarm_General = 0, Alarm_Smoke, Alarm_CarbonMonoxide, Alarm_CarbonDioxide, Alarm_Heat, Alarm_Flood, Alarm_Access_Control, Alarm_Burglar, Alarm_Power_Management, Alarm_System, Alarm_Emergency, Alarm_Clock, Alarm_Appliance, Alarm_HomeHealth, Alarm_Count }; (you should check the Source of the Alarm CommandClass for updated list as this might change).

J’ai donc défini un index 0 pour la classe 113 dans les fichiers Localization.xml et NotificationCCTypes.xml , mais sans succès.
En fait, le module ne réponds pas à la demande. Alors, il faudrait éviter de demander ! Je ne vois pas comment faire sans virer la classe complètement.

En revanche, @Bison, ton nœud 19 répond mais ça timeout aussi ! Pourrais-tu augmenter le timeout ?

Line 2297: 2020-04-25 16:42:45.316 Info, Node019, Sending (Send) message (Callback ID=0xd7, Expected Reply=0x04) - AlarmCmd_Get (Node=19): 0x01, 0x0c, 0x00, 0x13, 0x13, 0x05, 0x71, 0x04, 0x00, 0x00, 0x01, 0x25, 0xd7, 0x70
Line 2298: 2020-04-25 16:42:45.344 Info, Node019, Request RTT 27 Average Request RTT 40
Line 2299: 2020-04-25 16:42:45.359 Info, Node019, Response RTT 42 Average Response RTT 59 -> 4 secondes
Line 2300: 2020-04-25 16:42:49.317 Error, Node019, ERROR: Dropping command, expected response not received after 1 attempt(s)

@Bison

Le truc de dingue c’est que j’avais pas eu de plantage (la queue ne dépile plus) depuis au moins 2 semaines et là ça fait 3 fois en 2 jours depuis que j’ai redémarré pour voir les logs et chercher les erreurs. Je suis deg.

Bizarre, les redémarrages successifs devraient améliorer les choses…

[naboleo]

@Domatizer

J’ai donc défini un index 0 pour la classe 113 dans les fichiers Localization.xml et NotificationCCTypes.xml , mais sans succès.
En fait, le module ne réponds pas à la demande. Alors, il faudrait éviter de demander ! Je ne vois pas comment faire sans virer la classe complètement.

Comme ça c’est certain, c’est coté requête qu’il faut corriger

[Bison]

@Domatizer

En revanche, @Bison, ton nœud 19 répond mais ça timeout aussi ! Pourrais-tu augmenter le timeout ?

À quel endroit faut il augmenter le timeout déjà ?

[Domatizer]

@naboleo

Comme ça c’est certain, c’est coté requête qu’il faut corriger

J’aimerais bien. Si tu as d’autres idées ?

Bémol, la requête AlarmCmld_Get avec l’index 0 fonctionne avec le module Fibaro Smart Implant. C’est le seul module que j’ai qui n’a pas de timeout pour l’index 0, je ne comprends pas pourquoi.

@Bison

À quel endroit faut il augmenter le timeout déjà ?

Dans le fichier plugins/openzwave/resources/openzwaved/config/options.xml

<Option name="RetryTimeout" value="8000" />