Je pense que sur une smart, ca doit aussi grandement améliorer les perfs. Sans ces modifs, avec des plugins comme zwaveJS ou z2m, le systeme doit bien swapper !
Norbert
C’est difficile d’intégrer cette modification directement dans une mise a jour de jeedom ?
sur du DIY, je pense que ce n’ets pas possible, chacun doit gérer son système (et là, on est sur des paramètres système), sur une smart ou atlas ou tu ne devrais pas trifouiller les fichiers système, il suffirait d’intégrer les commandes données dans un script de mise à jour
… le « il suffirait » vient d’un utilisateur qui ne maitrise pas le processus de mise à jour 
1 « J'aime »
Merci @ngrataloup pour ton support.
La manipulation a été effectué, après reboot voici mon statut. Je donnerais suite dans les prochaines heures et demain pour voir si la chute est aussi vertigineuse qu’auparavant ou si elle se stabilise à un niveau correcte.
J’ai par la même occasion désactivé mon scenario de reboot de demon de plugin.
EDIT SCREEN
A bientot 
1 « J'aime »
L’espace disque libre tmp n’a rien à voire avec la choucroute.
Il faut regarde, la mémoire et le swap utilisés, et sans doute aussi la charge qui devrait un peu diminuer
1 « J'aime »
Désolé je me suis planté de screenshot. j’ai modifié le post. Je voulais bien parler du swap.
Bonjour,
Voici l’état de ce jour du swap disponible. Si l’on compare avec la date du 4 au 6 décembre les courbes sont assez similaire. Si le problème persiste je devrais continuer à baisser jusqu’à un seuil critique. Pour le moment il n’en est pas encore la, je surveille et vous tiens au courant
EDIT:
Suite a la chute en cascade du swap de nouveau constaté j’ai une autre piste d’investigation.
La « TIMELINE » Je demande un Max de 50, pourtant j’en constate 433 !!
Pour info Il s’agit du pilotage du poele a pellet (Club2.0) Piloté par RFXCom.
EDIT: J’ai retiré la TIMELINE pour le club2.0 Je vais voir si cela ralentit la chute du swap.
Merci, je viens de passer les commandes par Jeedom, et sur ma smart je suis passé de 50% à 54% de mémoire disponible, c’est déjà ca. Demain je supprimerai mon périphériques zwave, je désactiverai le plugin et j’en profiterai pour faire un reboot complet.
Pour gagner en utilisation mémoire RAM est-ce que désactiver le plugin serait suffisant ou vaut il mieux carrément le supprimer ?
Le désactiver suffit, mais aucun intérêt à le garder si vous ne l’utilisez plus …
Rebooter aussi pour libérer la ram/swap et voir si la dernière modification a porté ces fruits
Norbert
Voilà, j’ai carrément désinstallé le plugin puisque inutile. Reboot du jeedom.
Après deux heures de fonctionnement, je suis passé d’environ 50% de mémoire libre à environ 60 % de mémoire libre.
Evidement le swap est toujours à 100%, à voir dans le temps.
Par contre, hasard ou pas, depuis le passage à debian 11, à chaque reboot du jeedom, je dois refaire le cookie du plugin Alexa 
J’aurais presque envie de dire "c’était mieux du temps de debian 10 … "
Remontée de la mémoire disponible suite à la suppression du plugin ZWAVE, et reboot du jeedom.
Le swap est toujours à 100%, mais trop tôt pour en tirer des conclusions.
1 « J'aime »
Hello à tous,
Je me permets de revenir sur le sujet après quelques semaines d’expérience
voici le couple swap/mem dispo
==> cette fois ci j’ai tout fait pour être un élève modèle 
Obligé de redémarrer quand le swap est < 10 et c’est planifié pour cette nuit .
Le fait que beaucoup d’entre nous sommes obligés de développer des rustines avec le swap démontre quand même que l’on a un problème de gestion mémoire. J’espère que l’on pourra trouver une solution pérenne et que les petits systèmes comme la jeedom smart pourront continuer à vivre normalement.
du coup, on va reprende les actions à réaliser :
lancer la commande suivante :
sudo journalctl --disk-usage
Si disk usage > 500Mo,
lancer
grep -E "SystemMaxUse|MaxRetentionSec" /etc/systemd/journald.conf
si rien ne sort :
sudo sed -i.bak 's/^#SystemMaxUse=.*/SystemMaxUse=20M/' /etc/systemd/journald.conf
sudo sed 's/^#MaxRetentionSec=.*/MaxRetentionSec=1w/' /etc/systemd/journald.conf
sudo systemctl restart systemd-journald
puis relancer
grep -E "SystemMaxUse|MaxRetentionSec" /etc/systemd/journald.conf
et rebooter
Norbert
2 « J'aime »
La solution proposée n’est pas une rustine mais une solution perenne
Bonjour, je vous lis car j’ai le même soucis.
Au retour de la commande (grep -E « SystemMaxUse|MaxRetentionSec » /etc/systemd/journald.conf) après toutes les commandes précédentes sur une smart cela donne :
SystemMaxUse=20M
#MaxRetentionSec=
Le Maxretentionsec reste tout le temps sans valeur. Par contre, la valeur du systemmaxuse est bien pris en compte.
C’est ça qui est beau , on ne se connait pas mais on doit faire confiance.
je dois avouer que les secondes pendant le reboot , j’ai bcp pensé à toi en me disant " 
j’aurais du faire une sauvegarde … "
En tout cas ; ça à l’air de rouler …
Merci
pareil …
Ça me fait plaisir qu’on pense à moi 
Du coup, tu pourras indiqué le résultat sur l’usage du swap ?
Norbert
1 « J'aime »
Désolé si je me suis mal exprimé. Ce que j’appelais rustine c’est les scénarios de redémarrage des démons quand le swap est trop bas. Et merci pour les solutions proposées.