Problème de mémoire sur mon atlas

Bonjour,
Depuis quelques jours j’ai Z2M qui plante sans prévenir, lorsque je vais dans la page santé le démon est pourtant toujours OK.

Lorsque je reboot mon Atals, le démon apparait OK mais Z2m ne trouve pas. JE dois relancer le démon manuellement pour qu’il reparte.

J’ai mis a jour les dépendances au cas ou, jeedom est à jour.
Mqtt Discovery est également planté et lui est affiché en rouge après le problème de mémoire.

memoire suffisante affiche 1 mais la mémoire dispo affiche plus de 50%

Changement que j’ai fait, je suis entrain de reporter petit a petit mon instance Zée sur une autre instance avec un autre contrôleur, et j’intègre tout avec mqttdiscovery.

Est ce que quelqu’un a une idée ?
Le truc le plus étrange que j’ai c’est l’histoire du reboot de jeedom avec le démon jeezigbee qui affiche OK alors qu’il n’est pas démarré.



ici il affiche ok alors que je n’accèderaient pas a l’interface Z2M

voici les logs après reboot de jeezigbee
z2m.txt (424,9 Ko)

et il n’y a rien d’autre.

merci

Bonjour,

port du contrôleur auto pas bon.

akenad :slight_smile:

Bonjour,

La charge CPU à plus de 16 montre que le pauvre Atlas est saturé donc normal que ça ne fonctionne pas correctement.

J’avais mis le port directement, j’ai mis auto pour tester mais j’ai le même problème dans les 2 cas. Je vais remettre le port.

Concernant la charge, elle tourne autour de 2 sauf quand j’ai le problème de mémoire …

J’ai enlevé le mode auto et j’ai à nouveau le problème. J avais le problème tous les 3 jours, mais là ça fait 3 fois aujourd’hui.

Il ne peut pas y avoir un problème dans ma configuration z2m ?

Autre chose que j’ai faite, j’ai fait un nouveau container lxc pour le broker mqtt mosquitto pour le mette à jour

Ce matin même problème, jeezigbee planté, mémoire suffisante 1

Reboot, le démon jeezigbee ne repart pas tout seul. Je dois le relancer manuellement

Je ne sais plus où chercher.

Est ce que que ça peut venir du plug in mqttdiscovery sur lequel j’ai ajouté pas mal de périphériques ?

Non, ce n’est pas mqttdiscovery qui bloque le démon de jeezigbee.
et mqttdiscovery ne va pas prendre plus de mémoire que tu aies 1 ou 100 périphériques.

je pense que plutot que de chercher pq jeezigbee ne redémarre pas, tu devrais chercher qui consomme la mémoire dispo jusqu’à faire planter ta box.

Ok je vais me pencher la dessus.

Par contre je n’arrive pas a comprendre pourquoi le démon de jeezigbee est toujours OK alors que jeezigbee est NOK…
Pareil au démarrage de jeedom. tout est vert mais jeezigbee ne fonctionne pas.

SIZE     PID USER     COMMAND
630888    485 mysql    /usr/sbin/mariadbd
216772   2688 root     node --preserve-symlinks server/bin/www.js
211232   1928 www-data homebridge
197088   3550 root     node index.js
136908   2171 www-data homebridge-config-ui-x
131032   2369 root     /usr/bin/node /var/www/html/plugins/mqtt2/resources/mqtt2d/mqtt2d.js --loglevel error --socketport 55035 --mqtt_server mqtt://[IP_ADDRESS]:1883 --username [USERNAME] --password [PASSWORD] --callback http://127.0.0.1:80/plugins/mqtt2/core/php/jeeMqtt2.php --apikey [API_KEY] --cycle 0.3 --root_topic jeedom_atlas --pid /tmp/jeedom/mqtt2/deamon.pid
93672    2128 www-data nodejs /var/www/html/plugins/maillistener/resources/maillistener.js [EMAIL_ADDRESS]@imap.gmail.com http://[IP_ADDRESS]/plugins/maillistener/core/api/maillistener.php?apikey=[API_KEY] [EMAIL_ADDRESS] [APP_PASSWORD] imap.gmail.com 993 false /var/www/html/plugins/maillistener/resources/attachments/
92568    1950 www-data node /var/www/html/plugins/hkControl/resources/hkControl.js http://[IP_ADDRESS]/core/api/jeeApi.php [API_KEY] 12217 error /var/www/html/plugins/hkControl/data/pairings.json NoCam
89640    3534 root     npm start
88320    2677 root     npm start
71896    2164 www-data node /var/www/html/plugins/matter/resources/daemon/rpc-wrapper.mjs --port 55123 --loglevel error --jeedom-url http://127.0.0.1 --jeedom-apikey [API_KEY] --push 1 --poll-interval 300 --url ws://[IP_ADDRESS]:5580/ws --pidfile /tmp/jeedom/matter/matterd.pid.rpc
49592    2157 www-data /usr/bin/node /var/www/html/plugins/matter/core/class/../../resources/daemon/daemon.js --pidfile /tmp/jeedom/matter/matterd.pid --loglevel error --logfile /var/www/html/core/class/../../log/matterd --jeedom-url http://127.0.0.1 --jeedom-apikey [API_KEY] --rpc-port 55123 --storage-path /var/www/html/plugins/matter/core/class/../../data --matter-url ws://[IP_ADDRESS]:5580/ws
39504    2094 www-data /var/www/html/plugins/jMQTT/resources/jmqttd/venv/bin/python3 /var/www/html/plugins/jMQTT/resources/jmqttd/jmqttd.py
38700    4289 www-data /var/www/html/plugins/MQTTDiscovery/core/class/../../resources/venv/bin/python3 /var/www/html/plugins/MQTTDiscovery/resources/mqttdiscoveryd.py --loglevel debug --mqtthost [IP_ADDRESS] --mqttport 1883 --mqttuser [USERNAME] --mqttpassword [PASSWORD] --discoverytopic homeassistant --datatopics myfox2mqtt,Myfox2mqtt,home,zigbee2mqtt_Nano --socketport 55074 --cycle 1 --callback http://127.0.0.1:80/plugins/MQTTDiscovery/core/php/jeeMQTTDiscovery.php --apikey [API_KEY] --pid /tmp/jeedom/MQTTDiscovery/daemon.pid
35872    1840 www-data python3 /var/www/html/plugins/broadlink/resources/broadlinkd/broadlinkd.py --loglevel none --socketport 55013 --sockethost 127.0.0.1 --callback http://127.0.0.1:80/plugins/broadlink/core/php/jeeBroadlink.php --apikey [API_KEY] --cycle 0.3 --pid /tmp/jeedom/broadlink/deamon.pid
34688     308 root     /usr/sbin/ModemManager

et lorsque ca plante pourtant la quantité de membre dispo n’a pas l’air mauvaise

jeezigbee considère que son démon est ok s’il trouve un process contenant « zigbee2mqtt »

Comment je peux trouver pourquoi Z2m ne démarre pas au démarrage de jeedom ? je suis obligé de le faire manuellement.

je vais essayer de trouver pourquoi la charge monte d’un coup.


j’ai installé le plug in monitoring pour essayer de comprendre, mais quelle commande historier pour avoir le bon suivi ? Charge Système 1 min ?

il faudrait regarder la liste des process en cours lorsque le problème se pose: htop via ssh par exemple

tu peux en plus préparer ce bloc code dans un scénario et l’executer lors du problème, cela fait exactement ce que fait le plugin mais on verra le contenu:

$res = system::ps('zigbee2mqtt');
$scenario->setLog(json_encode($res));
if (!empty($res)) {
  $scenario->setLog("z2m is running");
} else {
  $scenario->setLog("z2m is not running");
}
1 « J'aime »

merci, j’ai préparé le bloc code, et vérité la commande htop


prochain plantge je partage les infos

et autre info qui a peut être une importance,
Z2m de jeezigbee sur mon atlas publie sur le topic zigbee2mqtt_Nano et mqtt discovery ecoute un autre topic zigbee2mqtt_Nano qui reçois les infos d’une autre instance Zée sur un smhub smilight.

Donc ce n’est pas un autre mais le même
Ceci n’a pas d’impact de toute façon, les deux peuvent avoir souscrit au même topic

ca y est ca plante, et au moment du partage je n’avais plus que 4% de ram


la ram remonte après le plantage

resultat du bloc code :

[2026-04-06 07:21:10][SCENARIO] -- Début : . Tags : {"#trigger#":"JeedomConnect","#trigger_name#":"","#trigger_id#":"","#trigger_message#":"Lancement du scénario [Aucun][Monitoring][code plantage] (241) par l'utilisateur admin","#trigger_value#":"","#eqId#":"1074","#userJC#":"admin"}
[2026-04-06 07:21:10][SCENARIO] - Exécution du sous-élément de type [action] : code
[2026-04-06 07:21:10][SCENARIO] Exécution d'un bloc code
[2026-04-06 07:21:10][SCENARIO] [{"pid":"18861","tty":"?","stat":"Sl","time":"5:24","command":"\/var\/www\/html\/plugins\/MQTTDiscovery\/core\/class\/..\/..\/resources\/venv\/bin\/python3 \/var\/www\/html\/plugins\/MQTTDiscovery\/resources\/mqttdiscoveryd.py --loglevel debug --mqtthost 192.168.18.85 --mqttport 1883 --mqttuser xavax --mqttpassword b0mbeC --discoverytopic homeassistant --datatopics myfox2mqtt,Myfox2mqtt,zigbee2mqtt_Nano --socketport 55074 --cycle 1 --callback http:\/\/127.0.0.1:80\/plugins\/MQTTDiscovery\/core\/php\/jeeMQTTDiscovery.php --apikey 6irTTe83WX3u0FPE75OHA3SCDlZJAjrgwcQlw3ENLvOqWXv46NJD95SNzniFiiCx --pid \/tmp\/jeedom\/MQTTDiscovery\/daemon.pid"}]
[2026-04-06 07:21:10][SCENARIO] z2m is running
[2026-04-06 07:21:10][SCENARIO] Fin correcte du scénario

Voila maintenant on sait pourquoi jeezigbee pense que la démon tourne

Donc ok mais indirectement… et parce que le check démon est buggé dans jeezigbee…

Il a trouvé la ligne de mqttdiscovery qui contient le topic « zigbee2mqtt_nano » ce qui est évidemment une erreur d’interprétation.


Ok mais du coup cnest ça qui charge la mémoire jusqu’à stopper le processus ?
Je dois faire quoi ?

non, ce n’est pas ca qui charge la mémoire.

Concernant la mémoire, c’est quasi impossible à dire avec les infos données car le htop est trié sur le CPU, pas la mémoire.
Dans la capture donnée je ne vois pas de process consommant bcp de mémoire

Du coup je suis un peu dans l’impasse,
Dans mqttdiscovery une fois que j’ai ajouté mes équipements je dois quand même laissé le topic configuré zigbee2mqtt_nano pour avoir les infos des équipements ? Où est ce qu’un fois ajouté je peux enlever le topic des paramètre de configuration ?

Pour la mémoire ce paraît compliqué car elle chute un laps de temps mais reviens ok après. Mais de démon jeezigbee ne redémarre pas ….