Bonjour, je suis dans le même cas avec un rpi 4 4Go de ram. Moi c’est le plugin xiaomihome qui me pose soucis. En espérant qu’une solution soit trouvée 
Bonjour
Après presque 2 jours sur cette version beta de RFXCOM, tout roule sur le plugin, aucun bug apparent.
Par contre ça ne change pas grand chose sur la box Atlas. La mémoire est bien au démarrage et diminue constamment, un peu moins rapidement certes.
Du coup j’imagine que d’autres plugins type « python » ont le pb (comme j’en ai d’autres, enocean, BLEA).
A+
Manu
Ah j’en connais un qui va devoir prendre des congés 
@Mips
3 « J'aime »
Bonjour.
Le plugin Blea, oui, il a bien un problème (non reconnu par Jeedom) sur Debian 11 uniquement (constaté par la communauté).
Problème uniquement sur Debian 11.
Bonjour
Comment ça non reconnu ? Je pense que le change log du rfxcom et mes messages montre bien que jeedom est au courant et qu’on cherche à corriger. Même si je comprends que vous trouvez qu’on a trop traîner sur ce soucis majeur malheureusement c’est compliqué et on a pas pour habitude de communiquer sans réel avancé.
Bonjour Loïc.
Je parle de BLEA (le plugin du même nom), c’est le 1er mot de la phrase.
Car c’est pas blea le soucis mais tous les plugin python dû a une lib tierce dans le framework de base de jeedom pour les démon python.
Et d’après ce que j’ai pu lire il est bien prévu de revoir le plugin blea comme le rfxcom (tout comme sms et openenocean)
2 « J'aime »
Surtout qu’après les plugins officiels, il y a les plugins des devs tiers ainsi que les commandes linux à base de python: fail2ban, TheengsGateway … 
Non pas forcément… en l’occurrence pas le cas pour les 2 exemples cités ni mes plugins.
Je rappelle que le problème n’est pas causé par python 3.9.2 même si cela se produit avec cette version.
Salut à tous, est ce qu’on pourrait avoir un résumé de ce qu’il faudrait faire pour nos plugins qui peuvent aussi poser pb? Perso j’étais à 52% de libre et en relançant mon plugin teleinfo je suis repassé à 59%. Ok ce n’est pas le seul problème mais déjà si je peux régler ça sur mes plugins ce serait bon pour tous ceux qui l’utilise
2 « J'aime »
Ça ne semble pas aussi simple… de ce que j’ai lu c’est la conception même du démon qui pose problème. Ici Mips utilise asyncio qui est prévu pour tourner en permanence avec une boucle d’événement (comme Nodejs en fait ;-)), et il gère mieux la suppression des éléments en mémoire (c est ce que j’ai compris à la lecture de son code mais je suis pas expert du tout en python)
Surveilles d’abord la conso mémoire du plugin sur plusieurs jours pour voir la courbe.
Si c’est une ligne droite continue alors effectivement il y a un soucis.
S’il y a des montées et descentes alors il n’y en a pas
Ca mériterait un sujet dédié
Merci, je vais voir ça dès que possible
Bonjour,
Tgw en fonctionnement:
Ça fuit moins vite que rfxcom. Mais ça fuit quand même.
Si ce n’est pas python 3.9.2 le coupable, pouvez-vous mettre un nom sur la lib qui fuit?
En tout cas les fuites de tous les plugins avec daemon python fuyant se résolvent en installant python 3.9.19 …
1 « J'aime »
Je vais refaire des mesures pour comparer concernant l’app theengsgateway
je vais remettre en route mon monitoring pour fail2ban également d’ailleurs
non, je n’ai pas l’info, je l’aurais déjà donné sinon…
mais le fait que du code python puisse tourner sans fuite sous python 3.9.2 est pour moi une preuve que c’est possible et que donc non le problème n’est pas causé par, ni généralisé à, python 3.9.2 mais une combinaison plus complexe. c’est le seul fait dont je sois sur.
jamais dit le contraire mais, comme déjà dit ailleurs, ca ne prouve rien non plus (même si ca reste une possible solution).
plusieurs scénarios possible sans être exhaustif:
- soit ils ont trouvé un problème / mis en place qlqch pour s’arranger (je ne suis pas assez calé pour en savoir plus) pour correctement nettoyer lorsqu’une lib a un problème de fuite
- soit la lib X ayant un problème est dispo en version N sous python 3.9.2 et en version N+1 sous python 3.9.19
- soit cette même lib à un comportement différent entre les deux sans pour autant que ca soit python lui même qui se comporte différemment.
de toute façon je ne suis pas certain que ca soit une solution viable (car sinon pourquoi n’est-ce pas fait par debian directement? ils sont certainement plus malin que nous)
ceci dit, je pense qu’on devrait mettre plus d’efforts à passer plus rapidement sous debian12 et régler les problèmes là-bas 
4 « J'aime »
Comment tu suis l’évolution de la mémoire d’un plugin stp?
1 « J'aime »
Avec un scénario lancé toutes les 5 minutes qui traite le résultat de la commande:
ps -eo rss:10,size:10,vsz:10,command --sort -size
Il renseigne les commandes d’un virtuel.
2 « J'aime »
Bonjour @jpty
Ca nous intéresse bigrement pour faire avancer le schmilblick
Il serait intéressant, si tu as un peu de temps, pour nous donner un peu plus d’information pour des non initiés comme moi ?
Un Screenshot de la méthone pour un plugin comme zwave ou zigbee par exemple ?
Merci à toi
1 « J'aime »
Bonjour à tous,
Comme convenu je reviens vers vous après 3 jours de passage sur beta RFXcom
Pour rappel,
Odroid N2
Debian 11.7
Jeedom 4.4.6
Python 3.9.2
Remontée de 45% à 55 % uniquement lors de l’arrêt du plugin RFXcom pour son remplacement par le beta.
3 jourS plus tard nous sommes à 44%
Il y a du mieux. La chute progresse plus lentement. Mais il y clair qu’il y a d’autre souci de fuite ailleurs
Voila si ça peut aider
Jean Marc
