Personnellement, j’ai juste tout passé en non sécurisé & je n’ai plus aucun pb de radiateur depuis.
En sécurisé, j’avais exactement les mêmes problèmes que toi.
Pour info j’ai récupéré de la stabilité sur mon installation…
Ce que j’ai changé n’a plutôt rien a voir… j’ai rajouter du swap sur un SSD externe.
Je m’explique: je me suis rendu compte que j’avais de nombreuses lenteurs sur le RPI 4. En analysant un peu j’ai pu observé un load average qui montait régulièrement au dessus de 4.
Pour tester, j’ai donc mis un fichier de swap sur un SSD externe et la depuis plus de soucis… jusqu’à ce matin… Je viens de me rendre compte dans les logs que j’ai des messages de ce type:
97197.258612] INFO: task Xorg:578 blocked for more than 120 seconds.
[97197.258619] Tainted: G C 4.19.97-v7l+ #1294
[97197.258623] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[97197.258628] Xorg D 0 578 550 0x00000001
[97197.258651] [<c09c8f5c>] (__schedule) from [<c09c95cc>] (schedule+0x50/0xa8)
[97197.258660] [<c09c95cc>] (schedule) from [<c09cd5b4>] (schedule_timeout+0x200/0x428)
[97197.258667] [<c09cd5b4>] (schedule_timeout) from [<c09ca23c>] (wait_for_common+0xd4/0x1b0)
[97197.258674] [<c09ca23c>] (wait_for_common) from [<c09ca338>] (wait_for_completion+0x20/0x24)
[97197.258683] [<c09ca338>] (wait_for_completion) from [<c0840b14>] (
Je pense que le fait de rajouter du swap n’a été qu’un facteur améliorant mais pas de résolution du problème de fond… Je vais maintenant essayer avec un démarrage en mode CLI au lieu de graphique du RPI (étant doné que les soucis semblent venir de Xorg…).
@Emlivyo, tu es sur quelle plateforme? si RPI, quel est le load average?? Je suspecte qu’une charge trop important empêche la bonne communication avec les modules…
Personnellement je déconseille plus que fortement d’installer Debian avec l’interface graphique. …surtout sur un pi !
cf la doc:
1/ Télécharger le dernière image “lite”, c’est à dire sans interface graphique
https://jeedom.github.io/documentation/installation/fr_FR/index#tocAnchor-1-8Installez la debian de préférence sans interface graphique car inutile.
https://jeedom.github.io/documentation/installation/fr_FR/index#tocAnchor-1-14-5
Oui oui … c’est sur… je voulais juste avoir un teamviewer qui était indépendant du reste de mon infrastructure (plusieurs serveurs ESXi etc …)
Je suis sur RPI3 avec interface graphique aussi (c’était au début pour debugger et j’ai laissé mais je n’ai pas d’écran connecté dessus)
Encore une fois, tout a plutôt bien fonctionné pendant 3 mois (j’avais qq erreurs de swap qui tombait à 0 et donc plantait mais maintenant je surveille et ça tourne bien) et là j’ai quelques soucis depuis quelques jours.
Load average je n’ai pas trop regardé mais je ne dépasse pas 1… et au final j’ai que 3 modules et ils font simplement du ON/OFF sur mes 2 radiateurs et ma prise extérieure en fonction du plugin agenda (et en plus ils ne le font même pas en même temps 
)
J’ai relancé les dépendances et du coup je surveille un peu…
Edit: Je suis en non sécurisé aussi
Ce soir, je me rends compte que mon éclairage exterieur ne s’est pas eteint comme prévu par l’agenda à 21h30.
Est-ce possible d’envoyer 2 voire 3 fois (ou plus ?) la commande pour augmenter sa probabilité de réalisation ?
Salvialf, c’est gentil de t’investir pour la communauté Jeedom, et je trouve réellement appréciable que des gens s’engagent pour aider les autres.
Ceci étant dit nier les problèmes ne les résout pas. On est nombreux à avoir eu récemment des soucis avec le plugin zwave (depuis l’été dernier des cas similaires sont signalés). Les sujets ont été multipliés et contiennent tous à peu près la même description. A mon avis dans ce cas précis, les topics mériteraient d’être regroupés, ça permettrait aux devs d’accéder plus facilement aux infos.
Je te mets quelques exemples :
Pour info, je n’ai fait qu’une rapide sélection en cinq minutes sur le nouveau forum. Il y en a au moins autant sur l’ancien, et j’aurais pu je pense en rajouter en remontant jusqu’à l’été dernier.
La description varie un peu parfois, et c’est ça qui est intéressant pour les développeurs. Les symptômes sont presque tout le temps les mêmes. Perte de voisin, perte de connectivité avec le zwave au bout de quelques heures / jours.
Pour info, je fais des tests depuis trois semaines avec différentes versions du plugin pour essayer de comprendre à quel moment la régression a été introduite. Malheureusement, je n’arrive plus à voir le souci depuis que j’ai commencé à faire ça. Même sur la dernière version je n’ai plus de souci.
1 « J'aime »
Hello,
Tu as cité mon post.
J’ai un environnement particulier et pas officiellement supporté : Jeedom dans un conteneur Docker sous Synonology.
Mon problème était présent uniquement en mettant une clef 4G avec le contrôleur Z-Wave.
Je vais d’ailleurs répondre dans mon post car depuis mon dernier changement ça a l’air OK.
Salut,
Je parcours énormément le forum, j’ai déjà lu tous ces posts.
…Justement à lire ces posts j’en étais arrivé à ne plus vouloir mettre à jour le plugin openzwave de peur que mon installation devienne instable. J’ai finalement mis à jour récemment et mon réseau zwave ne s’en porte que mieux.
Le truc comme j’essayais d’expliquer dans mes posts précédents c’est que l’on entend que ceux chez qui ça ne fonctionne pas impeccablement alors que ça fonctionne parfaitement chez une écrasante majorité d’utilisateurs.
Et à chaque fois les posts mettent en cause le plugin alors que vraisemblablement il s’agit de leur installation qui présente un défaut (matériel, logiciel ou lié à l’environnement physique).
D’où l’importance de bien décrire mon environnement 
Pour ma part, je suis conscient que mon environnement est l’élément clef.
Les logs peuvent se ressembler mais derrière, cela peut être un tas de problèmes différents.
1 « J'aime »
J’ajoute ce post :
Bonjour @anto35 ,
Pour compléter et clarifier (je pense) le point de @Salvialf, les problèmes ne sont pas nier ici.
Beaucoup de personne ont un problème, c’est clair.
Mais, et c’est une information intéressante pour investiguer celui-ci, il y a plus de 18.000 installations zwave.
On ne va pas faire les comptes en détails mais çà parait clair que même si on trouve 100 topics de personnes différentes ayant un problème avec zwave et qu’on ajoute tous ceux qui ne sont pas ici mais qui ont aussi un problème, cela restera un pourcentage très faible de ceux chez qui cela fonctionne.
Donc un bug structurel dans le plugin n’est pas la plus probable des pistes, donc il faut mieux chercher ailleurs l’origine du problème pour avoir plus de chance de le trouver
Et ce dernier commentaire ne fait que confirmer ce que je viens d’écrire: tu aurais pu gagner 3 semaines en n’investiguant pas la piste du « bug dans une des dernières versions du plugins » car fortement improbable
Merci de vos réponses.
J’ai investigué cette partie car c’etait la plus imple dans un premier temps. J’arrive effectivement à la conclusion que le problème est très probablement ailleurs.
Concernant le fait que l’immense majorité des installs zwave fonctionnent correctement, je ne l’ai jamais nié. Mais pourquoi fonctionnent t’elles correctement alors que d’autres déraillent ? Des modules qui mettent le réseau à genou. Un package debian qui fait dérailler le contrôleur USB ? Un autre plugin Jeedom qui fout la grouille ? Une mise à jour du core qui change le séquencement des messages zwave envoyés depuis les scénarios ?
Honnêtement ce problème pour moi sent l’effet de bord à plein nez. Le réseau est fonctionnel et tout d’un coup plus rien, sans montée en charge, sans fuite mémoire sans aucun élément particulier.
Dans mon cas mon setup est tout à fait standard. Une install sur un Z83 avec un ZStick aeon et Debian 10 headless.
Je suis en train de me diriger effectivement vers la piste du pb hard, même si le Z83 ne semble pas montrer de signe de faiblesse apparent.
Oui c’est très certainement un problème lié au protocole, on voit tout un tas d’informations dans la page protocole / z-wave / santé, ce qui démontre que le protocole n’est pas assez fiable et que le logiciel (driver / couche open-zwave / jeedom …) tente de suppléer ces erreurs tant bien que mal. Et j’essaye d’en rajouter une couche avec des scénarios. C’est du sans-fil, et chaque élément est autonome pour capter / router un message, 2 bonnes raisons pour que les messages soient éparpillé ou perdu.
D’ailleurs quand je vois la typologie des erreurs, la différence est un peu floue, mais ce qui est sûr c’est qu’il y a des erreurs:
| Nombre de messages non-sollicités alors qu’en attente d’ACK : | 13 |
|---|---|
| Nombre de bits jamais arrivés : | 0 |
| Nombre de mauvais checksums : | 0 |
| Nombre de retours inattendus : | 55 |
| Nombre de ACK retournés en erreur : | 0 |
| Nombre de lectures en échec dues au timeout : | 0 |
| Nombre de messages d’échec dus au réseau occupé : | 0 |
| Nombre de messages non remis au réseau : | 4 |
| Nombre de messages jetés ou non délivrés : | 5502 |
| Nombre de messages en échec à cause d’un mauvais routage : | 0 |
| Nombre de messages reçus avec statut de routage occupé : | 0 |
et s’il y a des erreurs détectées par notre contrôleur et jeedom, à l’inverse il y a sûrement des erreurs des modules qui ne sont pas détectées.
Là pour le coup je ne suis pas d’accord, les faiblesses sont plutôt dans la partie driver / soft que dans la partie protocolaire. Pour m’être beaucoup renseigné avant de partir sur du zwave, c’est clairement le protocole radio le plus fiable, loin devant les autres (hors zigbee). Les paquets perdus et les perturbations c’est normal et le zwave est très bien doté de ce côté là, ils ont parfaitement adressé dans le protocole ce genre de souci avec du CRC, du multipath et du rejeu sur erreur.
Je suis moins convaincu par l’implémentation openzwave qui est issue de reverse engineering au départ. Maintenant le sdk a été libéré par silabs et je pense qu’on pourrait avoir quelque chose de bien meilleure qualité en repartant du fameux sdk. J’en veux pour preuve fibaro qui est réputé pour avoir le meilleur moteur zwave du marché (dommage que le reste suive pas).
je n’ai pas dit qu’il est moins fiable qu’un autre (du reste je ne connais pas les autres protocoles), juste que ces erreurs existent. Quoique je n’ai pas pu les retrouver dans les logs, et je ne sais pas comment c’est géré: c’est le protocole qui prend en charge ces protections et donc ça serait transparent pour nous? ou bien au contraire ça serait à nous de gérer en cas d’erreur quelle action lancer, via des scénarios jeedom du coup (je m’oriente vers cette méthode maintenant)
Et voilà ça continue… on a beau expliquer que le problème vient en général de l’installation on a quand même droit à tout un laïus sur le manque de fiabilité du protocole!
La gestion des erreurs ne démontre pas que le protocole n’est pas fiable, Ça démontre juste que ton install n’est pas clean!
oui exactement, et du reste c’est sans doute le plus fiable, comme dit @anto35 moi mes 5000 erreurs ça représente environs 5% des commandes, je suppose que c’est acceptable (qui a 0% d’erreur, si ça existe?)
Quand c’est une remontée d’info qui n’aboutit pas, on s’en aperçoit pas. Mais quand c’est un chauffage qui ne démarre pas, ou une lampe, c’est moins confortable donc on s’en inquiète. Moi ça m’est arrivé 1 fois cet hivers sur le chauffage c’est pour ça que je me renseigne.
Hello a tous,
Petit retour sur mon post originel… Je pense avoir trouvé la solution et vous allez rire… c’était vraisemblablement lié a une surcharge CPU sur mon RPI4… venant d’un plugin de gestion de volets…
Après avoir chercher dans tous les sens, il semblerait que la queue zwave est très très très sensible a la latence d’exécution des commandes dans la couche driver/plugin…
Je m’explique… depuis quelque temps j’avais des erreurs de configurations dans le plugin Gestion de Volets de Mika-nt28, voulant savoir d’ou ca venait, j’ai un petit peu regarder le système et les process en cours car je me suis retrouvé avec des load average de 20 !!!
Avec htop, j’ai réussi a trouver les commandes posant problème, et cela provenait des Listener (monitoring des changements d’état des objets - lampes / tv… ). après avoir désactivé les actions conditionnelles, pas de changement.
J’ai alors désactivé le plugin et la miracle le load average est passé a 0.3… cf pièce jointe…
Le simple fait de réactiver le plugin, tout en laissant les object désactivés continuait à poser des problèmes… et il faut redémarrer le RPI pour ne plus avoir d’utilisation CPU démesurée.
Donc pour finaliser j’ai migré sur le plugin officiel de gestion de volet tadaaaa plus aucun soucis depuis plusieurs jours.
My 2 cents
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.