# Titre : Utilisation élevée du CPU (~60%) avec v **URL:** \ **Category:** Configuration\ **Tags:** mqtt\ **Created:** [Mars 12, 2026, 9:28 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126 "2026-03-12T09:28:47Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![bamboleate](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bamboleate/32/20501_2.png) [@bamboleate](https://community.gladysassistant.com/u/bamboleate)\ **Post date:** [Mars 12, 2026, 9:28 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/1 "2026-03-12T09:28:48Z")
* * * **Environnement :** - Gladys v4.70.0 (mise à jour automatique via Watchtower) - Docker sur Linux (Ubuntu), `network_mode: host` - Intégration MQTT avec plusieurs appareils (Raspberry Pis) * * * **Problème :** Après que Watchtower a automatiquement mis à jour Gladys de v4.66.8 vers v4.70.0, le conteneur a commencé à consommer ~60% du CPU en permanence – pas seulement au démarrage, mais en continu. ```auto gladys 59.72% ``` Les logs montraient une avalanche d’erreurs au démarrage : ```auto NotFoundError: DeviceFeature mqtt:xxx not found ``` Cela semble être un problème de synchronisation où des messages MQTT conservés arrivent avant que Gladys n’ait chargé son cache de device features. Cependant, même après que les erreurs de démarrage ont cessé et que les logs étaient propres, le CPU est resté à ~60%. * * * **Solution :** Rétrogradé vers v4.66.8 et épinglé la version pour empêcher Watchtower de mettre à jour automatiquement : yaml ```auto gladys: image: gladysassistant/gladys:v4.66.8 labels: com.centurylinklabs.watchtower.enable: "false" ``` Après la rétrogradation, le CPU a chuté immédiatement à ~4%. ```auto gladys 3.90% ``` * * * **Question :** Est-ce un problème connu avec la v4.70.0 ? Y a-t-il des plans pour corriger cette régression de CPU ? J’aimerais mettre à jour éventuellement, mais pas si cela plombe à nouveau les performances. ---
**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\ **Post date:** [Mars 12, 2026, 5:34 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/2 "2026-03-12T17:34:08Z")
Salut @bamboleate et bienvenue sur le forum ! tu dois avoir quelque chose qui ne va pas car de mon côté je n’ai pas de soucis de CPU qui s’emballe depuis la version 4.70 (ni même avant) : ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/e/0/e03bf1b984d6f0f9bad99fc193bccc14f4baa9c7.png) Et j’ai du zigbee, du node-red, du zwave et des scènes qui tournent sur Gladys. Quelle est ton architecture hardware pour faire tourner Gladys ? (cpu, ram, hdd/sdd, etc.) ---
**Author:** ![bamboleate](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bamboleate/32/20501_2.png) [@bamboleate](https://community.gladysassistant.com/u/bamboleate)\ **Post date:** [Mars 12, 2026, 9:17 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/3 "2026-03-12T21:17:11Z")
Salut @mutmut, merci d’avoir vérifié ! Mon matériel: - **Machine:** Minisforum UM350 (AMD Ryzen 5 3550H) - **RAM:** 32 GB - **Storage:** several HDDs and SSDs connected - **OS:** Ubuntu 24.04 - Docker, `network_mode: host` Le pic d’utilisation CPU est très reproductible de mon côté. Voici l’avant/après : **v4.70.0:** ```auto gladys 59.72% ``` **v4.66.8 (same machine, same config, same moment):** ```auto gladys 3.90% ``` J’utilise l’intégration MQTT avec 3 Raspberry Pi (cartes relais + capteurs). Pas de Zigbee, pas de Z-Wave, j’utilise Node-RED. Une chose que j’ai remarquée dans les logs au démarrage avec la v4.70.0 : ```auto NotFoundError: DeviceFeature mqtt:xxx not found ``` Cela se répète pour chaque DeviceFeature MQTT à chaque démarrage — on dirait que les messages conservés (retained messages) arrivent avant que le cache des appareils ne soit prêt. Cette avalanche d’erreurs pourrait-elle provoquer le pic d’utilisation du CPU ? Peut-être que c’est spécifique aux configurations MQTT ? ---
**Author:** ![mutmut](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/mutmut/32/14064_2.png) [@mutmut](https://community.gladysassistant.com/u/mutmut)\ **Post date:** [Mars 12, 2026, 9:56 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/4 "2026-03-12T21:56:08Z")
Ton matériel est clairement bien, de mon côté je suis sur un cluster proxmox et Gladys est sur un LXE (équivalent VM pour faire simple) avec 6Go de RAM et 2 vCPU. Je ne suis pas un expert pour une analyse poussée malheureusement. Néanmoins côté intégration MQTT de Gladys, utilises-tu l’intégration interne ? ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/3/7/3719c4272c1c84b858e50a9d9b66454dda5c23a5.png) Ensuite, que dit la page de debug ? ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/0/6/06c632165fe912be63a45b7ba493413af2de4043.png) Si tu utilises `MQTT Explorer` (par exemple) pour te connecter au broker MQTT, as-tu des informations de tes RPi qui apparaissent ? ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/b/7/b71e4795e0ae467c70a789d00bc8c541bf18f2bd.png) Autre point, comment as-tu configuré tes appareils dans l’intégration MQTT ? ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/1/f/1fae118aa1d2f286ece035f6033d05bd0c529aa9.png) ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/6/0/60732f30139dce1428c8b35be314c4d026454ad3.png) De ce que je vois du message d’erreur, un (ou plusieurs ?) appareil n’est pas trouvé/reconnu, il faudrait voir avec `MQTT Explorer` si il est bien visible et si sa configuration est toujours bonne dans l’intégration MQTT de Gladys. ---
**Author:** ![bamboleate](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bamboleate/32/20501_2.png) [@bamboleate](https://community.gladysassistant.com/u/bamboleate)\ **Post date:** [Mars 13, 2026, 8:36 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/5 "2026-03-13T08:36:24Z")
Salut @mutmut, merci pour les questions détaillées ! Oui, j’utilise l’intégration MQTT interne dans Gladys. Concernant les messages `NotFoundError` : j’ai déjà étudié cela en profondeur. Les erreurs apparaissent **seulement au démarrage** et sont un problème de synchronisation — le broker MQTT livre des messages conservés avant que Gladys ait fini de charger son cache de device features. Après le démarrage, les logs sont complètement propres et tous les appareils fonctionnent correctement. Les RPis publient correctement, les topics sont corrects, et tout est visible dans MQTT Explorer. Ces erreurs ne sont **pas** la cause de mes problèmes — elles sont un symptôme du timing au démarrage. Et plus important : le CPU reste à ~60 % **en permanence** , pas seulement pendant la pluie d’erreurs au démarrage. Le point clé est la comparaison directe : - **v4.70.0** → 60 % CPU en permanence, mêmes erreurs au démarrage - **v4.66.8** → 4 % CPU en permanence, mêmes erreurs au démarrage (le problème de temporisation existe dans les deux versions) Donc quelque chose a changé entre v4.66.8 et v4.70.0 qui provoque une régression CPU, du moins sur ma configuration avec MQTT. Les erreurs au démarrage sont un problème distinct (plus ancien). ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Mars 13, 2026, 8:42 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/6 "2026-03-13T08:42:10Z")
@bamboleate Merci beaucoup pour le rapport, et désolé pour le désagrément. Avez-vous essayé d’installer d’autres versions de Gladys entre-temps ? Voici le journal des modifications complet : > **[Releases · GladysAssistant/Gladys](https://github.com/GladysAssistant/Gladys/releases)** > > A privacy-first, open-source home assistant. Contribute to GladysAssistant/Gladys development by creating an account on GitHub. Pourriez-vous procéder à une mise à jour version par version jusqu’à trouver quelle version a introduit le problème ? Cela nous aiderait à identifier exactement quelle version a causé le problème, ce qui facilitera grandement notre enquête. ---
**Author:** ![bamboleate](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bamboleate/32/20501_2.png) [@bamboleate](https://community.gladysassistant.com/u/bamboleate)\ **Post date:** [Mars 13, 2026, 9:56 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/7 "2026-03-13T09:56:16Z")
Mon premier instinct dit que ça vient de la 4.70 parce qu’avant j’avais watchtower activé et je ne me donnais pas la peine de gérer manuellement toutes les versions, mais quand j’ai été confronté au problème pour la première fois, c’était la 4.70 et je n’ai fait qu’une grosse rétrogradation pour ne pas trop bidouiller et juste le remettre à fonctionner. MAIS j’installerai toutes les versions finalement pour vous aider à identifier le problème. Bien sûr ce week-end je ---
**Author:** ![bamboleate](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bamboleate/32/20501_2.png) [@bamboleate](https://community.gladysassistant.com/u/bamboleate)\ **Post date:** [Mars 19, 2026, 7:33 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/8 "2026-03-19T19:33:30Z")
Salut @pierre-gilles, J’ai effectué la mise à niveau progressive comme tu l’as suggéré. Voici mes résultats : - **v4.66.9** → CPU normal, aucun problème - **v4.67.0** → CPU monte immédiatement à \~57% et y reste Donc le problème a été introduit dans **v4.67.0**. Le journal des modifications pour cette version ne comporte que trois modifications : - Intégration Nuki - Sauvegarde DuckDB de Gladys Gateway sur une connexion DB temporaire - Mise à jour de la dépendance HAP vers la dernière version stable Je n’utilise pas HomeKit/Apple Home, donc je ne peux pas confirmer si la mise à jour de HAP est la cause — mais cela semble être le ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Mars 19, 2026, 7:36 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/9 "2026-03-19T19:36:21Z")
Vois-tu exactement quel processus provoque le pic d’utilisation du processeur ? Est-ce le processus Node.js de Gladys ? Rien d’étrange dans les logs ? ---
**Author:** ![bamboleate](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bamboleate/32/20501_2.png) [@bamboleate](https://community.gladysassistant.com/u/bamboleate)\ **Post date:** [Mars 19, 2026, 7:39 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/10 "2026-03-19T19:39:21Z")
Salut @pierre-gilles, Les logs montrent quelque chose d’intéressant. Il y a une avalanche de rejets de promesses non gérés liés à des DeviceFeature MQTT introuvables : ```auto NotFoundError: DeviceFeature mqtt:wozipi:07 not found NotFoundError: DeviceFeature mqtt:wozipi:10 not found NotFoundError: DeviceFeature mqtt:wozipi_bme680:temperature not found [...and so on] ``` Ces erreurs apparaissent toutes les quelques secondes (mon WoZiPi envoie des messages MQTT en continu). Sur la v4.66.9 cela était apparemment géré silencieusement — sur la v4.67.0 cela semble provoquer une boucle CPU. À noter également : `ps aux` n’est pas disponible à l’intérieur du conteneur, mais toutes les erreurs proviennent du processus Node.js (`index.js`), donc oui — c’est le processus Node.js de Gladys qui cause le pic. Je n’utilise pas HomeKit, donc la mise à jour de la dépendance HAP n’est probablement pas la cause. Mon hypothèse serait un changement dans la gestion des rejets de promesses non gérés entre la v4.66.9 et la v4.67.0. J’espère que cela aidera ! ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Mars 19, 2026, 7:43 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/11 "2026-03-19T19:43:46Z")
Bizarre, car rien n’a changé de ce côté ! Je me demande si cela pourrait venir de l’intégration Nuki, car l’intégration Nuki utilise MQTT pour écouter des messages MQTT provenant des serrures Nuki. Cc @ProtZ ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Mars 19, 2026, 7:47 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/12 "2026-03-19T19:47:33Z")
Au fait, nous allons publier une amélioration de l’intégration Nuki dans la prochaine version de Gladys pour empêcher l’intégration Nuki de démarrer si elle n’est pas configurée, donc cela pourrait certainement vous aider pour cela ! ( pas 100 % sûr) > > > FIX : at start check if service is configured and send ServiceConfigurationError… if not > FIX : do not subscribe through to all device but only those registered for Nuki service > FIX : do not authorize to perform a scan (http or mqtt) if service is not configured ; stop the loading spinner and display a message > IMPROVEMENT : control API token in setup tab, if an error occured display an error message, then clear the api token > Code refactoring ---
**Author:** ![bamboleate](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bamboleate/32/20501_2.png) [@bamboleate](https://community.gladysassistant.com/u/bamboleate)\ **Post date:** [Mars 19, 2026, 7:52 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/13 "2026-03-19T19:52:35Z")
Eh bien.. ça me dépasse complètement. Si je peux fournir quelque chose qui pourrait vous aider, n’hésitez pas à me contacter. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Mars 19, 2026, 7:55 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/14 "2026-03-19T19:55:44Z")
Je vais bientôt publier la nouvelle version de Gladys avec ce correctif, et pourrais-tu simplement essayer cette version pour voir si elle résout ton problème. Sinon, nous étudierons le problème plus en profondeur ensemble 😊 ---
**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\ **Post date:** [Mars 19, 2026, 8:32 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/15 "2026-03-19T20:32:52Z")
> [@pierre-gilles](#): > > Je me demande si cela pourrait venir de l’intégration Nuki, car l’intégration Nuki utilise MQTT pour écouter des messages MQTT provenant des serrures Nuki. Je valide ce point, j’ai egalement des logs Nuki qui n’etaient pas present avant, liés à mqtt. Pour le moment de mon coté, la charge est toujours tolérée par le mini PC, mais ça m’a intrigué. Je n’ai pas eu le temps d’investiguer ---
**Author:** ![ProtZ](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/protz/32/1641_2.png) [@ProtZ](https://community.gladysassistant.com/u/ProtZ)\ **Post date:** [Mars 20, 2026, 1:23 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/16 "2026-03-20T13:23:42Z")
Hello, Je confirme que les logs mqtt en trop cela vient de l’intégration Nuki v1, c’est normalement corrigé sur la v1.0.1 (@mutmut avait détecté ce soucis dès la release G4.67)). Le susbribe mqtt au démarrage se faisait sur tous les devices existants, l’attribut de recherche était mal configuré et allait au delà du service Nuki, ça ne devait pas avoir de conséquence outre mesure en revanche. ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Mars 20, 2026, 2:29 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/17 "2026-03-20T14:29:40Z")
@bamboleate Je viens de publier une mise à jour de Gladys (v4.71.0) avec le correctif, dites-moi si cela résout votre problème ! > [@Gladys Assistant 4.71 : Nuki & Matter](https://community.gladysassistant.com/t/gladys-assistant-4-71-nuki-matter/10142): > > Cette nouvelle version apporte des améliorations importantes sur Matter, Nuki, et plusieurs corrections de bugs. locked_with_key Nuki v1.0.1 : Une intégration plus robuste L’intégration Nuki a été mise à jour avec plusieurs correctifs importants : Au démarrage, Gladys vérifie maintenant que le service est bien configuré avant de démarrer, pour éviter les erreurs dans les logs. Les abonnements MQTT sont désormais limités aux seuls appareils Nuki enregistrés, ce qui évite des écoutes inutil… ---
**Author:** ![bamboleate](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bamboleate/32/20501_2.png) [@bamboleate](https://community.gladysassistant.com/u/bamboleate)\ **Post date:** [Mars 20, 2026, 4:46 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/18 "2026-03-20T16:46:20Z")
Bonjour @Pierre-Gilles, J’ai mis à jour de v4.66.8 à v4.71.0 et je vois toujours ~60–70% d’utilisation CPU. Après un débogage approfondi, j’ai trouvé deux problèmes distincts: * * * **Issue 1 : Condition de concurrence avec les messages conservés MQTT (boucle de plantage au démarrage)** Au démarrage, Mosquitto rejoue immédiatement tous les messages conservés sur `gladys/master/#` avant que Gladys n’ait fini de charger son cache de périphériques. Cela provoque un flot d’erreurs `NotFoundError: DeviceFeature mqtt:xxx not found` — une par topic conservé, à chaque redémarrage. Le pic CPU est causé par des rejets de promesses non gérés qui saturent la boucle d’événements. Solution de contournement : supprimez tous les messages conservés sur `gladys/master/#` en utilisant `mosquitto_pub -r -n`. Après un redémarrage, Gladys les repopule et fonctionne correctement — mais seulement jusqu’au redémarrage suivant. Cela ressemble à un bug où le service MQTT s’abonne avant que le gestionnaire de périphériques ait fini son initialisation. * * * **Issue 2 : Le scanner de présence du LAN Manager exécute `ip neigh show` en boucle continue** Même avec le LAN Manager réglé sur « disabled » dans l’UI (et `LANMANAGER_PRESENCE_STATUS=disabled` confirmé dans la DB), Gladys continue de lancer `ip neigh show` via `execve` en continu. Comme `ip` n’est pas installé dans l’image Docker de Gladys (exit code 127), chaque appel échoue immédiatement et la boucle se répète. J’ai confirmé cela avec `strace -f -e execve` sur le PID de Gladys. Solution de contournement : injecter un script `ip` factice qui se termine proprement réduit légèrement la surcharge, mais la boucle elle-même continue. Cela semble être un bug où le LAN Manager ne respecte pas l’état désactivé à l’exécution. * * * **Environnement :** - Gladys v4.71.0 (mis à jour depuis v4.66.9) - Docker, network\_mode: host - Broker Mosquitto externe (eclipse-mosquitto:2.0) - ~30 appareils MQTT (sur plusieurs pis) - Hôte : Ubuntu 24.04, 32 GB RAM Je peux fournir davantage de logs ou tester des correctifs si utile. Merci ! ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Mars 22, 2026, 2:01 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/19 "2026-03-22T14:01:53Z")
Merci pour le retour, je vais examiner les deux problèmes 👍 Cela dit, je ne pense pas qu’ils aient été introduits dans Gladys v4.67.0, donc ils ne sont probablement pas la cause principale de l’utilisation élevée du processeur que vous observez. Puisque vous avez mentionné que l’utilisation du processeur est constante (pas seulement au démarrage), cela ne ressemble pas non plus à un problème de messages retenus. Vous avez également dit que votre WoZiPi envoie des messages MQTT en continu, avez‑vous une idée du taux de messages (par ex. messages par seconde) ? Une explication possible est qu’il n’y a pas de « bug » réel, mais plutôt une limitation de débit : Avec le code supplémentaire que nous avons ajouté récemment (notamment autour de Nuki), l’intégration MQTT pourrait être un peu plus lente à traiter les messages. Si votre configuration envoie des messages à haute fréquence, Gladys pourrait ne pas suivre, entraînant une accumulation de messages en file d’attente et une augmentation de l’utilisation du processeur. Si c’est le cas, la solution serait probablement d’optimiser le traitement MQTT dans Gladys pour améliorer le débit. Indiquez-moi le volume de messages, cela aiderait à cerner le problème ! ---
**Author:** ![bamboleate](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bamboleate/32/20501_2.png) [@bamboleate](https://community.gladysassistant.com/u/bamboleate)\ **Post date:** [Mars 22, 2026, 5:06 UTC](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126/20 "2026-03-22T17:06:30Z")
Salut @Pierre-Gilles, J’ai mesuré le taux de messages MQTT en utilisant `mosquitto_sub -t '#'` en le passant dans `pv` : **~0.8 messages/seconde** (291 messages sur ~6 minutes, tous topics confondus) Cela me semble bas, donc je ne pense pas que le débit soit le problème. L’utilisation CPU élevée (~60–70%) est constante et ne corrèle pas avec des pics de messages. Pour référence, ma configuration publie les états des relais depuis trois Raspberry Pis (WoZiPi et AZiPi, SchlaZiPi) ainsi que des données des capteurs BME680 et SHT35 — rien de particulièrement bavard. [Page suivante](https://community.gladysassistant.com/t/titel-high-cpu-usage-60-with-v4-70-0-fixed-by-downgrading-to-v4-66-8/10126.md?page=2)