J’ai un comportement assez bizarre sur mon réseau Zwave. J’ai beaucoup de modules sur lesquels j’ai des loupés. Parfois, lors de l’envoi de commandes, le module ne réagit pas.
Quand je regarde sur la page de santé Zwave, j’en ai beaucoup dont le pourcentage de « OK » ne sont pas à 100%. Cela concerne 26 modules sur secteurs et 12 sur piles sur un total de 94 noeuds. Je peux comprendre que les modules sur piles ne reçoivent pas forcément un message car ils sont en veille mais pour les modules secteurs, ils devraient toujours recevoir les messages. Pour la plupart d’entre eux, il y a une route directe avec le contrôleur. Voir mon tableau ci-joint dans lequel j’ai fait apparaître uniquement les modules qui ont des pertes.
J’ai déjà tenté de soigner les modules concernés, de mettre à jour les noeuds voisins et de mettre à jour la route de retour vers le contrôleur mais j’ai toujours ces pertes.
J’ai aussi tenté de soigner le réseau mais il n’arrive pas à aller au bout, la file d’attente augmente sans cesse et fini par faire planter le plugin au bout d’un moment. Le fait de soigner le réseau devrait en effet être assez long car j’ai des modules sur piles qui ont des wake up très élevés (supérieur à 24 heures pour certains) mais le plugin ne devrait pas planter. Peut être est-ce du au nombre élevé de modules ?
Lorsque j’ai tenté de soigner le réseau, j’ai aussi eu des modules qui ont été exclus/inclus automatiquement pour lesquels il a fallu que je les reconfigure complètement . Du coup, je ne suis pas très chaud pour tenter de nouveau de soigner le réseau.
Comment pourrais-je avancer sur mon problème ? Une idée.
Si je comprends bien votre tableau, vous avez beaucoup de périphériques inclus de façon sécurisée, et il a toujours été dit que les messages sur les réseaux sécurisés génèrent beaucoup de latence.
Oui, en effet, j’en ai beaucoup qui sont inclus en mode sécurisé. Cela peut effectivement générer de la latence mais normalement pas de perte. Et puis même si cela ne concerne que peu de modules, il y en une partie qui ne sont pas inclus en sécurisé pour lesquels j’ai aussi le soucis.
Au niveau des logs Zwave, j’ai ces 2 erreurs qui reviennent très souvent :
ERROR: Dropping command, expected response not received after 1 attempt(s)
ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack
Mais pas uniquement sur des noeuds pour lesquels j’ai des pertes. Les messages sont aussi présent pour des noeuds qui n’ont pas de perte.
D’ailleurs, je n’ai pas l’impression que le pourcentage de OK soit réinitialisé à chaque redémarrage du plugin. Compte t-il depuis la création (inclusion) du module ?
Les noeuds qui dorment ne génèrent pas de KO dans la communication lorsqu’ils dorment. Les messages sont simplement mis de côté et seront transmis au noeud lorsque ce dernier se réveillera. Ouf ! Car un module sur pile classique (si l’on oublie les modules FLiRS) passent 99,99% de leur temps à dormir, tu aurais sinon un ratio bien proche de zéro.
Je constate qu’après un redémarrage, les stats OK/KO bougent beaucoup plus rapidement que lorsque mon système est allumé depuis longtemps. Je pense donc que les stats ne portent pas sur toute la durée d’utilisation depuis l’inclusion.
Pour revenir sur ce message : ZW_SEND_DATA could not be delivered to Z-Wave stack
Je pense que les KO sont générés lorsque le message a effectivement été envoyé par le controleur ZWave, et que l’envoi sur le réseau ZWave n’a pas aboutti. Hors, quand tu as ce message de log, le message n’a pas été envoyé par le controleur Zwave. Il y a eu un problème en amonit, qui fait que l’envoi a été annulé.
Bonjour @Bull, merci pour ta participation. Attention, il est bien question de latence. En effet,pour avoir fait des tests et benchmark sur le ZWave,avec plusieurs modules, je te confirme que lorsque j’inclue le même module ZWave en sécurisé, j’observe une latence supplémentaire dans la communication par rapport à une inclusion en non sécurisé. Nous parlons de quelques centaines de millisecondes tout au plus. Attention, en aucun cas cela justifie un dysfonctionnement, ou une perte d’ordre. (tu peux faire le test simple avec un scénario qui boucle sur l’allumage et extinction d’une lumière par exemple, et qui attend le changement d’état de la dite lumière avant d’envoyer l’ordre suiant → la lumière clignote plus rapidement en inclusion non sécurisée, mais elle clignote quand même en inclusion sécurisée)
J’avais des doutes concernant le bon fonctionnement du mode sécurisé et entre temps je suis tombé sur le post suivant Re: Stabilité du zwave: c’était mieux avant ! (maj 2019-04-10 15:50:21) dans lequel @dJuL (au passage merci @dJuL pour ton retour d’expérience) explique avoir rencontré le même type de problème et la solution a été de réinclure tout ses modules en mode non sécurisé. Cela faisait déjà un moment que je voulais le faire car j’avais déjà lu ici et là que le mode sécurisé engendrait plus de problèmes qu’il n’apportait d’avantage, mais compte tenu du nombre de module que j’ai, et que la sécurité était un élément important à mes yeux, je n’avais jamais franchi le pas.
A choisir entre un système sécurisé mais non fiable et un système non sécurisé mais fiable, il a fallu faire un choix et le post indiqué m’a convaincu. Depuis quelques jours c’est chose faite (réinclusion de tout les modules en mode non sécurisé) et franchement c’est le jour et la nuit. Cela m’a pris pas mal de temps (J’ai d’abord fait tout les modules sur secteur puis les modules sur piles) mais les latences sont beaucoup plus faibles, ce que je peux comprendre par la lourdeur des échanges en mode sécurisé, mais surtout les pertes ont quasiment disparues.
Pour les modules associés en direct, la latence est aussi beaucoup plus faible. La différence est visible à l’œil nu par exemple pour une lumière qui est associée à une autre. L’allumage/extinction de la seconde est instantanée quand la première est allumée/éteinte.
Sur 93 modules, il m’en reste seulement 7 avec un pourcentage de OK qui ne sont pas à 100% (2 à 97%, 3 à 98%, 2 à 99%) alors qu’avant j’en avais 39 en dessous de 100% et cela descendait jusqu’à 76%.
La réactivé des modules est bien meilleure et le démarrage de mon réseau Zwave est aussi beaucoup plus rapide (J’ai bien gagné 5 minutes en passant de plus de 800 secondes à moins de 500). J’ai envie de dire normal puisqu’il y a moins de latence qu’en mode sécurisé.
Maintenant il serait intéressant de comprendre pourquoi ce mode sécurisé est-il si capriceux. Quand il a fallu que je fasse un choix sur « LE » protocole domotique que j’allais choisir, le fait que le Zwave soit sécurité était un élément très important à mes yeux, mais là, ça perd tout son sens … De plus, avec l’arrivée des modules en S2, qu’est ce cela va donner avec Jeedom ?
Concernant le point 3, je ne peux malheureusement pas accéder au lien indiqué :
merci pour vos témoignages qui m’ont aussi amené à passer des modules sécurisés (qubino ZMNHCD1) en mode non sécurisé : j’avais aussi des pertes de communication et des dysfonctionnement aléatoires, principalement lorsque l’ouverture/fermeture des volets se déroulait en mode synchrone.
Il me reste encore 2 modules sécurisés (Fibaro), qui eux ne semblent pas rencontrer de soucis. Est-ce donc un problème qubino?
D’expérience, il faut éviter le mode sécurisé au maximum, et surtout dans le cas de communication bi-directionnelles avec des modules.
J’ai gardé pour la sécurité quelques modules critiques en sécurisés avec qui le contrôleur n’envoie aucune commande (détection d’ouverture ou de mouvement). Là ça pose pas trop de problème. Ça chie beaucoup plus avec des modules que le contrôleur pilote (lumière, prises, têtes thermo…)
. Du coup, je ne suis pas très chaud pour tenter de nouveau de soigner le réseau.
