Zwave Dropping Command lors du "Get"

Osiris76 · Novembre 9, 2020, 10:29

Salut a tous,
Je galère depuis le début avec ces foutues erreurs sur mon Zwave
« ERROR: Dropping command, expected response not received after 1 attempt(s) »
j’ai une Smart avec le Zwave embarqué.
J’ai suivi le super post de Domotizer pour identifier certaines classes qui posaient problème et les retirer des confs des modules.
Aujourd’hui j’ai beaucoup moins d’erreurs mais encore pas mal persistent…
Après épluchage des logs, je m’apercois que lorsque la demande de SET est faite, le résultat est systématiquement OK, mais tout de suite après il fait un Get pour relire l’état (je suppose), et c’est a ce moment la que le Dropping command apparait. (j’ai remarqué qu’il apparait à 90% sur les Qubino)

Exemple ici on voit bien que le Set est envoyé pour mettre la valeur:

2020-11-09 10:08:04.381 Info, Node081, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 2 -
2020-11-09 10:08:04.381 Info, Node081, SwitchMultilevel::Set - Setting to level 0
2020-11-09 10:08:04.381 Info, Node081,   Duration: Default
2020-11-09 10:08:04.381 Detail, Node081, Queuing (Send) MultiChannel Encapsulated (instance=2): SwitchMultilevelCmd_Set (Node=81): 0x01, 0x0f, 0x00, 0x13, 0x51, 0x08, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x01, 0x00, 0xff, 0x25, 0x66, 0x4c
2020-11-09 10:08:04.382 Detail, Node081, Queuing (Refresh) MultiChannel Encapsulated (instance=2): SwitchMultilevelCmd_Get (Node=81): 0x01, 0x0d, 0x00, 0x13, 0x51, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x02, 0x25, 0x67, 0xbd
2020-11-09 10:08:04.382 Detail,
2020-11-09 10:08:04.382 Info, Node081, Sending (Send) message (Callback ID=0x66, Expected Reply=0x13) - MultiChannel Encapsulated (instance=2): SwitchMultilevelCmd_Set (Node=81): 0x01, 0x0f, 0x00, 0x13, 0x51, 0x08, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x01, 0x00, 0xff, 0x25, 0x66, 0x4c
2020-11-09 10:08:04.388 Detail, Node081,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-11-09 10:08:04.388 Detail, Node081,   ZW_SEND_DATA delivered to Z-Wave stack
=> bien envoyé

2020-11-09 10:08:04.450 Detail, Node081,   Received: 0x01, 0x05, 0x00, 0x13, 0x66, 0x00, 0x8f
2020-11-09 10:08:04.450 Detail, Node081,   ZW_SEND_DATA Request with callback ID 0x66 received (expected 0x66)
2020-11-09 10:08:04.450 Info, Node081, Request RTT 68 Average Request RTT 69
2020-11-09 10:08:04.450 Detail,   Expected callbackId was received
2020-11-09 10:08:04.450 Detail,   Expected reply was received
2020-11-09 10:08:04.450 Detail,   Message transaction complete
2020-11-09 10:08:04.450 Detail, Node081, Removing current message

Jusque la pas de problème, mais tout de suite après on voit que le Get arrive:

2020-11-09 10:08:04.450 Info, Node081, Sending (Refresh) message (Callback ID=0x67, Expected Reply=0x04) - MultiChannel Encapsulated (instance=2): SwitchMultilevelCmd_Get (Node=81): 0x01, 0x0d, 0x00, 0x13, 0x51, 0x06, 0x60, 0x0d, 0x01, 0x01, 0x26, 0x02, 0x25, 0x67, 0xbd
2020-11-09 10:08:04.457 Detail, Node081,   Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2020-11-09 10:08:04.457 Detail, Node081,   ZW_SEND_DATA delivered to Z-Wave stack
2020-11-09 10:08:04.524 Detail, Node081,   Received: 0x01, 0x05, 0x00, 0x13, 0x67, 0x00, 0x8e
2020-11-09 10:08:04.524 Detail, Node081,   ZW_SEND_DATA Request with callback ID 0x67 received (expected 0x67)
2020-11-09 10:08:04.524 Info, Node081, Request RTT 73 Average Request RTT 71
2020-11-09 10:08:04.524 Detail,   Expected callbackId was received
2020-11-09 10:08:08.451 Error, Node081, ERROR: Dropping command, expected response not received after 1 attempt(s)

Et 4 secondes plus tard l’erreur apparait.

Est-ce que c’est normal d’avoir systématiquement un GET directement après le SET pour relire la valeur?
Est-ce qu’il y a un paramètre quelque part pour modifier la tempo après le SET, pour éventuellement rajouter 1seconde juste avant de faire le GET ? (pour peut être laisser le temps au module de digérer le SET?)

J’ai le soucis majoritairement sur un Qubino ZMNHUD1.
Je l’ai aussi un peu moins souvent sur les ZMNHJD1…

J’ai désactivé les classes ci-dessous:

Merci

Domatizer · Novembre 19, 2020, 8:47

Merci

Timeout de 4s

Je pense que c’est pour le retour d’état.

Tu peux augmenter le timeout à 5s ou 8s au lieu de 4s. Cela laisse plus de temps. Mais si la commande n’est pas bien supportée, cela plantera tout de même au bout d’un temps plus long

Attention, il faut utiliser le getsupported="false" au cas par cas.
Si tu as plusieurs modules du même type, vérifie d’abord que tous les modules d’un même type ont le problème. Si t’en as un qui n’as pas de souci, c’est qu’il n’y a pas de souci avec cette classe.

Osiris76 · Novembre 20, 2020, 10:24

Salut @Domatizer ,
J’ai viré les classes que je n’utilise pas pour tous les Qubino car j’ai remarqué que le retour d’état était demandé de temps en temps sur les sensors et binary switch alors qu’ils ne sont pas utilisés dans mes commandes.
Comment modifies-tu le timeout de 4s ? c’est a quel endroit ?
Merci

Domatizer · Novembre 20, 2020, 10:37

Réponse ici

[EDIT] J’avais remarqué un truc : avec un long timeout, il faut bien « nettoyer » les classes mal supportées avant. En effet, les modules sur piles peuvent ne pas avoir le temps d’échanger toutes les infos durant leur réveil s’il y a une commande non supportée qui bloque la queue trop longtemps. Il faudra plusieurs réveils…

Osiris76 · Novembre 20, 2020, 11:01

Ca marche merci bien. De mon coté pas de module sur pile donc pas de probleme.
Vivement le vrai sdk zwave sur jeedom…

Osiris76 · Novembre 23, 2020, 2:11

Bon j’ai toujours des problèmes meme en changeant le timeout. Beaucoup de mes erreurs viennent du Get uniquement, donc pour le retour d’état.
Je viens de tomber sur un post d’@akenad

1) Retours d’état :
Depuis la mise à jour du plugin du 04-02-2019 (c’était donc il y a un an) (https://jeedom.github.io/plugin-openzwave/fr_FR/changelog ), il arrive que pour certains modules, certains retours d’états ne soient pas pris en compte par le plugin en configuration par défaut (identifiés par exemple pour certains modules double switch).
Un contournement est possible dans la configuration du module :
Equipement → Configuration → Valeurs
Changer le Rafaichissement de « Auto » à « 5 min ».
On perd le temps réel mais ce n’est pas forcement un problème, ça dépend de l’usage.

Est-ce que dans mon cas et sur mes qubinos cela pourrait répondre ?
Est-ce que cette valeur de rafraichissement est le temps entre le set et le get ? et donc le module va attendre 5 minutes avant de lancer le GET pour avoir l’état?
Ou alors est-ce que cette option va lancer un refresh toutes les 5 minutes ?
merci

Domatizer · Novembre 23, 2020, 2:20

Ouai, il faut vivre avec, j’ai le problème lorsque j’appuie sur l’inter de ma VMC, je ne regarde plus l’état du widget, mais je sais que physiquement il est bon (et c’est la bonne vitesse).

Oui, ça devrait rafraîchir la valeur toutes les 5 minutes car c’est Jeedom qui demande au module.
Je ne pense pas que cela va résoudre tes problèmes.

Le timeout permet au module d’avoir plus de temps pour répondre. Le contrôleur va attendre au maximum cette durée avant de déclarer un message « dropping command ».