Soucis sur mon réseau z-wave

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'aime »

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…

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

Tu teste comment le retour de fil d’attente à 0 pour le coup ?
Si ta un bout de code PHP je suis preneur :slight_smile:

Il faut bien insister en commençant comme indiqué dans l’onglet du module par “Soigner le nœud”, “Mise à jour des nœuds voisins” puis si ça ne va pas “Rafraîchir les infos du nœud”, “Récupérer les CC dynamiques”, “Rafraîchir les valeurs nœud”, entre temps on réveille plusieurs fois les modules piles, on attend, on recommence…

Le Z-Wave, réputé fiable et robuste, c’est comme un grand malade, il faut bien le soigner :laughing:

Concernant le module Fibaro Motion Sensor (Eye), j’en avait analysé un en particulier car dès fois le ON ou le OFF ne passait pas. En fait, il y avait bien des infos remontées dans tous les cas sauf que la valeur du « Burglar » n’était pas la même lorsque le true (ou false) fonctionnait et lorsque le true (ou false) ne fonctionnait pas. En clair, la valeur « Burglar » remontait à chaque détection ou fin de détection mais pas l’info du capteur « Sensor ». Pourquoi ? ==> Exclusion puis inclusion en non sécurisée et enfin OK

J’ai mis cette fonction dans mes utilitaires

function WaitBusy($timer = 5) {
	$networkState = openzwave::callOpenzwave('/network?type=info&info=getStatus');
	$queueSize = $networkState['result']['outgoingSendQueue'];
	while ($queueSize > 0) {
		$networkState = openzwave::callOpenzwave('/network?type=info&info=getStatus');
		$queueSize = $networkState['result']['outgoingSendQueue'];
		sleep($timer);
	}
	return 'ok';
}

@m.georgein
Thx :slight_smile:

@Domatizer, mon fibaro eyes est effectivement en mode sécurisé, je vais le passer en mode non sécurisé ainsi que tt mes autres modules demain pour voir si j’ai des améliorations.

Sinon j’ai passer en mode « aucun » log, et j’ai toujours mon fichier /var/www/html/log/openzwave qui est spam de message de debug oO

Bon courage, c’est ce que je devrais faire aussi, mais c’est très long. En effet, les nouvelles inclusions ne se passent pas bien du premier coup et je me retrouve comme toi avec des modules sans infos, je dois cliquer, cliquer et re cliquer… Pour un module ça va, mais pour des dizaines de modules… En plus, je perds les réglages des paramètres des modules. Pour les dimmers, il y a beaucoup d’option a changer, il faut tout recalibrer, c’est vraiment lourd. Je ne parle du cas où le système d’inclusion plante à force d’en faire et refaire, là c’est le redémarrage obligatoire du réseau Z-wave pour continuer les inclusions (Alors ici problème Jeedom ou openzwave ?). J’ai des modules de porte pour compter les impulsions eau et gaz, donc je dois couper la chaudière gaz, ne pas cuisiner, ne pas tirer de l’eau pendant le reboot. Il faut donc personne dans la maison pendant ce temps là, le soir on ne bidouille pas les dimmers. Pour le chauffage, ce n’est pas trop la bonne période pour jouer. Bref, c’est très ch**nt tout ça !

1 - Pour que le changement de log soit efficient il faut RELANCER le daemon

2 - L’astuce pour se mettre la tête dans le sable c’est dans la page des logs de faire « supprimer tous » :slight_smile:

Plus le réseau est gros plus il est conseillé de n’avoir aucun module en sécurisé. LE plugin ne tient pas en sécurisé

Je rebondis sur ton message car j’avais cette information et je pense n’avoir pas réalisé les inclusions en sécurisé.
Par contre l’état du cadenas dans ma page santé m’interpelle : dans la doc on voit le symbole d’un cadenas vraiment ouvert, alors que chez moi le symbole est plutôt entrouvert

Symbole repris dans la doc du plugin openzwave :

Salut,
Ne prête pas attention à ce pictogramme.
Il y a des cas où le système ne sait pas s’il s’gait d’un module en mode sécurisé ou pas.
Dans ce cas, le pictogramme doit ressembler à ça.