Je reviens sur une anomalie qui paralyse mon système domotique. J’ai beaucoup de mal à cerner la cause mais j’avance avec les indices suivants.
Les défauts :
certains scénarios deviennent très lents ou "sautent " des étapes, de façon aléatoire.
certains devices sous zigbee ne réagissent plus même à une commande manuelle via jeedom alors qu’ils restent joignables d’après l’info « dernière communication ».
Pour que les "choses rentrent dans l’ordre, soit je reboote le Pi , soit je relance les dépences du plugin zigbee Z2M et la domotique refonctionne normalement, pendant quelques heures.
J’ai constaté que la charge du CPU peut monter entre 2.5 et 3.2 sans que je ne sollicite la domotique, puis redescend à moins de 1.0 Avec un PI4 cela me semble très (trop)élevé.
En suivant les log en temps réels , je m’aperçois que mes prises NOOS sous zigbee semblent surcommuniquer.
J’en déduis que cela peut saturer le PI.
VOici les logs :
Pour rendre la prise NOUS moins bavarde, tu peux jouer sur les paramètres de rapport.
soit directement dans jeedom : dans ton équipement, tu choisis ‹ configuration du module ›, puis onglet ‹ Reporting ›
soit depuis l’interface Zigbee2MQTT, onglet ‹ Rapport ›
Pour les paramètres currentSummDelivered, rmsVoltage, activePower, rmsCurrent, tu peux régler :
. Min report time : le temps minimum en secondes pour avoir une info de ce paramètre. Si 60, tu n’auras pas de remontée d’info plus fréquentes que 60s.
. Max report time : idem, dans l’autre sens. Si 900, tu auras au moins une info toutes les 15mn, même si le paramètre n’a pas changé de valeur.
. Report change : le delta de valeur du paramètre pour déclencher une remontée d’info ; en tenant compte des réglages précédents.
Tu as la même chose pour les autres équipements zigbee gérés par z2m
Tu peux en plus aussi jouer, depuis l’interface Zigbee2MQTT onglet ‹ Paramètres ›, sur l’option ‹ debounce ›
doc dans Devices and Groups | Zigbee2MQTT
Je n’ai jamais utilisé ; à utiliser avec prudence : voir la doc précédente.
Je crois que la première option (Reporting) demande à l’équipement de n’être pas trop bavard, en zigbee. Ca réduit le trafic de manière globale.
L’option ‹ debounce › ne réduit pas le trafic zigbee ; il réduit le nombre de messages mqtt.
N’arrivant pas à réduire la communication de la prise NOOS (située dans la véranda) je l’ai débranchée physiquement.
La communication de ce fait a disparu, mais c’est une autre prise qui prend le relai maintenant :
En effet, si j’essaie de changer une valeur depuis jeedom, ca génère l’erreur suivante : Z2M à renvoyé une erreur : z2m: Request 'zigbee2mqtt/bridge/request/device/configure_reporting' failed with error: 'Invalid payload'
Je pense que c’est un bug coté plugin jeezigbee ; ca fonctionnait … avant (il y a longtemps que je n’ai pas fait).
Tu peux aussi le faire depuis l’interface web de Zigbee2MQTT (z2m)
Pour y aller :
menu configurations du plugin. Copier la valeur de l’identifiant, puis, en face de ‹ Accès à la page web z2m ›, cliquer sur le bouton ICI ; ca ouvre l’interface web de z2m.
S’il y a une demande d’authentification, il faut coller la valeur de l’identifiant qu’on a copié auparavant.
La page d’accueil liste les périphériques zigbee gérés ; choisir celui à modifier, et cliquer.
Ca ouvre une page dédiée à ce périphérique. Il faut cliquer sur l’onglet ‹ Rapports ›.
Depuis cette page, tu peux changer les valeurs paramètre par paramètre, et cliquer sur l’action ‹ Appliquer ›
Tu peux ensuite vérifier dans jeedom que le paramètre a bien été modifié.
Tu as cliqué sur le menu ‹ Rapports › de l’écran d’accueil ; tu vois le rapport de tous tes devices.
Dans la copie d’écran que tu envoies, on voit bien des devices différents …
Je t’avais proposé :
depuis le menu d’accueil, tu cliques sur le device désiré ; ou alors, tu choisis le menu ‹ Appareils ›, puis tu choisis ton device.
tu arrive maintenant sur la page principale de ton device. Dons les onglets du haut, tu cliques sur l’onglet ‹ Rapports › ; à ce moment, tu ne vois que les paramètres modifiables du device choisi.
Tu es certain ?
quand le le fais, par exemple sur la première ligne (chez toi, rmsVoltage) :
Je change la valeur (chez toi, 5) en 60, par exemple ; puis je clique que la coche action que tu as entourée, correspondant à la même ligne.
Alors, cette ligne semble disparaitre ; en fait, elle passe en dernière ligne ; et chez moi, à la bonne valeur.
C’est un peu déroutant. On peut croire qu’on n’a pas modifié la valeur, car le paramètre affiché à la place n’est plus le même.
Ensuite, si je vérifie dans jeedom, je vois que la valeur a bien changée.
2 - J’ai refait la procédure de changement de valeur pour voltage : la ligne de disparait pas , la valeur n’est pas prise en compte une fois que j’ai validé. En mettant à) jour, la valeur revient sur 5 , et sous jeedom j’ai toujours 5 .
Par contre si je modifie le nom d’un device en passant par Z2m, le nom est bien mémorisé. Donc mon interface est active.
Si je n’arrive à rien, j’envisage de transférer toute ma domotique sous Pi5 debian 12 car actuellement, alors que tout allait bien il y a quelques temps, je ne peux plus compter sur la fiabilité du système avec le protocle Zigbee. Autant mes devices Zwave restent opérationnels, autant ceux sous Zigbee, disparaissent, se bloquent, un vrai bonheur
J’avais exactement les mêmes paramètres que toi. Maintenant j’ai réussi à rallonger le délai de 5 à 60 sec.
Je n’ai pas su lire la version du firmware de ces prises. Pas trouvé l’endroit !
Même si j’ai réussi à réduire la communication, je ne comprends pas pourquoi mon PI4 se mets en surcharge à certains moments. Je pense que le retard de réponse est en rapport, voire le fait que certaines opérations sont « sautées », mais à cet instant je n’ai ni trouvè la cause , en encore moins le remède.
Dans le cas où je tente d’installer ma sauvegarde Jeedom sur un PI5 sous debian 12 (que j’ai de disponible), en plus de la sauvegarde Jeedom, que dois-je sauvegarder ? Z2M ? SI oui, je n’ai pas trouvé d’onglet suavegarde.
Je suppose que tu va utiliser la même clé zigbee.
Je pense que la sauvegarde jeedom suffit ; il faudra relancer les dépendances après restauration.
Il faudra vérifier que le port du controleur a toujours le même nom, sinon il faudra ajuster.
Les vielles viennent d’Amazon car Domadoo était en rupture pour 1 ou 2 mois.
Ces vielles versions m’ont fait le gag de beaucoup communiquer lors de leur inclusions : A se demander pourquoi une bonne partie de mon réseau voulait passer par elles.
Et puis cela s’est calmé, sans que je ne fasse rien.
