Salut @StephaneB ,
A tout hasard, as-tu vérifié tes backups Gladys Plus ? Si tu n’as rien d’autre dessus, et que tu as 45% d’espace disque d’occupé, Gladys a besoin de la meme quantité au moins pour realiser le backup.
Je sais que tu dis que ca ne se produit pas forcement au meme moment mais sait on jamais ^^
Combien fait ta DB ?
Salut @StephaneB 
Effectivement c’est fâcheux si Gladys se bloque, on va trouver
Effectivement, pour cela il faut 2 clé d’API. Je ne sais pas si il est possible de créer 2 clés d’API pour un même bot, mais en tout cas tu ne peux pas avoir 2 connexions en même temps, c’est une limitation côté API Telegram.
Visiblement c’est une scène avec un « continuer seulement si » avec un calcul, ça te dit quelque chose ?
Cela provient d’une scène avec un « Contrôler un appareil » avec une valeur calculée, ça te parle ?
Autre question, est-ce que ce blocage intervient à partir d’une heure pile ? Toutes les heures, Gladys calcule les valeurs agrégées de capteurs, ça pourrait être ça qui sature ta bande passante disque et qui empêche le reste de Gladys de tourner
PS: Dès que tu trouves les scènes coupables, si c’est bien ça qui provoque le blocage, je veux bien que tu documentes ici ce que tu as trouvé dans ces scènes pour qu’on puisse corriger dans Gladys ce qui provoque ces blocages
Merci pour la piste, @Terdious. Mais pas de soucis de mes sauvegardes, elles se font correctement. Et la taille de la sauvegarde est d’environ 5Go.
Merci @pierre-gilles pour ces pistes. Je vais m’occuper de corriger ma config avec Telegram.
Et pour les scènes, ce qui est compliqué c’est que j’ai des tas de scènes qui correspondent aux critères que tu as donné. Est-ce qu’il y a une trace de chaque déclenchement de scène avec le nom de la scène, et je recouperai avec l’heure de l’erreur ?
Mais sinon je vais les ouvrir une à une est déjà vérifier lesquelles se lancent toutes les 5 minutes, et parmi elles celles qui correspondent à tes critères.
Et je ne sais pas trop si les blocages interviennent à heure pile, car je les détecte à un moment où j’ai besoin de gladys et que ça ne répond pas, et ce sont des moments assez aléatoires…
Non actuellement ça n’existe pas !
Si jamais tu veux qu’on s’appelle un soir ou ce weekend pour débugger ça ensemble, je suis toujours disponible pour aider
Merci @pierre-gilles pour ta proposition d’aide. Mais c’est de mon côté que je manque de temps pour me poser et t’appeler. J’essaie dès que possible…
@pierre-gilles, J’ai eu 3 plantages ces derniers jours :
Dans les logs docker, j’ai toujours les deux mêmes erreurs déjà décrites plus haut… Donc j’ai commencé à relire une a une mes scènes pour retrouver celles qui se déclenchent toutes les 5 minutes et contiennent les actions que tu m’as citées… Je vais finir par trouver 
Mais j’ai repéré un autre truc dans la page ‹ tâches en arrière plan › dans Gladys : l’erreur suivante est affichée chaque heure avec l’agrégation mensuelle :
Error:
<--- Last few GCs --->
rt of marking 1752 ms) (average mu = 0.672, current mu = 0.238[110976:0x7fb3c20040] 1698423 ms: Mark-sweep (reduce) 919.1 (936.1) -> 919.1 (936.1) MB, 1709.2 / 0.0 ms (+ 10.0 ms in 3 steps since start of marking, biggest step 3.5 ms, walltime since start of marking 1728 ms) (average mu = 0.532, current mu = 0.214)[110976:0x7fb3c20040] 1700597 ms: Mark-sweep (reduce) 938.5 (955.5) -> 938.3 (955.5) MB, 2126.9 / 0.0 ms (average mu = 0.339, current mu = 0.022) allocation failure; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
Et cette erreur est aussi logiquement dans les logs docker…
Sais-tu ce que je dois faire pour éliminer cette erreur d’agrégation ?
L’agrégation se prend les pieds dans le tapis pour une histoire d’usage RAM, la « Heap memory » de Node.js est pleine, plusieurs causes possibles :
De manière générale, plus tu n’as pas eu d’agrégation depuis longtemps, et plus c’est compliqué car il y a de plus en plus d’états à « traiter » et donc ça devient de plus en plus compliqué ^^
Lissage RAM oscille entre 5% et 30%, selon ce schéma :
Et le pic à 55% correspond au dernier plantage
Et je dirais que c’est un 64 bits, mais je ne sais plus comment vérifier
Attention, on te parle de RAM, mémoire vive, pas de la charge sur le CPU…
Oups… Effectivement, je n’ai pas été assez attentif pour répondre.
En terme de RAM, j’ai ça que me donne l’appli piHelper sur mon smartphone :
Avec les commandes uname -m où arch tu obtiendra ta version
Merci. Et donc c’est ‹ aarch64 ›
ça nous aide pas trop, c’est un chiffre relatif à un instant t, j’aimerais bien savoir comment de RAM tu as de dispo et combien est occupé en général
Sur ton Pi, en ligne de commande tu peux faire :
docker stats
Ou :
htop
Fais nous des captures d’écrans des deux commandes
docker stats me renvoie des infos qui varient, bien sûr, entre des instants calmes ou plus intenses (ça ressemble à un cycle sur 10 secondes environ) :
et htop :
Je comprend mieux, avec 1.8Gb de RAM sur ton Pi, si 600Mo sont toujours pris en fonctionnement normal, et si dans l’état actuel tu as besoin de plus de 1Go pour l’agrégation (tu as du prendre du retard), ça coince.
L’agrégation fonctionne capteur par capteur, tu as sûrement un seul capteur qui est responsable de l’usage important de RAM que l’on voit. Une analyse de la base SQLite pourrait permettre de déterminer de quel capteur on parle. Ça se trouve, ce capteur tu ne te sers même pas de ses données et tu pourrais les supprimer ^^ (imagine c’est genre l’historique de batterie sur les 2 dernières années, bon on peut s’en passer). Si tu sais extraire ta base de donnée, je pourrais faire les requêtes et te dire quel capteur pose problème. Sinon tu peux faire les requêtes toi même si tu sais le faire aussi
Si ça te semble compliqué, tu peux déjà faire une passe sur chaque appareil dans l’intégration Gladys-Zigbee2mqtt et vérifier que tu ne garde bien que les états dont tu as besoin. Si tu décoche une fonctionnalité, automatiquement Gladys purgera les états historiques
Ok, merci de l’analyse. Et ça me force à faire ce que je repousse depuis un moment : passer en revue la config de chaque appareil Zigbee et chaque appareil MQTT pour supprimer un maximum d’historique. Je vais d’abord faire ça tranquillement.
Et puis aussi étudier le passage au mini-pc dont tu vantes régulièrement les mérites
