Soucis sur mon réseau z-wave

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.

Bonjour,

Concernant les inclusions sécurisées, j’ai eu des soucis aussi avec un module qui fonctionnait en non sécurisé (même de pas de cadenas) mais qui avait été inclus il y a longtemps en sécurisé. Assez régulièrement, j’avais des erreurs de type retours inattendus ou ACK retournés en erreur au réveil du module. Bien entendu, une ré inclusion en mode normal a résolu ces problèmes. :wink:

Sinon, tout va bien, mais de temps en temps, il y a des ratés avec les capteurs de mouvement Fibaro Motion Sensor comme ici SensorBinary report non reçu avec Fibaro Motion Sensor

Bonjour,

ne faut-il pas ajouter la « Network Key » pour reconnaître les modules inclus en sécurisé ?
Network Key = 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10
C’est la même pour toutes les install OpenZwave…ça craint du boudin…

Source : Modifier la clé de sécurité Z-Wave - La domotique de Nechry

Seulement si tu as personnalisé ta clé

Ouais, par défaut, tout le monde a la même. Et tu l’apprends lorsque tu as déjà fait toutes tes inclusions.
Donc, il faut d’abord la changer à la main comme expliqué dans ton lien, puis refaire en sécurisé toutes inclusion en faisant gaffe que ta nouvelle clé ne soit pas écrasée dans le temps par celle par défaut. Puis, tu te rends compte que le mode sécurisé ne fonctionne pas aussi bien que tu le pensais. Enfin, quand tu en as marre des problèmes en sécurisé, tu refais tout en mode non sécurisé. :smiley:

Oui je comprends… ! :rofl:
Perso je suis en docker donc les fichiers de conf sont bien sauvegardé à l’abri sur mon QNAP sur un share, du coup pour le update il y aura moins de contrainte.
J’en suis qu’à mes débuts, je regarde comment ça fonctionne pour le moment…
J’espère juste gagné en rapidité d’exécution des actions avec MQTT…

Salut !
Bon j’ai ma réponse !
J’ai fait des tests avec zigbee2mqtt et les actions effectuées par scénario sont quasi zéro latence !
Et le changement d’état successif est très bien géré et les actions suivent !
Je me tatais à essayer Home Assistant car apparemment il y avait des temps de traitement très court…
Bah pas besoin, le couple Zwave2mqtt/jMQTT/Jeedom fonctionne parfaitement !
Quand je suis revenu sur le plugin Zwave des fois c’était rapide des fois non et le changement successif d’état qui ratait des actions.
Je précise quand même que j’ai un très bon réseau Zwave avec un Razberry connecté en USB avec interface USB-TTL et une antenne externe via un connecteur uFL soudé sur le PCB.

Bonjour, j’apporte ma pierre à l’edifice car je rencontre de même pb zwave.
J’ai un réseau de 40 noeuds principalement sur secteur réparti sur 3 niveaux (sous-sol, rdc, étage). Mes ordres zwave étaient exécutés 1 fois sur deux donc impossible de savoir si la commande était réellement exécutée.
Du coup, et après avoir lu vos posts, j’ai refait mon architecture en mettant 1 contrôleur primaire (Raspberry pi4 ou pi3 + ssd16Go + zwave) par niveau et en utilisant jeedom Link. Maintenant ça marche nettement mieux pas de dropping command à l’horizon mais mon budget a explosé :frowning:
Bravo à Stanymaman qui a basculé en MQTT, sacré boulot ! J’ai hésité à le faire d’autant plus que je commence à avoir des capteurs Shelly mais ma principale crainte ç’est la saturation du wifi déjà fortement sollicité. A bientôt Manu

Salut,
Je suis entrain de faire la même opération. Pourrais tu me montrer la config jmqtt pour les volets ? c’est des modules Fibaros ?
Merci d’avance.

Oui ce sont des FGR-223.

Par contre j’ai quitté Jeedom il y a plusieurs mois maintenant, et je ne pourrais donc pas te montrer de screen de ma config :confused:
Après pose tjr tes questions, je vais peut être pouvoir y repondre :slight_smile:

Ah OK. Tu es parti sur HA ?
ca va je m’en suis sorti merci :wink:

Oui depuis quelques mois maintenant :wink:
Si tu veut une visu de ma dashboard HA : [Mon Dashboard ] - @Madmartigan - Présentations - Home Assistant Communauté Francophone

C’est vraiment beau ! Félicitations !
Combien de temps as-tu passé @m4dm4rtig4n pour construire seulement ton interface sous Home Assistant ?

Bcp de temps…

Sur HA, t’est bcp moins assister que sur Jeedom et si tu veut un truc qui correspond à tes envies ça peut être très long à mettre en place :confused:

Après depuis la version 0.116 (la latest est en 0.117), ils mettent de plus en plus en avant l’IHM et tu peut commencer à quasiment tt faire via l’IHM.

Après j’ai cru comprendre la que la v4.1 de Jeedom apportent pas mal de truc sympa, mais revenir sur Jeedom après avoir goutté à la liberté de HA, je pense que c’est impossible :stuck_out_tongue: