Soucis sur mon réseau z-wave

Ça fait 10 modules Z-Wave ! Et si ça marche dès les premières inclusions, que de temps gagné !
Et si je compare vraiment le temps passé à debugger (soit je suis mauvais, soit il y a un lézard ou plutôt un caméléon dans le plugin), ce n’est plus une question de prix, il aurait été plus rentable de l’acheter, mais elle n’existait pas il y à 3 mois.

Bonjour,

J’ai ré inclus en non sécurisé les principaux modules de portes Fibaro Door Sensor 2 avec lesquels j’observais des collisions. Et bien, je n’ai plus de collisions avec ces modules en non sécurisé. Soit je suis vraiment chanceux, soit il y a un petit souci de gestion des collisions avec certains modules en mode sécurisé. Maintenant, le Nombre de messages non remis au réseau et le Nombre de messages jetés ou non délivrés ont drastiquement diminué. Je pense que les messages non remis au réseau restants vont être résolu lorsque tout mon réseau sera en mode non sécurisé…

Pour les messages jetés ou non délivrés, ils sont principalement dus à la commande AlarmCmd_Get mal supportée, comme je l’avais remarqué dans mes premiers posts sur ce fil. Ces erreurs sont moins critiques, mais je pense qu’il y a vraiment moyen de gagner un temps énorme lors du démarrage du réseau. J’ai donc ouvert un autre sujet ici

1 « J'aime »

C’est fait, j’ai pris mon courage à 2 mains pour tout ré inclure en non sécurisé. De plus, j’ai modifié les fichiers de config de certains modules pour enlever les classes inutiles lorsque les requêtes finissent en timeout et bloquent la queue de plusieurs secondes à chaque fois. Explication dans l’autre sujet Optimisation du temps de démarrage du réseau Z-Wave

Avant, j’avais environ 10% des messages qui partaient je ne sais où !
Maintenant, à la fin du redémarrage, je n’ai plus du tout d’erreur et ça fonce

1 « J'aime »

Et le temps de démarrage réseau du coup ?

Bon maintenant plus qu’à remettre en sécurisé :wink: avec les XML de corrigé courage ! On va tous nous sortir de l’impasse !!

Bonjour a tous,

Pour information suite aux divers soucis que je rencontre avec mon Z-Wave et l’ampleur que mon post initial à prit (150 messages oO), je me suis décidé à migrer la totalité de celui-ci sur du MQTT.

Avantage :

  • Lib OpenZWave 1.6 :star_struck:
  • Aucune dépendance entre votre réseau Z-Wave & Jeedom (jeedom ne sais même pas qu’il pilote du z-wave)
  • Il est possible d’ajouter de la QoS afin de s’assurer que les commandes arrive bien (retry).
  • Outils de debug intégrée dans zwave2mqtt.
  • Compatibilité multi-box

Inconvénient :

  • Il faut récrée manuellement toutes les commandes des modules & widget.
  • Besoin d’un broker et des compétences qui vont avec (Mosquitto dans mon cas).
  • Besoin de dompter zwave2mqtt
  • Besoin de plus de ressource système

Bref, j’essaie de vous faire un retour pour vous dire si ceci résoud la totalité des problèmes :slight_smile:

Je vous met quelques screens de l’install :

Configuration des actions d’un FGD-212 de Fibaro :

Et ses widgets qui vont avec :

image

Salut,

Et aucun paquets ne part en dehors de ton réseau ? C’est du MQTT local ?

Il « suffit » d’installer un package zwave2mqtt sur Debian ?

Yep, t’installes un Mosquitto, la lib openzwaze que tu souhaites, et zwave2mqtt en parallèle de jeedom.

Et tt est en local, rien ne sort.

Un peu d’explication :

Dans mon cas j’ai remplacer Node-Red par Jeedom.

64-82 secondes. cf l’autre post

Dans tout mon réseau, j’ai laissé un seul module en sécurisé pour l’étude qui ne sert pas pour la domotique. Et bien, dans mes stats, depuis mon précédent post (pas de redémarrage entre temps) , je n’ai eu qu’un seul message non remis au réseau due à Error, ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack qui vient de ce seul module sécurisé.


Alors NON, pas de sécurisé pour moi !

Maintemant, si je fait le ratio entre le nombre des messages jetés ou non délivrés ou non remis au réseau et le nombre de messages correctement envoyés ou reçus, il n’y a pas photo !

Tu t’es lancé dans un sacré chantier !

Trop de boulot !!!

1 « J'aime »

Merci j’ai vu.
L’info qu’on a pas encore ici (sauf si je l’ai raté désolé) c’est est-ce que c’est le passage en mode non-sécurisé ou la suppression des class_command qui a eu le plus d’effet?

1 « J'aime »

Salut,
Ce qui me fait plaisir, c’est que tu as réussi à démontrer ce que je subodorais depuis longtemps et pour lequel je me faisais tailler régulièrement.
J’ai arrêté l’inclusion sécurisée depuis longtemps et je n’ai plus jamais eu de problème.
J’avais d’ailleurs arrêté de me battre pour ça.
Donc, oui, peut-être que je recommencerais à tenter le coup après le portage de la bibliothèque 1.6 mais sûrement pas avant.
Bonne journée

1 « J'aime »

En sécurisé, j’observais souvent des erreurs type ERROR: ZW_SEND_DATA could not be delivered to Z-Wave stack.

  • Soit les modules sécurisés déconnaient tous seuls
  • Soit les collisions avec des modules sécurisés étaient mal gérées et donc les communications des autres modules sécurisés ou pas ne passaient pas : voir plus haut l’exemple avec un Fibaro Dimmer 2 sécurisé ou pas qui n’arrivait pas à envoyer l’ordre d’allumer la lumière si au même instant un module de porte Fibaro Door Sensor 2 se mettait à échanger.

La suppression des COMMAND_CLASS a un impact sur les erreurs type ERROR: Dropping command, expected response not received after 1 attempt(s). Elles ne sont pas forcement critiques, mais comme expliqué dans l’autre post, il y a un blocage de la queue sortante de 4 secondes pour rien à chaque fois. En conséquence d’une queue bloquée jusqu’au timeout, je me demande si cela ne génère pas aussi des problèmes en plus de timeout pour les requêtes supportées mais qui n’auraient malheureusement pas eu le temps d’être traitées ? En effet, j’avais fait un essai de mettre le timeout à 1 seconde, et bien de nombreuses requêtes normalement supportées non juste plus le temps d’être traitées correctement et ça part en timeout.

Mais c’est bien le passage en mode non-sécurisé qui m’a permis d’avoir un réseau fonctionnel et non plus aléatoire (avec les collisions).

Je comprends

Pareil

Conclusion : on n’est donc pas sur des problèmes matériels !

Bon suite à mon précédent message et le passage en zwave2mqtt, voici mes 1er retours :

La lib openzwave 1.6 :

  • Ce n’est pas tout beau tout rose comme je l’avais imaginer…
    J’ai eu divers soucis qui m’ont obliger à inclure/relinclure une dizaine de fois certain modules.
    Bon l’avantage, c’est qu’on une interface zwave qui est bcp plus clair que ce qu’on peut avoir sur jeedom et me permet de comprendre plus en détail certaine choses :slight_smile:

  • Pour un bien (d’après ce que j’ai lu sur gitlab), il est conseiller de ré-inclure la totalité des modules directement en openzwave 1.6.
    => Ce qui va certainement rebuter pas mal de monde surtout si tu as 150 modules…

  • Je recontre actuellement un soucis avec les modules sur batterie qui n’arrivent pas à charger le « cache » de configuration au démarage de zwave2mqtt et sont donc inutilisable jusqu’au prochain « wakeup ».
    => J’ai une issue en cours chez OpenZWave.

  • Quand tu fouille un peu les différentes issue sur Githab, tu vois régulièrement des gens dire de repasser en 1.4 qui est considérer comme plus stable…
    Et ce qui est un peu contradictoire c’est que ttes issues créer pour du openzwave 1.4 sont automatiquement cloturer, le dev ne bosse plus que sur la 1.6…
    Donc en gros si ta un bug en 1.4, passe en 1.6 sinon tu n’aura pas de support.
    Si ta un bug en 1.6, repasse en 1.4 mais sans support/évolution.
    => :crazy_face::crazy_face::crazy_face::crazy_face::crazy_face:

MQTT ?

  • ca marche du feux de dieux et j’ai 0 latence.
    J’ai eu quelques soucis de latence au début, mais c’était à cause des « Dropping command » qui lorsqu’elle ce produise génère une latence de quelques secondes juste avant de pop.

Et j’ai retrouver tt mes bébés zwave :

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

  • Ce n’est qu’un au revoir ! :stuck_out_tongue:

  • Alors j’ai rencontrer principalement ce soucis avec certain module récalcitrants qui avait du mal à s’inclure…
    Ma procédure pour les dégager à était de faire un hard reset des modules en questions et de les ré-inclure derrière jusqu’à tant de ne plus en avoir du tout…
    => Très long et fastidieux surtout chez Qubino qui demande une coupure électrique et de relié à la phase 5x de suite une sortie le tout sous 220v…
    Surtout qu’il y a un bouton sur le module mais que ne fonctionnement uniquement que sur de la basse tension 24v…

  • Merci le « Replace failed node », qui m’a évité d’être à l’ID 150 et qui permet de remplacer le module défaillant sans en perdre l’id.

Création des modules sur jMQTT

  • Alors soit je suis passer à coté d’un truc, soit ça manque clairement de doc…
    Il y a certain modules où la création à était très simple, et d’autre comme les volets où j’ai mit 2j à trouver la commande pour envoyer le « Stop ».

  • Je me suis beaucoup aider du plugin zwave pour retrouver les commandes qui vont bien :stuck_out_tongue:

Bref prochaine étape Enocean2MQTT :slight_smile:

3 « J'aime »

Merci @m4dm4rtig4n pour ce retour

Et bien, je ne vais pas me presser pour le changement :smiley:

C’est un des points noir du Z-Wave ces exclusions/inclusions, c’est vraiment chronophage.
La mise en place d’une installation filaire prendrait moins temps…

Je voudrais désactiver certaines requêtes qui génère des timeout et donc Dropping command.
En 1.4, pas de support :sleepy:

Ouais, c’est bien ce que pense, que des emmerdes de soft !

Remarque : j’ai transféré mon Jeedom sur un ancien PC portable. Bon, pas de chance, il est moins puissant que le RPi3 et il a toujours une charge de 2 à 3 fois le max sauf la nuit où il est juste limite : il souffre en continu le pauvre, en attendant une nouvelle machine.
Et bien, le Z-Wave n’a pas plus de problème de Dropping command, etc.
J’ai tous mes modules avec un %OK à 100% excepté pour les modules Flirs (>98%)
Donc, les pertes Z-Wave ne sont pas dues au manque de puissance de la machine !

Huhu et ben on est pas rendu encore !

Un problème de gestion de l’USB par ton RPi3 comme cela pourrait être le cas sur mon NAS QNAP (VM Jeedom) ?

Note : j’ai changé ma clef zwave récemment par une Aeotec Gen5 et à première vue pas vraiment de meilleurs résultats donc ce n’est pas mon ancien dongle qui déconnait

Ah si, on y arrive ! Le passage en non sécurisé a résolu les bug aléatoires à la con.
De plus, le fait d’avoir nettoyer les commandes non supportées a bien aidé à avoir un truc plus propre.

Au bout de 5 jours sur une machine qui rame à mort, c’est aussi bon qu’avec le RPi3.

Le nombre de messages jetés ou non délivrés est de :

  • zéro (si tout va bien en principe) après le démarrage du réseau (réveils des modules secteurs)
  • une trentaine après le 1er réveil de tous les modules (cf l’autre post)
  • une vingtaine de plus les 5 jours suivants (certains modules se réveillent mal…)

Le nombre de messages non remis au réseau est de 6, à comparer avec les 5384 correctement envoyés. Et elles ont été générées seulement par les têtes thermostatiques Spirit (modules Flirs). 1 tête m’en a généré 4, sur plus de 640 (mais je lui envoie des infos toutes les 5 min avec une régulation PID externe, donc statistiquement, elle peut avoir plus de problème) et les 2 autres ont 1 erreur sur une centaine. Tous les autres modules n’ont eu aucune erreur : %OK à 100% partout. C’est vraiment bien donc le protocole Z-Wave est bon.

En revanche, j’ai toujours des doutes sur la qualité des ports USB du RPi3. Avec ce vieux PC portable, je n’ai pas eu un seul décrochage(déconnexion) des clés RFPlayer, GSM et TéléInfo. Pourtant, j’ai le même matos branchés sur le même hub USB. Donc le hub n’est pas en cause.

Bonjour,

Après 2 semaines d’utilisation de zwave2mqtt, je vous fait un petit retour d’XP :slight_smile:

J’ai juste envie de dire une chose, c’est la meilleur évolution que j’ai pu faire sur mon installation depuis le début !

Pour moi la conclusion est des plus simple, j’ai gagné en :

  • Stabilité
  • Rapidité
  • Fonctionnalité

J’en suis arrivé à ce que j’ai également basculer la totalité de mes protocoles en MQTT :

Pour avoir ceci :

Alors j’ai eu quelques déboire au début que j’ai fini par résoudre assez rapidement, et à priori la ré-inclusion des modules en openzwave 1.6 et parfois nécessaire sur certains modules.

J’ai juste envie de vous dire go zwave2mqtt pour les gens qui ont des soucis :slight_smile:

4 « J'aime »

Bonjour @m4dm4rtig4n,

Merci pour ton retour. Ta screenshot montre un réseau non sécurisé; En quoi est-ce mieux ou plus stable que de faire du non sécurisé directement sous Jeedom ? D’après les retours, les problèmes rencontrés sont vus en mode sécurisé uniquement.

Bonne journée

Perso j’avais des soucis également en mode non sécurisé avec le plugin.