Ce qui m’inquiete c’est la baisse continue 
Pour ma part et en allant vite, j’ai lancé la commande free en background avec sortie dans un fichier, soit :
free -m -s 600 >> trace.txt&
-m : en megabytes
-s : récurence en secondes, -s 600 => toutes les 10 minutes.
redirection de la sortie standard (l’écran) dans un fichier en l’occurrence le fichier trace.txt
le double « > » soit >> signifie « à la suite ».
le & à la fin force le lancement en background, c’est à dire que debian rend la main après lancement, ce qui permet de continuer à taper des commandes debian.
dans mon cas, je peux lancer :
jeff@Rpi5jf:~ $ cat trace.txt
Sat 6 Sep 18:37:17 CEST 2025
total used free shared buff/cache available
Mem: 8063 1113 3922 61 3184 6949
Swap: 511 0 511
total used free shared buff/cache available
Mem: 8063 1109 3924 61 3186 6953
…
Si besoin, pour arrêter le processus « free », faire ps -eaf | grep free pour noter son pid (process id).
dans mon cas, je trouve la ligne :
jeff 2268728 2268095 0 18:37 pts/1 00:00:00 free -m -s 600
le 1 er numéro 2268728 est le pid (ne pas confondre avec le 2e qui est l’id du processus père !)
faire :
kill -9 2268728 (attention avec la commande kill, cela ne pardonne pas en cas d’erreur)
Pour voir le résultat, éditer le fichier (nano ou vi) ou faire « cat ». Même avec le process free en fonction, cela marche.
1 « J'aime »
Bonsoir,
A ce jour, je n’ai jamais eu de retour concernant le plugin Monitoring et une baisse de mémoire, et ce plugin tourne sur l’ensemble de mes jeedom depuis des années, et pour certains de ces jeedom, ils tournent depuis plusieurs mois, et cela n’a pas d’incidence.
D’autant plus que le plugin Monitoring est lié au plugin SSH-Manager, donc si tu veux tester son arrêt, il faut couper le plugin ssh-manager en même temps…
Après, comme il a été dit à plusieurs reprises, que la mémoire baisse (mémoire libre), ce n’est pas forcément un problème, cela signifie juste que ton système effectue des tâches qui se chargent en mémoire au fur et à mesure… Regarde dans le plugin Monitoring, (pas sur le widget, mais dans les commandes de ton équipement, il y a plusieurs données concernant la mémoire. Si tu restes sur le fait que le soucis vient de la mémoire, alors il faut monitorer l’évolution de l’ensemble de ces données mémoire, pas seulement la mémoire libre, car elles sont toutes liées entre elles.
TiTidom.
Merci de ton retour. J’ai mis en place le suivi. Wait and see.
J’utilise Monitoring et ssh-manager depuis un moment. Je recherche toutes les plugin qui sont communs avec les autres utilisateurs qui rencontrent le pb. Je suis sur monitoring mais je vais voir avec d’autres qui ont évolué ou que j’ai ajouté ces 3-5 derniers mois. Ce qui est de nouveau sur ma config c’est que j’ai ajouté dans monitoring mon équipement Synology (qui ne contient pas Jeedom), le Synology m’alerte souvent sur le nombre de journeaux trop importants depuis. Bref, c’est un test, ce n’est pas une critique du Plugin.
Et merci pour ce plugin qui est essentiel pour la bonne santé des Jeedom.
Pour info, un sujet intéressant :
Jeedom redoutable de stabilité - Discussions Générales - Communauté Jeedom
Ah ? En ce qui me concerne, j’interviens sur mon jeedom quand j’intègre de nouveaux périphériques ou qu’on change des habitudes, ce qui oblige à créer/modifier des scénarios mais c’est vraiment rare que je le redémarre.
Un bon système domotique est un système qui s’oublie. Jeedom remplit parfaitement ce rôle.
Comme le rappelle Fabrice, jeedom est hyper stable (version à jour sur débian 11).
Bonjour,
Je suis d’accord avec vous, sauf que mon Jeedom qui s’était fait « oublier » pendant 4 mois (alors que je m’occupais de lui) a commencé à se planter régulièrement quand je l’ai laissé tranquille.
« Un bon système est un système qui s’oublie » : je suis d’accord., mais comment interpréter votre phrase si le système plante ?
Pour ma part, un système qui plante n’est pas pour autant un mauvais système, à condition qu’on y remédie même si le plantage est impossible. Il n’y a que ceux qui ne font rien qui ne font pas d’erreur. Je sais aussi que le programmeur qui fera un contournement n’est pas forcement celui qui a commis l’erreur. Je prends aussi ma part en ce qui concerne la possibilité d’erreur.
Au passage, vous êtes sous debian 11 !
Oui, je suis sur la version préconisée par jeedom.
1 « J'aime »
En phase stable (peu d’évolution de l’installation ou de versions de Jeedom ou plug-in) il n’y a pas de raison d’intervenir sur la configuration. C’est ce que j’ai fais au printemps occupé à autre chose et c’est là que j’ai constaté les plantages.
Quand je suis en phase de projet domotique, (arrosage avec vanne cet été et batterie solaire en ce moment) il est parfois nécessaire de redémarrer et l’on ne s’aperçoit pas que les performances se dégradent dans le temps puis que l’on réinitialise les mémoires et autres.
Je ne pense pas qu’en disant que ces plantages ne sont pas liés à tel ou tel composant nous pourrions avancer.
Je crois au contraire que c’est toute la force de la communauté avec ses expériences diverses et ses experts que l’on progresse tous et Jeedom aussi. Depuis 8 ans que je développe mon Jeedom j’ai énormément appris de la communauté, c’est la force de Jeedom. Sans le collectif, la solution restera entre les mains d’experts et ne se développera pas. C’est pour cela que j’ai un peu du mal avec les messages condescendants et parfois agressifs de certains. Ils font du mal à la solution et à la collectivité.
1 « J'aime »
Bonjour,
Voici un aperçu des premières données :
Si on observe entre deux remontées de mémoire libre, la perte sur 24 heures est de 40 mb sur 3900 mb encore libres, soit un rapport 0,01 = 1 % de la RAM par jour. Il faudrait 90 jours pour que cela conduise au crash si une simple fuite était à l’origine. Une fuite continue ne semble pas être la bonne piste.
Pour devancer les questions, la remontée survient à 3:00.
Actuellement, les plugins monitoring et camera sont désactivés, et je ne sais pas si cela va planter.
Wait and see.
La release debian 12 date de juin 2023, soit il y a plus de 2 ans, et avec un Rpi5 la recommandation en début d’année 2025 était debian 12.
N’a-t-on pas un peu de recul maintenant ?
Pour compléter, je n’utilise aucun plugin incompatible debian 12 signalé dans
(merci à Mips, DanielJ et ngrataloup pour cet état des lieux)
Un rpi5 ne fonctionne pas sous deb11, ce n’est donc pas une recommandation mais une obligation
Attention, il ne s’agit pas d’une liste officielle, mais bien d. Une synthèse du retour des utilisateurs (qui testent plus ou moins bien !)
Sans doute des milliers d’installation qui tournent sans pb
Norbert
C’est bien ce que j’avais compris, mais je suis prudent / assertions.
Pour la liste, c’est un apport remarquable et j’utilise avec précaution. C’est tout de même un bon point de départ. Un plugin noté HS est à éviter ou utiliser avec précaution.
Avec des milliers de conf en debian 12 et Rpi5, il serait temps de dire que cela marche. Bien sûr, vu la complexité et la diversité des conf, personne ne peut se plaindre si on découvre un pb. Un soft sans correctifs réguliers est un soft qui n’est pas utilisé et/ou pas maintenu !
Du coup, jeedom sas livre désormais sous deb12, donc …
ça progresse. merci aux développeurs.
D’après la release note, la 4.20 ne concerne que les box officielles et seulement le processus de restauration. Il faudra attendre pour le Rpi, mais en tous cas, debian 12 et jeedom sont maintenant mariés.
1 « J'aime »
Ma Smart tourne sous Debian 12 depuis bien plus d’un an !
Je remarque que ça fait un moment que je l’ai pas mise à jour du coup, faut que je passe aux nouvelles images sur ma prod : les cordonniers les plus mal chaussés. C’est hyper stable, je la redémarre uniquement pour des tests en fait :
Et j’ai beau avoir une petite connaissance du fonctionnement de l’utilisation de la mémoire sous Linux, jamais je ne m’avancerais à la mettre en cause sans de solides arguments…
1 « J'aime »
Moi aussi je ne redémarrais mon Rpi que pour faire des tests, et dans les 4 premiers mois, j’en faisait une fois pas semaine. Depuis que je n’en fais plus, mon Rpi se plante au bout de 3 semaines.
Rien ni surtout personne n’est en cause mais quand qqchose ne marche pas, il faut en trouver la raison. La progression de l’occupation mémoire est un indice comme un autre. On se raccroche à ce qu’on peut pour l’investigation.
Juste une remarque : Debian est super, Jeedom est stable et plébiscité, le hard est éprouvé, avec chaque fois des milliers d’installations : Si malgré toutes ces qualités, certaines installations plantent, il y a forcément un biais d’analyse ou des angles morts.
Côté debian, mon jeedom me signale d’un coup hier 4 pages de 50 lignes de packages OS à faire évoluer. Pas mal de tests d’analyse d’impact et de non régression à faire sur Jeedom et ses plugins !
Il y a aussi une release jeedom qui ne concerne apparemment pas le Rpi d’après la note de version mais qui est néanmoins proposée.
Vous écrivez :
Et vous avez une lumière bleue qui vous intrigue, alors nous on a des pistes, que vous ne voulez pas appliquer.
On part du principe qu’il n’y a pas de problème de mémoire (c’est une hypothèse largement partagée par les experts de l’OS ici) et vous avez un HAT avec SSD, qui n’est certainement pas le produit le plus courant ici.
Alors, je vous propose un test déjà pour isoler tout cela, c’est celui que je vous ai proposé le 1er septembre 2025 (je note l’année, car vu comment part ce fil, c’est pas dit qu’il ne soit pas encore alimenté d’ici l’an prochain 
)
Supprimez votre HAT et le SSD NVME que vous avez installé sur la machine, puis, installez l’OS (Raspberry Pi OS Bookworm Lite 64 bits) sur une carte microSD de bonne qualité (cela est largement capable de tenir au moins 2 ans), sans faire de backup / restaure de votre SSD, mais uniquement en utilisant la sauvegarde de Jeedom.
ET remplacez aussi votre bloc d’alimentation.
Pour rappel, il y a beaucoup d’utilisateur qui utilisent encore des Pi3 et Pi3B, avec seulement 1 petit Go de mémoire RAM !.
Si vous ne testez pas cela, je trouve qu’il est inutile de poursuivre ici, dans tous les sens, sans preuve ni but.
Bonjour
Pour ajouter au propos de Fabrice.
Pour analyser un problème de planté, il faut des éléments d’analyse, je vous ai déjà proposé d’installer un écran pour vérifier si vous aviez un Kernel Panic qui sera affiché sur l’écran dans ce cas.
L’écran n’a pas besoin d’être constamment allumé et vous pouvez mettre n’importe quel écran, j’utilise un vielle écran 4/3.
Le planté peut être de nature hard ou soft mais sans éléments pas d’analyse et de résolution possible.
Nota: Le Kernel Panic correspond par analogie à l’écran bleu de la mort sous Windows.
Bonjour
J’ai une question, je regarde cette valeur qui baisse sans arrêt sur mon PI4 et mon PI5 à travers le plugin
Comme vue, dans ce fil, j’ai aussi mis en place une suivi au niveau système
…
Je ne trouve pas de correspondance entre ces valeurs et celles du plug-in.
Dernière ligne donne 6,909 Go alors que le plugin 6,38 Go mais surtout, ça descend au niveau du plug-in pas au niveau système.
Peux-tu m’indiquer ce qui correspond à la valeur indiquée dans le plug-in ?
Merci de ton aide