J’ai l’impression que le plugin côté Jeedom est touché par le fuite mémoire python sous debian 11 (la partie serveur web socket j’imagine).
@Mips est capable de résoudre se soucis, il l’a déjà corrigé sur les plugins officiels.
Lorsque je redémarre le démon, voici le résultat sur le swap :
Je vais monitorer la mémoire du démon pour vérifier.
Quelqu’un d’autre remarque ce phénomène ?
étant donné qu’on utilise de base le fichier proposé dans le plugin-template (celui que @Mips a modifié) c’est peut être pas étonnant
j’ai commencé à faire des modif avant-hier sur le sujet …
tu peux d’ailleurs toi même appliquer les modif proposées par Mips pour voir si c’est bien ça en //
edit : pas tout à fait le même fichier, car il y a une modif en +, donc plutot ce fichier
J’ai de mon coté fait des tests avec @tomitomas cet après-midi … Les deltas de mémoire sont vraiment trop faibles pour tirer une quelconque conclusion. Si fuite mémoire il y a, elle n’est pas perceptible sur mon environnement
Norbert
Salut,
Vu qu’il me semble qu’il n’y a que des jeedomCom.send_change_immediate() et aucune usage de .add_changes(), je suggère de ne pas laisser la valeur cycle par défaut mais de forcer à 0 histoire de ne pas créer du tout ce thread: jeedomCom = jeedom_com(apikey=_apikey, url=_callback, cycle=0)
Content de voir qu’il y a du monde sur le coup 
J’ai remarqué que les trous de mémoire arrivent par accoup, ça peut rester des heures sans bouger, surtout après un redémarrage du démon.
C’est donc pas facile à reproduire rapidement…
Peut être pour ça qu’il ne se passe rien dans vos essais.
J’ai lancé le monitoring de la ram du démon pour pourvoir confirmer…
Bonjour,
Je rejoins cette discussion (après en avoir ouvert une autre pour le même sujet par erreur 
).
Je fais également les mêmes constatations depuis plusieurs semaines, mais je constate aussi que lors de ces montées brutales de l’utilisation de la mémoire, mon téléphone n’arrive plus à se connecter en Websocket (mais fonctionne parfaitement en http). Après avoir relancé le démon de JC, la mémoire est libérée et la connexion à WS est à nouveau fonctionnelle. Je viens d’appliquer le dernier correctif de @tomitomas. Reste à voir si le phénomène ne réapparaitra plus ces prochaines semaines.
Je viens de voir une nouvelle beta.
Est-ce le correctif ou bien dois-je modifier le fichier à la main ?
J’attends encore 1 jour de monitoring pour pouvoir ensuire comparer.
Là j’ai bien la ram du démon qui augmente, mais pas encore assey pour entamer le swap.
non ya strictement rien dans cette « nouvelle » beta, a part un rafraichissement du nom du repo. le market a considéré qu il y a une nouvelle version
Ok merci 
Je vais faire la modif du fichier py à la main ce soir et comparer.
Je vais tenter avec self._cycle = 0 comme l’a préconiser @Mips
Le swap n’est toujours pas entamé, mais ça ne devrait plus tarder, on peut voir que la ram du demon ne cesse d’augmenter :
J’ai pas de refresh auto sur la commande, je n’ai regardé pourquoi… Il n’y a que 4 points donc on n’a pas vraiment la bonne forme de courbe, mais ça suffit tout de même pour voir que la ram consommée par le démon ne cesse d’augmenter.
La consommation de ram continu d’augmenter :
J’ai fait la fausse maj pour virer la notif.
J’ai fait les motifs dans le fichier en forçant le cycle à 0 pour ne pas utiliser de nouveaux threads.
Redémarrer le démon.
Tout semble fonctionner normalement.
Résultats dans 2 ou 3 jours pour comparer avec avant…
Bon pour l’instant y’a pas photo :
Cette fois ci il y a le refresh programmé toutes les 10 minutes sur les pointillés, donc ça ne bouge vraiment pas
top !
et niveau retour d etat pas de changement tjs OK ?
Oui les retours d’état sont OK pour moi.
Après j’utilise JC sur mon tel, donc il n’est pas sut une tablette allumée en permanence.
C’est une utilisation ponctuelle, mais les retours d’état au lancement de l’application, ou sur les actions sont OK (en websocket), je n’ai pas constaté de soucis (malgré le cycle à 0).
J’ai modifié ça :
def __init__(self, apikey='', url='', cycle=0, retry=3):
Et ça :
self._cycle = 0
Donc c’est certain qu’il n’y a plus de nouveau thread.
Peut être qu’il faudra confirmer avec d’autres utilisateurs dans des utilisations différentes pour être sur que ça ne pose pas de soucis.
Quand à la mémoire je pense qu’on peut conclure que c’est ok, ça ne bouge plus du tout.
Et mon swap ne bouge plus non plus, donc JC était probablement le dernier de mes plugins qui était touché par ce soucis de fuite de mémoire.
J’ai réussi a faire bouger la mémoire d’un yota en cliquant un peut partout sur JC dans mon tel (on voit les petits zigouigoui à la fin) :
Et la ram est retournée ensuite à sa valeur initiale.
Bonjour,
Pour ma part ma mémoire augmente toujours, mais progressivement. Pour l’instant je n’ai pas eu de montée brutal comme je l’avais déjà rencontrée. Par contre, je monitor la mémoire totale et pas juste celle de JC… donc pas sur que cela vienne de JC. J’ai cherché sur le Forum (ne m’engueulez pas), mais je n’ai pas trouvé la commande Bash à ajouter dans Monitoring pour surveiller uniquement la mémoire utilisée par JC. @dJuL pourrait tu m’indiquer la commande que je puisse l’ajouter?
Bonne journée
Ici:
Mille merci @Mips… Je cherchais à faire cela avec Monitoring, je ne risquait pas de trouver 
Bon, reste à suivre l’évolution maintenant.
Pour ma part je vais désactiver le monitoring, la ram consommée par le démon est désormais stable :
Mon swap reste stable également :
@thomaspascal Tu peux redémarrer les démons un par un en regardant le résultat sur la ram et le swap en rafraichissant les valeurs entre chaque redémarrage.
Cela permet d’identifier les suspects.
Ensuite tu peux monitorer les démons incriminés pour vérifier l’évolution de la conso de ram.
