Quand je parle de surveiller, ce n’est pas par l’utilisateur que je pense.
Il faut que ce soit le plugin-swassist qui le fasse avant de voir si il peut relancer la commande action.
C’est la version actuelle, je n’ai pas encore déployé la version plus bavarde
1 « J'aime »
Par défaut, swassist effectue maximum 5 répétitions avec un temps d’attente de 3 secondes entre chaque répétition (peut être modifié par l’utilisateur). Je ne pense pas que ce soit ça qui puisse saturer zwave.
Je suis plutôt d’accord avec ce propos.
D’après ma modeste mais acharnée expérience, le plus souvent quand un ordre ne passait pas c’est que la queue zwave était ou allait partir en vrille sans ne plus jamais revenir à 0 => restart du daemon ou reboot du serveur obligatoire.
@Nemeraud bref c’est pas simple et si tu rencontres souvent ce problème je te conseille du coup de réfléchir au passage sur zwavejs2mqtt mais assure toi déjà d’avoir des modules uniquement inclu en non sécurisé.
Je n’ai pas dis ça, seulement qu’il ne faut pas en rajouter quand la queue n’est pas vide.
Imagine certains utilisateurs s’en servir pour ouvrir ou fermer en même temps une dizaine de volets.
Version un peu plus bavarde en debug déployée…
[2021-11-04 21:08:45][DEBUG] : Traitement d'une commande '[bureau][swassist][ON]'...
[2021-11-04 21:08:45][DEBUG] : Réception d'une info [bureau][swassist][Puissance]
[2021-11-04 21:08:45][DEBUG] : Lancement de '/var/www/html/plugins/swassist/core/class/../php/repeatCmd.php -i 1159'
[2021-11-04 21:08:45][DEBUG] : [repeatCmd] [1974] Lancement de /var/www/html/plugins/swassist/core/php/repeatCmd.php
[2021-11-04 21:08:45][DEBUG] : [repeatCmd] [1974] Commande ID : 1159
[2021-11-04 21:08:45][DEBUG] : [repeatCmd] [1974] Délai entre répétitions: 3
[2021-11-04 21:08:45][DEBUG] : [repeatCmd] [1974] Nombre max de répétitions: 5
[2021-11-04 21:08:45][DEBUG] : [repeatCmd] [1974] Valeur cible: 1
[2021-11-04 21:08:48][INFO] : [repeatCmd] [1974] Relance de la commande [bureau][swassist][ON]
[2021-11-04 21:08:51][DEBUG] : Réception d'une info [bureau][swassist][Etat]
[2021-11-04 21:08:51][INFO] : [repeatCmd] [1974] Commande exécutée après 2 tentatives
Le concept même de renvoyer des commandes en boucle quand il y a un problème est une mauvaise idée, peu de système (pour ne pas dire aucun) ne résiste à ça et cela n’est pas propre à openzwave.
C’est le concept même d’un DoS: bombarder de requêtes qui vont provoquer une instabilité ou simplement surcharger jusqu’à tuer l’application.
Bonjour @Mips
Avec 5 tentatives, voir moins i on veut, c’est peut être un peu exagéré de parler de bombardement et encore plus de DOS 
Il fait bien trouver des solutions pour compenser quelques choses qui marche mal !
J’ai un réseau zwave correctement maillé, pas de surcharge du réseau en tant Normal, et parfois une commande ne passe pas à la première tentative
Ce plugin corrige cette rare défaillance et permet de la mettre en exergue.
On arrête pas de demander une évolution du plugin zwave pour avoir un usage de ce protocole plus fiable mais ça ne semble pas bouger côtés Jeedom, certaines personnes vont jusqu’à abandonner ce protocole.
Je dois avoir plus de 2000€ de modules zwave je ne peux pas me permettre de les mettre à la poubelle.
1 « J'aime »
Je pense que tu n’as pas suivi tout les postes. Ça bouge côté jeedom.
A bon ? Ça discute depuis un sacré moment oui mais je vois pas grand chose arriver…
Et ce que je vois, travail sur le plugin zigbee, promo sur l’Atlas uniquement en zigbee,…
C’est même a ce demander si on nous pousserait pas à abandonner le zwave au profit de zigbee
Maintenant si tu as des news, je suis preneur
1 « J'aime »
Je te rappelle qu’entre une 4.1 à maintenir, un 4.2 qui se prépare et d’autres projets, l’équipe est bien occupée.
Donc oui le nouveau plugin zwave prend du temps, comme l’app mobile et pourtant…
Pourtant y a un plugin docker qui pointe le bout de son nez justement pour permettre une évolution et faire tourner de manière plus sur le nouveau plugin zwave.
Attendons de voir, après la gestion des priorités… faire fonctionner correctement un protocole basé sur des couches obsolètes depuis quelques années ou faire évoluer une application mobiles…
mais en attendant il faut bien faire fonctionner notre domotique d’où ce plugin.
Regarde le poste sur le plugin docker ^^
Ah je ne dis pas le contraire. Mais perso je préfère trouver la cause que mettre une rustine.
Je n’ai aucun loupé en zwave… donc bon
Mais je trouve que tu as beaucoup de souci avec ta domotique.
Beaucoup de soucis je dirais pas ça mais elle n’est pas 100% fiable c’est claire, mais d’après Loïc je lui en demande trop 
Je vais regarder mais sur le principe ça me dérangeait que cela passe par cette plateforme, une surcouche supplémentaire au système
Je ne connais pas la taille de ta domotique nombre d’équipements, scénarios etc.
plugins utilisés mais je vois beaucoup de post passer ou tu as des soucis
Ah bon avoir un plugin qui tourne dans un container et qui du coup évite les soucis de dépendances, de paquets linux etc. donc fiabilise l’ensemble de la solution ça te dérange ?!
Franchement a ta place, je reverrai ma domotique pour la fiabiliser avant de continuer
Et limiter les plugins, optimiser mes scénarios, virtuel etc.
C’est pas le concept qui me dérange mais de devoir mettre docker en plus de Jeedom qui devrait se suffire à lui même
Merci pour tes conseils, j’ai déjà pas mal avancé sur l’optimisation des virtuels, j’ai également viré mon design mono page qui affichait plusieurs sous design, c’était efficace en terme de rapidité mais ça devait un peu changer la Smart, en tous les cas depuis plus de compteur de mémoire insuffisante, la santé est un beau fixe
Les plugins sont à la fois la force et le talon d’achille de Jeedom.
On le voit aujourd’hui avec les soucis de paquets à installer sur linux pour certains.
Donc que Jeedom SAS pour fiabiliser cela se tourne vers docker je trouve que c’est une avancée justement.