Pas de requête SQL mon, mais le code suivant à mettre dans un bloc code d’un scenario :
foreach(jMQTTCmd::searchConfiguration('"influx::enable":"1"') as $cmd)
$scenario->setLog('cmd: '.$cmd->getHumanName());
Dans les logs du scenario tu auras les commandes pour lesquelles influx est actif (ou rien).
Je n’en ai aucune où la publication vers influxdb est activée.
Merci pour ton retour, on te tiendra au courant quand on aura passé en beta des changements qui pourraient améliorer la situation.
je suis sur la beta du 2022-03-02 01:01:20 et j’ai aussi une petite fuite de mémoire quelques mega /jours
ma config un Pi4 8G rasbian 10 en 32Bit
mon brocker est sur un orange pi a coté
j’ai que un seul équipement MQTT mais qui envoi au moins une info /min
Bonjour @Bad ,
Je me permets de revenir sur ce sujet.
J’ai migré pas mal d’échanges de mon système via MQTT.
J’avais constaté que mon niveau de RAM etait en augmentation constante sur mon RPi 4B 8Go et je suis ce post en attendant du nouveau.
Y aurait-il du nouveau dans la résolution de ce problème ?
Bonjour @Eridani78,
A date, il n’y a rien de nouveau, non.
Nous manquons de temps en ce moment pour faire l’« évolution magique qui va tout arranger »…
Le problème est intimement lié au daemon PHP, il faut changer beaucoup de choses pour s’en passer.
Si d’autres personnes ont ce problème, restez sur ce fil, on vous tiendra au courant.
Bad
Merci pour l’update.
A l’occasion, si je peux aider pour du test/debbugage, je le ferais volontiers.
Malgré tout il fut une époque où ce daemon ne posait aucun problème, en tous cas chez moi, j’ai tourné probablement 3 ans avec JMQTT avec pas mal de topics souscrits et écrit pour la gestion de ma chaudière Vaillant avec Ebusd et ma RAM était parfaitement stable, c’était même le plugin le plus stable de mon installation dans lequel je n’avais jamais remis les mains pendant 3 ans.
Le problème a commencé chez moi autour de décembre 2021 mais quasi en même temps j’ai updaté le core en 4.2, basculé mon zwave et mon zigbee sous MQTT et déporté mosquito sur une autre machine … donc difficile à dire si c’est lors d’un update du plugin que c’est apparu ou si c’est à cause des l’évolutions de mon installation
Il est peut-être plus simple de se pencher sur le daemon dans un premier temps avant de chercher à tout prix à le migrer, si ça tombe c’est vraiment une toute petite connerie.
Malheureusement, cette fuite existait avant notre reprise du plugin :
Et en faisant des debugs relativement semblable à ceux-ci :
On s’est rendu compte que c’est json_decode() qui bouffe la mémoire. La seule solution pour éviter qu’une fonction du langage PHP ne vampirise la mémoire, c’est de ne pas la lancer dans un daemon. D’où la nécessité du retrait du daemon PHP.
Il y a peu, j’avais une version fonctionnelle et presque finie, mais on a décidé partir sur des mécanismes plus normalisé et facile à maintenir dans le temps pour la communication avec Jeedom.
Encore un peu de patience, on ne va pas vous laisser dans la panade ! De toute façon, c’est nécessaire pour aller vers la prochaine grosse fonctionnalité (qu’on a entamé avec le jsonPath). 
Bad
Bravo pour cette stratégie 
sinon peut-être :
Une rapide recherche sur un memory leak et json_decode() donne des résultat à foison donc ça semble effectivement être un problème très courant et récurent.
Et effectivement avec l’évolution de mon installation json_decode() à certainement plus de « boulot » qu’avant, bien que déjà rien qu’avec Ebusd pour ma chaudière je devais déjà parser assez « profondément » dans pas mal de topics en json pour en extraire les valeurs.
Pour le moment je relance le daemon 4 fois par 24H à heure fixes et ça tien comme ça.
Alors oui, en effet on a vu tout ça 
Le souci, c’est que notre utilisation de la fonction est assez « légère » comparé à l’usage qu’en fait le core de Jeedom.
On a mis un certain nombre de contre-mesures dans le daemon, notamment avec un garbage collecting plus agressif, mais ça ne suffit toujours pas…
super j’attends la maj avec impatience, je peux faire quoi pour éviter le plantage de jeedom pour le moment ? un vidage de la mémoire programmé ?
+++
Simplement redémarrer le daemon
ok merci