Soucis sur mon réseau z-wave

Tags: #<Tag:0x00007f38637267b0>

J’ai vu qu’ils y avaient quelques post qui parle de soucis de stabilité au niveau du z-wave et je me permet d’ajouter ma petit goûte d’eau dans le vase :stuck_out_tongue:

Je fait un nouveau post, car je ne sais pas si le soucis vient de mon installation ou du plugin z-wave en lui même :confused:

Perso ça fait plusieurs mois que je rencontre des soucis de stabilité général sur mon réseau z-wave :confused:
Au début c’était des latences, maintenant c’est carrément des modules qui ne reçoivent pas les commandes en questions…
J’ai des modules qui passent en DEAD, que je suis obligés de soigner via les commandes (et même parfois de reboot électriquement)
J’ai également un module (ID 76) qui à 1 seul voisin alors que les 2 modules de chaque coté de celui-ci ont au minimum 10 voisins…

image

Sur mes scénarios principaux, j’en suis arrivé à mettre des check qui relance les commandes en cas de non réception des commandes (assez lourd à gérer…).

Voici mon maillage :
image

J’ai déjà regardé au niveau des logs et je n’ai aucune erreur :’(

Sinon au début j’était sur un RPI3 où j’avais uniquement des soucis de latence.
Ensuite je suis passé sur un RPI4 où j’ai commencé à avoir les soucis de modules qui ne reçoivent pas les commandes
Et maintenant je suis sur un LXC sous Proxmox où j’ai toujours les même soucis :’(

Ma config étant un AMD 3600X + 16Go de RAM + SSD avec un load overage moyen de 1, je ne pense pas que le soucis proviennent d’un manque de puissance.

Bref, je ne comprend pas trop ce qu’il arrive à mon Z-Wave et j’aurai bien besoin d’un coup de main car hier soir par exemple, le chauffage de la chambre de mon nouveau née n’a pas reçu la commande et il faisait 13°C dans celle-ci…

Merci d’avance :slight_smile:

En fait, si j’ai des erreurs, je ne regarder juste pas dans le bon fichier de log…

2020-02-29 23:27:05.996 Error, Node008, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-02-29 23:27:05.998 Error, Node070, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
2020-02-29 23:27:15.006 Error, Node070, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-02-29 23:29:07.391 Error, Node070, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-02-29 23:29:07.399 Error, Node004, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
2020-02-29 23:29:11.392 Error, Node004, ERROR: Dropping command, expected response not received after 2 attempt(s)
2020-02-29 23:30:07.678 Error, Node070, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-02-29 23:31:11.784 Error, Node070, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-02-29 23:32:07.002 Error, Node008, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-02-29 23:32:11.003 Error, Node070, ERROR: Dropping command, expected response not received after 2 attempt(s)

Salut,
Comment est réparti ton maillage?
Quelle est l’étendue de ton réseau ?
Quelle proportion entre modules sur pile et sur secteur ?

Si tu reprend ce screen, tt les modules Radiateurs, Volets et luminaires sont des modules alimenté au 220V (Le reste sur piles)

image

A savoir que les modules volets, font le tour de la maison et permette d’étendre mon réseau assez facilement.
Les modules radiateurs, sont regroupé dans mon tableau électrique.
Niveau surface, la maison est assez grande (230m2) et si tu prend le module “Radiateur Chambre Simon” c’est le plus loin de mon stick z-wave (à l’étage).

Je voulais savoir également, si il était possible de tuner le plugin afin d’en amélioré les performances vu que je dispose de pas mal de puissance de calcul pour le coup.

Comme ça je ne sais pas répondre et il est un peu tard, en revanche, voici le lien d’un code te permettant d’etre signaler et de réveiller automatiquement les nœuds DEAD.
Tu peux le lancer par scenario toutes les heures par exemple.

Le reste attendra demain, bonne nuit.

Merci déjà pour le script, j’avais justement une question à ce sujet afin d’être notifier en cas de noeud DEAD :stuck_out_tongue:

Sinon je viens de faire une petit schéma qui montre mon installation z-wave :

image

Rouge : Module sur 220v
Jaune : Module sur pile
Vert : Mon serveur principal où est plug mon stick z-wave

Bonjour,

Nous sommes très nombreux a avoir ce souci de dropping command…
Il n’y a aucune solution, moi ça dure depuis que je suis sous openzwave, sois 3 ans au moins. Pour contourner j’ai créé des scénarios de vérification des actions
ça touche d’autres plateformes que jeedom aussi…

Bien sur je précise que j’ai un réseau zwave avec un maximum de modules sur secteur, très bien maillé, et que, même des modules proches génèrent des dropping command. Mon stick aeon gen5 est sur une rallong usb, je suis sous proxmox i7 , mais c’était pareil avec l’odroid c2.
Sans rien faire, j’ai même un nouveau bug : je ne peux plus soigner un module : il est exclu et réinclu !..
Il faudrait attendre une refonte du plugin qui n’utilise pas le sdk du zwave qui est maintenant plublic, mais c’est un travail titanesque…

Bonjour,

Dropping command = problème de communication donc tous ceux qui ont des problèmes de communication ont des dropping commands donc oui “très nombreux à avoir ce souci” sans que ce soit forcément lié donc réflexion sans intérêt vraiment.

@m4dm4rtig4n: ta situation me fait penser au problème que j’ai eu récemment avec un module Qubino fil-pilote commandé sur Am**on. (voir ce post)

Finalement après avoir tout essayé retour du module pour la même référence commandée chez plan**e-domotique: tout est nickel !!
Si c’est principalement le module 70 qui pose des problèmes pour ma part je m’y intéresserai en détail.

@doryphore, ça ne ma rassure pas ton post :confused:
Moi qui voulez justement partir sur du z-wave car le protocole avait l’air fiable, je m’aperçois avec le temps que ce n’est pas tjr le cas :frowning:

@Salvialf, je pense effectivement que je vais devoir changer le module 70, ce qui me fait chiez c’est que comme toi je l’ai acheter sur Amazon et faire un retour sur Amazon ça veut dire renvoyer le produit directement chez Fibaro en Allemagne car il n’assure pas le SAV…

En plus j’ai remarquer que le plugin tourne en version 1.4 d’openzwave alors que la dernière stable est en 1.6, je me demande si nos soucis serait tjr présent avec la 1.6 :confused:

Moi aussi je l’ai acheté sur Amazon en expédié par Amazon. Comme l’achat était début décembre j’ai pu le renvoyer courant janvier.

C’est la 2ème fois que j’ai des problèmes avec un module acheté sur Amazon, je ne sais pas si c’est leur manière de stocker qui n’est pas bonne mais depuis ma dernière mauvaise expérience je n’achète plus de modules domotique en “expédié par Amazon”.

La lib openzwave n’y est pour rien, c’est sûr ce serait bon que le plugin soit mis à jour avec les dernières évolutions mais ça ne l’empêche en rien de fonctionner parfaitement chez des milliers d’utilisateurs.

Bref si vous avez des dropping command il faut remettre en cause votre installation, pas le plugin. Les causes peuvent être tellement multiples: l’environnement (mur, plancher béton, etc), matériels (puissance usb, défaillance module ou contrôleur, etc), logiciel (autres logiciels en parallèle de jeedom, debian avec interface graphique, mauvais paramètrage, etc)…
ça en fait des points à vérifier avant de mettre en cause le plugin !

Je me demande si mettre un “repeater” me permettrais de gagner en fiabilité pour l’instant.

J’ai également quelques modules que j’avais inclus en mode sécurisé, je vais les désinclure puis réinclure pour le coup car en fin compte, je ne pense pas qu’il soit vraiment utile d’avoir des modules qui pilotes mes chauffages en mode sécurisé…
Surtout que j’ai appris par la suite que le z-wave sécurisé est sur un network séparé du non-sécurisé…

Après hier soir j’ai eu une erreur très bizarre dans les logs :

 [2020-02-29 22:52:55][INFO] : 200 GET /network?type=info&info=getStatus&apikey=XXXXXXXXXXXXXXXXXXXX (127.0.0.1) 0.48ms
Unhandled exception in thread started by <bound method _Timer.bootstrap of <_Timer(Thread-36086, stopped daemon 139620713801472)>>
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 774, in bootstrap
    self.bootstrap_inner()
  File "/usr/lib/python2.7/threading.py", line 789, in bootstrap_inner
    del _limbo[self]
KeyError: <_Timer(Thread-36086, stopped daemon 139620713801472)>
[2020-02-29 22:52:58][INFO] : 200 GET /network?type=info&info=getStatus&apikey=XXXXXXXXXXXXXXXXXXXX (127.0.0.1) 0.41ms

lol j’ai eu la même réaction avec mon module récalcitrant du coup j’ai acheté un range extender Aeotec… Franchement je n’ai vraiment pas vu d’impact sur le réseau Zwave. Même une fois enlevé le module défaillant à première vue le range extender n’apportait rien dans mon cas (retourné également).

Bah quand je regarde mon maillage tt mes modules (a part le 70) on plus de 10 voisin donc je ne pense pas que ce soit une histoire de porté ou autre pour le coup, mais à vrai dire je séché :confused:

Salut,
De ce que j’ai pu mesurer le range extender a le même effet qu’un module secteur,
Il n’ampliffie pas vraiment le signal, mais sert plutôt de répéteur.
Après, d’accord avec vous pour les produits domotiques achetés sur Am*. Énormément de retours en ce qui me concerne. J’ai quelquefois pensé qu’il ne vendait pas les mêmes versions que les autres mais il y a vraiment un problème de qualité.

Idem, je cherche à améliorer la fiabilité du réseau Z-Wave depuis des mois. J’hésitais à recréer un n-ième sujet sur les soucis du réseau Z-Wave mais je vais continuer à la suite de celui-ci, c’est le plus récent.

Pour l’instant, la fiabilité du Z-Wave ne me convient pas, j’ai de bien meilleurs résultats avec du Chacon ou du X2D, c’est malheureux vu le prix.
Ce que ressent en pratique, c’est que 1 ordre sur 20 ne passe pas.

  • Détecteur de mouvement (que du Fibaro) qui reste actif (indéfiniement) jusqu’à ce qu’on repasse devant afin qu’il renvoie de nouveau un OFF lorsqu’on repart.
  • Ordre d’éteindre la lumière bien envoyé par Jeedom, mais la lumière est resté allumée (le retour d’état est pourtant bon).
    Cette fiabilité reste bien plus mauvaise que celle d’un humain qui oublierait d’éteindre la lumière

J’ai déjà passé des semaines et des mois à essayer de soigner ce p*t**n de réseau Z-Wave
Je n’ai pourtant que du vert et du bleu dans la matrice avec 60 modules (2 cases jaunes). Le contrôleur, lui, voit 85% modules en direct. Je n’ai pas plus de problèmes avec ceux qui sont éloignés et un peu seuls que ceux qui sont à 2m de la box. Quand je vois que certains modules Dimmer ont entre quarante et cinquante voisins (pas de problème de portée) et que l’ordre d’allumer/éteindre la lumière ne passe, je me demande pourquoi le réseau ne trouve pas un chemin pour faire passer son message.

Dans le log, je suis toujours en mode Debug, j’ai bien sûr de temps en temps les erreurs classiques du style

Error, NodeXXX, ERROR: Dropping command, expected response not received after 1 attempt(s)
Error, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
Detail, NodXXX, Notification: Notification - TimeOut

(des sujets avec ce type d’erreur, il y en a à la pelle sur les forums)

D’un point de vue général, je constate que de nombreux utilisateurs ont les mêmes soucis.
Je dirais que ces problèmes ont un certain coté aléatoire et c’est bien ce coté aléatoire qui nous rend fous.

Donc qu’est ce qui marche ? Qu’est ce qui ne marche pas ?
Les problèmes sont-ils logiciels (Debian, Jeedom, plugin openzwave, firmware), ou matériels (smart, raspi, clé zwave, modules…) ?

D’après certains sur le forum, il y a des milliers d’utilisateurs chez qui ça marche donc ce n’est pas Jeedom ni le le plugin openzwave, sinon ça se saurait.
De mon côté, j’avais remonté des soucis de fonctionnement de certains modules Fibaro, pareil : nous vendons énormément de produits Fibaro, s’il y avait un problème ça se saurait.

Effectivement, il y a des gens chez qui ça fonctionne. Mais chez d’autres, il y a bien des problèmes de communications Z-Wave, comment faire pour les résoudre ?
Souvent, on conseille un reboot, une exclusion puis une inclusion, avec parfois un reset du module en plus, mais c’est lourd et c’est plus du debug au pif sans comprendre.

Pour commencer, pourquoi lorsqu’on effectue une inclusion, on n’est pas sûr si elle est réussie à 100% ? c’est-dire que toutes les infos du nœud ainsi que toutes les commandes aient bien été générées ?
Par comparaison, lorsqu’on effectue un appairage WiFi ou Bluetooth, ça marche ou ça ne marche pas, mais pas partiellement.
Et en plus c’est sécurisé sans avoir à redémarrer la box internet ou le téléphone (quand je vois le cirque qu’il faut faire pour obtenir ce fichu cadenas vert dans le cas d’une inclusion sécurisée)

Alors maintenant, que peut-on faire pour limiter le nombre de messages “perdus”, où faut-il chercher en plus des fichiers de log ?

Nombre de messages non-sollicités alors qu’en attente d’ACK :
Nombre de retours inattendus :
Nombre de ACK retournés en erreur :
Nombre de messages non remis au réseau :
Nombre de messages jetés ou non délivrés :
Nombre de message retransmie :

Je ne constate des fois aucune erreur dans les statistiques d’un module, y compris un %OK=100% dans l’onglet Santé, alors qu’il y a bien eu des soucis de communication avec les modules à pile.

Comment connaître le taux d’utilisation de chaque module c’est-à-dire bande passante utilisée par chaque module ? Ainsi on pourrait avoir une idée s’il reste de la bande passante pour que le réseau puisse bien fonctionner.

Si j’ai 100 modules et qu’ils parlent plus 1% du temps, je vais avoir un problème.
J’aimerai bien un truc qui me dise, attention, 20% de la bande passante est utilisé par tel module, un peu comme pour le réseau Ethernet.
Exemple : les prises qui communiquent la puissance peuvent causer beaucoup si la puissance change fréquement, je me suis fait avoir avec une guirlande clignotante.
Faire des stats en regardant le fichier de log, c’est pas évident !

Le mode sécurisé est il bien vraiment bien supporté avec Jeedom/openzwave ?
J’ai lu à plusieurs reprises qu’il fallait tout inclure en mode non sécurisé pour que cela fonctionne bien.
Je constate également que j’ai moins de souci avec les modules non sécurisés. Globalement, je n’ai pas acheté des modules Z-Wave pour faire du non sécurisé.
Qu’en est-il exactement ?

Faut-il activer le mode SUC sur le contrôleur ?

Lorsqu’on a une charge du système à 15 min supérieure à 1 ou 2 voire 3, faut-il s’inquièter?
La charge du système a-t-elle un impact jusqu’à faire perdre des paquets ?
Ceux qui ont fait des tests un un pc de course (style CPU Intel Core i7, 8 ou 16GB de ram, SSD…), avez-vous eu de meilleurs résultats ?

Peut-on avoir une liste de clé USB / hub USB compatibles ou non avec le Z-Wave?
Typiquement, la clé Aeotec ne cohabite pas bien avec les clés 3G/4G, ces clé chinoises fonctionnent bien toutes seules mais pourrissent le bus USB.
Les clés se déconnectent toutes seules, se reconnectent, les ports USB changent, des conflits se créent et c’est la cata…

Pour infos, j’ai la config suivante

Jeedom 4.0.42 (1900 commandes, 260 équipements, environ 150 scenarii)
Raspberry Pi 3+ (Alim 2.5A)
Hub USB 2.0 7 Ports DLink DUB-H7 alimenté avec une alim 3A ou auto-alimenté
Clé 1-Wire Dallas Semiconductor DS9490R (sondes DS18B20)
Clé Aeotec Z-Stick Gen 5 ZW090 (modules uniquement Z-Wave+ et tous commandés sur des sites spécialisés domotique donc pas de référence douteuse qu’on peut retrouver chez le géant américain)
Clé 3G Huawei E3531 HSPA+
Clé ZiBlue RF Player 1000 (sondes Oregon + prises Chacon)
Pas de Bluetooth

Ceci relance encore le débat sur la fiabilité du Z-wave avec openzwave, mais il faut que ça marche. C’est vendu pour ça ! Il va falloir trouver une solution cette année sinon c’est mort avec l’arrivée des géants du numérique dans le domaine de la domotique. Ceux là, quand ils font quelque chose, ça marche, d’ailleurs, d’où vient leur succès ?

3 J'aimes

Salut
Pour te répondre sur une infime partie de ton long mais très intéressant message :
J’ai un hardware de la mort (Intel i7 8e gen, 16bg ram, ssd, charge a …0,01) et ça ne change rien

J’ai tout essayé, j’ai toujours des dropping comand ou not delivred stack
openzwaved.txt (172,0 Ko)

2020-03-01 19:10:10.030 Error, Node074, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-01 19:11:51.220 Error, Node043, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-01 19:11:52.200 Error, Node110, Cannot find endpoint map to instance for Command Class COMMAND_CLASS_BASIC endpoint 1
2020-03-01 19:11:52.219 Error, Node110, Cannot find endpoint map to instance for Command Class COMMAND_CLASS_BASIC endpoint 2
2020-03-01 19:11:52.276 Error, Node110, Cannot find endpoint map to instance for Command Class COMMAND_CLASS_BASIC endpoint 2
2020-03-01 19:12:06.395 Error, Node047, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-03-01 19:12:52.889 Error, Node110, Cannot find endpoint map to instance for Command Class COMMAND_CLASS_BASIC endpoint 1
2020-03-01 19:12:52.907 Error, Node110, Cannot find endpoint map to instance for Command Class COMMAND_CLASS_BASIC endpoint 2
2020-03-01 19:33:43.609 Error, Node041, ERROR: Dropping command, expected response not received after 1 attempt(s)
saisir ou coller le code ici

Pourtant je ne suis pas dans un environnement perturbé, mais comme tu dis, on n’a aucun moyen de vérifier l’encombrement du réseau dans le 868 mhz

Quelques petites remarque d’un galérien du Zwave. Dabord la pratique qui consiste à vérifier l’état d’une commande pour la renvoyer peut être la pire des solution. Zwave met les demandes en fille d’attente, si on renvoi des demandes qui passe mal elles bloquent les autres et les demandes s’accumulent jusqu’au blocage final (c’est du vécu).
La solution est de vérifier l’état de la pile et de ne renvoyer les demandes QUE lorsqu’elle est à zéro. Chez moi cela à éliminé 90 % des problèmes.

Deuxième point, vous focalisez tous sur des messages d’erreurs … qui n’en sont peut être pas !!! , lorsqu’un paquet ne passe pas Zwave le renvoi, il lui faut certaine fois (rarement) 2 voir 3 demandes avec certain module. Dans mon install de 50 modules j’ai 50-80 messages par jour, ce qui n’est pas énorme vu le nombre de transactions, c’est même négligeable … D’ailleurs l’onglet statistique, lui, indique très peu d’erreur.

La solution : dans la page de log faire ‘supprimer tous’, et la, miracle du core version Jeedom, il n’y à plus d’erreurs de zwave dans les logs (enfin … plus de messages :crazy_face:). C’est aussi valable pour pas mal d’autres plugin d’ailleurs !! :slight_smile: (il parait que l’on ne peut rien y faire d’après Loîc, on verra ça quand on aura le temps :mask:) .
La redirection sur ‘null’ avec linux, c’est un le trou noir de Stephen Hauking, plein de surprise :rofl::joy::rofl:

Dernière remarque, les fichiers de config qui sont mis à jour de manière totalement aléatoire (cf la série des fibaro walli), selon la version l’intégration fonctionnera nickel ou … “assez mal”. Comme nous ne sommes JAMAIS avertis de ces mises à jour ni de leur fréquence (STRICTEMENT AUCUNE comm’ autour de Zwave !!!), la moindre mise à jour ressemble à une roulette russe à effet retard … (ne me dite pas github … il y a des commit qui ont plus de deux ans !!!)

Ces remarques seulement pour dire que “globalement” la solution zwave jeedom fonctionne à 80-90%, le résiduel n’apparaissant que rarement et pouvant même passer inaperçu pour beaucoup (des lenteurs 'inexpliquées, des faux signaux rare mais quand même…, des multiples bouts de ficelle que chacun essaye de mettre dès que l’install domotique grossi …, des problème qui disparaissent "spontanément …)

Donc oui le ZWAVE de Jeedom fonctionne, mais entre les mains d’un bon geek et de beaucoup d’heures de tâtonnement perdues à essayer de comprendre l’incompréhensible :slight_smile:

quelques derniers conseils, ne cherchez pas à bidouiller du code pour nettoyer/réparer, au mieux c’est inutile, au pire vous ne ferez que vous enfoncer dans les problèmes sans rien arranger.

En cas de soucis : repérer le module qui a le plus de message d’erreur et vous faite “exclusion / raz d’usine/inclusion / REBOOT de Jeedom”, si l’inclusion à mal fonctionné on recommence jusqu’à …
Lorsque tous vos module ne produiront plus que 3-10 messages d’erreurs par jour, vous faites un snapshot que vous portez à la banque.

Donc dans ton cas, la puissance de ta machine n’est pas en cause.

Pour l’encombrement du réseau, je parlais de la charge du réseau lui-même s’il y a trop de modules qui veulent communiquer en même temps pas des perturbations externes (antenne relais ou émetteur TV à proximité) où malheureusement on ne peut pas faire grand chose à part subir. En revanche, je conseillerais de ne pas utiliser d’autres protocoles à 868MHz si possible dans un premier temps. Mais bon, le WiFi s’en sort très bien dans les immeubles, il y a du monde à 2.4GHz, tellement qu’on est passé aussi à 5GHz

J’ai regardé ton fichier de log, tu as le module 110 qui ne va pas bien du tout, la sentence pour lui, tu la connaît, c’est exclusion, puis inclusion à 1 mètre de box, puis mise à jour des voisins à sa position finale, tu soignes ce nœud en particulier jusqu’à guérison ou tu l’enlèves temporairement pour debuger le reste.

Je confirme, j’ai déjà passé beaucoup trop de temps a essayer d’avoir un truc correct et ce n’est pas fini

Non, quand je rentre dans ma salle de bain, que le détecteur de présence clignote (il m’a vu), et qu’ensuite la lumière ne s’allume pas, je focalise sur pourquoi le message n’est pas reçu (le détecteur reste bloqué à 1 donc il faut sortir de la pièce, attendre qu’il revienne au repos et refaire le singe devant le capteur pour espérer que le message soit bien passé la 2ème fois) ou lorsqu’il est bien reçu et que le scenario a bien envoyé la commande d’allumer, ça ne s’allume pas, là c’est pire, le contrôleur a en plus le bon retour d’état comme quoi la lumière n’a pu s’éteindre, mais que fait-il ? Heureusement qu’il y a toujours un inter :grinning:

J’ai l’impression que c’est la meilleure solution, mais c’est difficile de savoir si une inclusion a bien fonctionné ou pas sauf cas extrême avec pleins d’erreur. Alors dans le doute, on clique sur “Rafraîchir les infos du nœud”, “Récupérer les CC dynamiques”, “Rafraîchir les valeurs nœud”, “Soigner le nœud”, “Mise à jour des nœuds voisins”, entre temps on réveille plusieurs fois les modules piles, on attend, on recommence, on soigne le réseau puis module par module dans la matrice, le réseau guérit un peu tous les jours…

Dès fois, le module sur pile est vu comme un module secteur, donc considéré comme toujours réveillé, là pleins d’erreurs puisqu’il ne répond pas, normal il dort. Ici, c’est un cas facile, puisque je sais si mon module est sur pile ou non. Pour les autres infos, ce n’est pas à mois de savoir s’il y manque telle ou telle classe, si leurs adresses sont bonnes ou pas.

@m.georgein

Dabord la pratique qui consiste à vérifier l’état d’une commande pour la renvoyer peut être la pire des solution. Zwave met les demandes en fille d’attente, si on renvoi des demandes qui passe mal elles bloquent les autres et les demandes s’accumulent jusqu’au blocage final (c’est du vécu).

Ok, mais je fait comment alors pour être sûr que mes volets soit bien fermer ?

Sur mon 1er fix, j’envoyé 5 fois la même commandes mais j’ai effectivement eu un effet de bord qui est la saturation de la file d’attente comme tu dit :smiley:

Sur mon 2eme fix, je fais un check d’état avant de renvoyer une autre commande avec un sleep de 5s entre chaque nouvelle commande pour éviter de saturer la fils d’attente.
=> Je n’ai plus de saturation de la file d’attente, et mes volets reçoivent correctement une des commandes.

@Domatizer, j’ai également le même soucis sur un capteur Fibaro Eyes qui bloque réguliérement…

Pour mon module en erreur, je viens de faire un exclusion, reset, inclusion et c’est encore pire :smiley:
Plus aucun voisin pour celui-ci…

image

Attention, le fait de vérifier l’état ne dit pas que la file d’attente est vide, si tu as lancé plusieurs tentatives elle risque dans ce cas de ralentir/bloquer les demandes suivantes et on peut avoir un effet de cascade difficile à détecter.
Raison pour laquelle je préfère tester le retour à 0 la file d’attente AVANT de tester l’état et de renvoyer éventuellement d’autres demandes