Mqtt Discovery ne remonte pas les informations

[xavax59]

Bonjour,
Je fais suite a mon dernier post qui a été clôturé…

Configuration du broker du smhub nano

Bonjour, J’ai migré mon jeedom sur une VM en Debian 12, et depuis je n’ai plus les retour d’état de mes équipements. Plus rien ne remonte pourtant les appareils n’appariassent pas hors ligne. JE peux passer les action mais le problème est sur le retour d’état. Je ne sais pas quoi donner comme log du coup j’ai mis en Debug mais ils sont trop lourd pour faire un copier coller. voici ma page santé [image] [image] J’ai testé dans HA et ca fonctionne les capteurs remontent bien. j’ai redémar…

car j’ai toujours le même problème et je voudrais trouver une solution.

C’est toujours la même histoire, je peux envoyer les actions mais je ne reçois plus les états…

J’a fait plein de teste et sur les conseils d’Akenad j’ai tout basculé sur le broker du smlight nano MG24 . Depuis 2 jours ca tourne, ce matin j’ai redémarré un switch et depuis le problème est revenu .
J’a rebooté vers 8h45
Log demon

[2026-09-22 19:22:14] INFO  : Successfully subscribed to Myfox2mqtt
[2026-09-22 19:22:35]WARNING : Unexpected disconnection from MQTT
[2026-09-22 19:22:36] INFO  : Successfully connected to MQTT server
[2026-09-22 19:22:36] INFO  : Successfully subscribed to discovery topic homeassistant
[2026-09-22 19:22:36] INFO  : Successfully subscribed to zigbee2mqtt_Nano
[2026-09-22 19:22:36] INFO  : Successfully subscribed to myfox2mqtt
[2026-09-22 19:22:36] INFO  : Successfully subscribed to Myfox2mqtt
[2026-09-22 19:25:44] INFO  : Signal 15 caught, exiting...
[2026-09-22 19:25:44] INFO  : Cancelling 4 tasks
[2026-09-22 19:25:44] INFO  : Listening cancelled
[2026-09-22 19:25:44] INFO  : Send async cancelled
[2026-09-22 19:25:44] INFO  : Shutdown
[2026-09-22 19:25:48] INFO  : Starting daemon (lib version 1.2.9) with log level: info
[2026-09-22 19:25:48] INFO  : Listening on 127.0.0.1:55074
[2026-09-22 19:25:48] INFO  : Send async started with a cycle of 0.5s
[2026-09-22 19:25:48] INFO  : Successfully connected to MQTT server
[2026-09-22 19:25:48] INFO  : Successfully subscribed to discovery topic homeassistant
[2026-09-22 19:25:48] INFO  : Successfully subscribed to Myfox2mqtt
[2026-09-22 19:25:48] INFO  : Successfully subscribed to myfox2mqtt
[2026-09-22 19:25:48] INFO  : Successfully subscribed to zigbee2mqtt_Nano
[2026-09-24 08:45:32]WARNING : Unexpected disconnection from MQTT
[2026-09-24 08:45:32]WARNING : Unexpected disconnection from MQTT
[2026-09-24 08:49:54] INFO  : Successfully connected to MQTT server
[2026-09-24 08:49:54] INFO  : Successfully subscribed to discovery topic homeassistant
[2026-09-24 08:49:54] INFO  : Successfully subscribed to Myfox2mqtt
[2026-09-24 08:49:54] INFO  : Successfully subscribed to myfox2mqtt
[2026-09-24 08:49:54] INFO  : Successfully subscribed to zigbee2mqtt_Nano
[2026-09-24 08:54:55]WARNING : Timeout on send request to jeedom
[2026-09-24 08:59:56]WARNING : Timeout on send request to jeedom
[2026-09-24 09:04:57]WARNING : Timeout on send request to jeedom
[2026-09-24 09:09:58]WARNING : Timeout on send request to jeedom
[2026-09-24 09:14:59]WARNING : Timeout on send request to jeedom
[2026-09-24 09:20:00]WARNING : Timeout on send request to jeedom
[2026-09-24 09:25:01]WARNING : Timeout on send request to jeedom
[2026-09-24 09:30:02]WARNING : Timeout on send request to jeedom
[2026-09-24 09:35:03]WARNING : Timeout on send request to jeedom
[2026-09-24 09:40:04]WARNING : Timeout on send request to jeedom
[2026-09-24 09:45:05]WARNING : Timeout on send request to jeedom
[2026-09-24 09:50:06]WARNING : Timeout on send request to jeedom
[2026-09-24 09:55:07]WARNING : Timeout on send request to jeedom
[2026-09-24 10:00:08]WARNING : Timeout on send request to jeedom
[2026-09-24 10:05:09]WARNING : Timeout on send request to jeedom
[2026-09-24 10:10:10]WARNING : Timeout on send request to jeedom
[2026-09-24 10:15:11]WARNING : Timeout on send request to jeedom
[2026-09-24 10:20:12]WARNING : Timeout on send request to jeedom
[2026-09-24 10:25:13]WARNING : Timeout on send request to jeedom
[2026-09-24 10:30:14]WARNING : Timeout on send request to jeedom
[2026-09-24 10:35:15]WARNING : Timeout on send request to jeedom
[2026-09-24 10:40:16]WARNING : Timeout on send request to jeedom
[2026-09-24 10:45:17]WARNING : Timeout on send request to jeedom
[2026-09-24 10:50:18]WARNING : Timeout on send request to jeedom
[2026-09-24 10:55:19]WARNING : Timeout on send request to jeedom
[2026-09-24 11:00:20]WARNING : Timeout on send request to jeedom
[2026-09-24 11:05:21]WARNING : Timeout on send request to jeedom
[2026-09-24 11:10:22]WARNING : Timeout on send request to jeedom
[2026-09-24 11:15:23]WARNING : Timeout on send request to jeedom
[2026-09-24 11:20:24]WARNING : Timeout on send request to jeedom
[2026-09-24 11:25:25]WARNING : Timeout on send request to jeedom
[2026-09-24 11:30:26]WARNING : Timeout on send request to jeedom
[2026-09-24 11:35:27]WARNING : Timeout on send request to jeedom
[2026-09-24 11:40:28]WARNING : Timeout on send request to jeedom
[2026-09-24 11:45:29]WARNING : Timeout on send request to jeedom
[2026-09-24 11:50:30]WARNING : Timeout on send request to jeedom
[2026-09-24 11:55:31]WARNING : Timeout on send request to jeedom
[2026-09-24 12:00:32]WARNING : Timeout on send request to jeedom
[2026-09-24 12:05:33]WARNING : Timeout on send request to jeedom
[2026-09-24 12:10:34]WARNING : Timeout on send request to jeedom
[2026-09-24 12:15:35]WARNING : Timeout on send request to jeedom
[2026-09-24 12:20:36]WARNING : Timeout on send request to jeedom
[2026-09-24 12:25:37]WARNING : Timeout on send request to jeedom
[2026-09-24 12:30:38]WARNING : Timeout on send request to jeedom
[2026-09-24 12:35:39]WARNING : Timeout on send request to jeedom
[2026-09-24 12:40:40]WARNING : Timeout on send request to jeedom
[2026-09-24 12:45:41]WARNING : Timeout on send request to jeedom
[2026-09-24 12:50:42]WARNING : Timeout on send request to jeedom
[2026-09-24 12:55:43]WARNING : Timeout on send request to jeedom
[2026-09-24 13:00:44]WARNING : Timeout on send request to jeedom
[2026-09-24 13:05:45]WARNING : Timeout on send request to jeedom
[2026-09-24 13:10:46]WARNING : Timeout on send request to jeedom
[2026-09-24 13:15:47]WARNING : Timeout on send request to jeedom
[2026-09-24 13:20:48]WARNING : Timeout on send request to jeedom
[2026-09-24 13:25:49]WARNING : Timeout on send request to jeedom
[2026-09-24 13:30:50]WARNING : Timeout on send request to jeedom
[2026-09-24 13:35:51]WARNING : Timeout on send request to jeedom
[2026-09-24 13:40:52]WARNING : Timeout on send request to jeedom
[2026-09-24 13:45:53]WARNING : Timeout on send request to jeedom
[2026-09-24 13:50:54]WARNING : Timeout on send request to jeedom
[2026-09-24 13:55:55]WARNING : Timeout on send request to jeedom
[2026-09-24 14:00:56]WARNING : Timeout on send request to jeedom
[2026-09-24 14:05:57]WARNING : Timeout on send request to jeedom
[2026-09-24 14:10:58]WARNING : Timeout on send request to jeedom
[2026-09-24 14:15:59]WARNING : Timeout on send request to jeedom
[2026-09-24 14:21:00]WARNING : Timeout on send request to jeedom
[2026-09-24 14:26:01]WARNING : Timeout on send request to jeedom
[2026-09-24 14:31:02]WARNING : Timeout on send request to jeedom
[2026-09-24 14:36:03]WARNING : Timeout on send request to jeedom

Log Mqtt discovery

[2026-09-24 14:46:30]WARNING Component event not yet supported: {"availability":[{"topic":"zigbee2mqtt_Nano\/bridge\/state","value_template":"{{ value_json.state }}"},{"topic":"zigbee2mqtt_Nano\/Bouton Ikea Ch Verte\/availability","value_template":"{{ value_json.state }}"}],"availability_mode":"all","default_entity_id":"event.bouton_ikea_ch_verte_action","device":{"hw_version":1,"identifiers":["zigbee2mqtt_0x000d6ffffee84181"],"manufacturer":"IKEA","model":"TRADFRI on\/off switch","model_id":"E1743","name":"Bouton Ikea Ch Verte","sw_version":"2.3.079","via_device":"zigbee2mqtt_bridge_0xbc8d7efffe2638bb"},"event_types":["on","off","brightness_move_up","brightness_move_down","brightness_stop"],"icon":"mdi:gesture-double-tap","name":"Action","object_id":"bouton_ikea_ch_verte_action","origin":{"name":"Zigbee2MQTT","sw":"2.13.0","url":"https:\/\/www.zigbee2mqtt.io"},"state_topic":"zigbee2mqtt_Nano\/Bouton Ikea Ch Verte","unique_id":"0x000d6ffffee84181_action_zigbee2mqtt_Nano","value_template":"{% set patterns = [\n{\"pattern\": '^(?P<button>(?:button_)?[a-z0-9]+)_(?P<action>(?:press|hold)(?:_release)?)$', \"groups\": [\"button\", \"action\"]},\n{\"pattern\": '^(?P<action>recall|scene)_(?P<scene>[0-2][0-9]{0,2})$', \"groups\": [\"action\", \"scene\"]},\n{\"pattern\": '^(?P<actionPrefix>region_)(?P<region>[1-9]|10)_(?P<action>enter|leave|occupied|unoccupied)$', \"groups\": [\"actionPrefix\", \"region\", \"action\"]},\n{\"pattern\": '^(?P<action>dial_rotate)_(?P<direction>left|right)_(?P<speed>step|slow|fast)$', \"groups\": [\"action\", \"direction\", \"speed\"]},\n{\"pattern\": '^(?P<action>brightness_step)(?:_(?P<direction>up|down))?$', \"groups\": [\"action\", \"direction\"]}\n] %}\n{% set action_value = value_json.action|default('') %}\n{% set ns = namespace(r=[('action', action_value)]) %}\n{% for p in patterns %}\n  {% set m = action_value|regex_findall(p.pattern) %}\n  {% if m[0] is undefined %}{% continue %}{% endif %}\n  {% for key, value in zip(p.groups, m[0]) %}\n    {% set ns.r = ns.r|rejectattr(0, 'eq', key)|list + [(key, value)] %}\n  {% endfor %}\n{% endfor %}\n{% if (ns.r|selectattr(0, 'eq', 'actionPrefix')|first) is defined %}\n  {% set ns.r = ns.r|rejectattr(0, 'eq', 'action')|list + [('action', ns.r|selectattr(0, 'eq', 'actionPrefix')|map(attribute=1)|first + ns.r|selectattr(0, 'eq', 'action')|map(attribute=1)|first)] %}\n{% endif %}\n{% set ns.r = ns.r + [('event_type', ns.r|selectattr(0, 'eq', 'action')|map(attribute=1)|first)] %}\n{{dict.from_keys(ns.r|rejectattr(0, 'in', ('action', 'actionPrefix'))|reject('eq', ('event_type', None))|reject('eq', ('event_type', '')))|to_json}}"}

cette partie log qui ne représente qu’une seule ligne. et j’ai remarqué que lorsque j’avais le probleme j’avais des timeout dans le log démon et cette ligne qui apparait a plusieurs reprises…

J’arrive a tout faire repartir en changeant de broker mais pas un broker qu’il a déjà utilisé… il faut carrément que je reparte sur un broker vierge…

Je ne sais pas si ces infos vont pouvoir aider.
Merci d’avance pour votre aide

[akenad]

Bonjour,

@xavax59

WARNING Component event not yet supported

Déjà je constate que dans la configuration smhub zigbee2mqtt tu persistes à activer HA Settings et Experimental Events,
alors que ce n’est pas supporté dans le plugin mqttdiscovery.

Ce qui a déjà été dit dans le sujet que tu cites en référence : « Configuration du broker du smhub nano » :

@Mips

je gère pas les events car comme indiqué c’est « expérimental »

@akenad

je te conseille de ne pas mettre HA dans l’équation pour l’instant.

akenad

[xavax59]

Ok je vais essayé de ne pas mettre HA dans l’équation mais j’ai des automatisations aussi dessus…
et je le répète ce fonctionnait avant avec les cases cochées… je vais voir ce que ca implique de désactiver ces options pour Ha…

autre point, je coupe HA… je relance Jeedom et la ca fonctionne au bout de 5mn le temps que je plug in fasse les découverte. je remets HA ca fonctionne toujours…

[Mips]

Je complète avec un autre point que j’ai déjà mentionné: si tu me donnes un log, il doit être le plus complet possible, au format texte et surtout il faut que les heures concordes sinon c’est impossible de corréler les données; tu me donnes:

• un log démon avec plein de timeout entre 8h54 & 14h36
• un log du plugin avec UNE seule ligne à 14h46

qu’est-ce qu’on peut faire avec ça?

[xavax59]

Ok sauf les lignes ont trop de caractères pour poser les logs ici. je vais voir ce que je peux faire.
j’ai activé la persistance du cache sur le broker du nano qui ne l’était pas.

[akenad]

@xavax59

et je le répète

« Ce qui se conçoit bien s’énonce clairement ». Nicolas Boileau.
Si c’est le cas, il est inutile de se répéter.

@xavax59

j’ai activé la persistance du cache sur le broker du nano qui ne l’était pas.

ça c’est nouveau.
Tu pourrais décrire comment tu as fais ?

akenad

[xavax59]

J’ai fait ceci avec Claude

ACTIVER LA PERSISTANCE (CACHE) DE MOSQUITTO SUR LE SMHUB NANO

But : que le broker Mosquitto du Nano garde les messages retenus
(decouverte Z2M, disponibilite, bridge/state) apres un redemarrage.

Dans le terminal web du SMHUB, coller UNE commande a la fois.
sudo demande le mot de passe de l’utilisateur smlight.

1. Sauvegarde de la config

sudo cp /etc/mosquitto/mosquitto.conf /etc/mosquitto/mosquitto.conf.bak

2. Activation (la ligne « #persistence false » devient « persistence true »)

sudo sed -i ‹ s/^#persistence false/persistence true/ › /etc/mosquitto/mosquitto.conf

3. Verification (doit afficher « persistence true »)

grep -n ‹ ^persistence › /etc/mosquitto/mosquitto.conf

4. Redemarrage de Mosquitto

sudo /etc/init.d/mosquitto restart

5. Redemarrer Zigbee2MQTT depuis son interface
   (Parametres → Outils → Redemarrer) pour qu’il republie tout.

[akenad]

Sur le smhub, pour gérer proprement le démon/service MQTT (Mosquitto) :

smlight@SMHUB:~$ su -
Password: smlight
root@SMHUB:~# rc-service mosquitto status
 * status: started
root@SMHUB:~# rc-service mosquitto stop
 * Stopping mosquitto ...                                                                                                                   [ ok ]
root@SMHUB:~# rc-service mosquitto start
 * Starting mosquitto ...                                                                                                                   [ ok ]
root@SMHUB:~# rc-service mosquitto restart
 * Stopping mosquitto ...                                                                                                                   [ ok ]
 * Starting mosquitto ...                                                                                                                   [ ok ]
root@SMHUB:~# rc-service mosquitto status
 * status: started

akenad

[xavax59]

va matin j’ai essayé de reproduire le probleme. et j’ai réussi a faire repartir avec Claude en faisant des test et lui fournissant des loigs.
voici un résumé de ce que j’ai fait et des conclusion que l’IA donne

DIAGNOSTIC — MQTT Discovery (Jeedom) : plus de retours d’état après une reconnexion MQTT

1. CONFIGURATION

---

• Broker : Mosquitto 2.1.2 intégré au SMHUB Nano (SMHUB-OS, OpenRC)
• Zigbee2MQTT 2.13.0 sur le Nano (base_topic zigbee2mqtt_Nano, ~79 appareils),
  intégration Home Assistant activée
• Jeedom sur VM Debian 12 (Proxmox), plugin MQTT Discovery (lib 1.2.9)
  Topics écoutés : homeassistant (découverte), zigbee2mqtt_Nano, myfox2mqtt, Myfox2mqtt
• Home Assistant connecté au même broker

2. SYMPTÔME

---

Après une coupure réseau (redémarrage d’un switch) ou un redémarrage du broker :

• les actions Jeedom → appareils fonctionnent ;
• plus aucun retour d’état dans Jeedom ;
• log du démon : « Timeout on send request to jeedom » toutes les 5 minutes, indéfiniment.

3. TESTS RÉALISÉS

---

a) Persistance du broker

• Mosquitto du Nano : persistance désactivée par défaut (#persistence false commenté)
  → messages retenus (découverte, disponibilité, bridge/state) perdus à chaque
  redémarrage du broker. HA ET Jeedom perdaient leurs entités jusqu’au
  redémarrage de Z2M.
• Ancien broker EMQX : retainer en storage_type = ram → même défaut.
• Correctif appliqué : « persistence true » dans /etc/mosquitto/mosquitto.conf.
• Résultat : après un « rc-service mosquitto restart », HA récupère tout
  instantanément. Jeedom reste bloqué → le problème restant est côté plugin.

b) Éliminations côté Jeedom (pendant le blocage)

• Charge CPU : aucun processus chargé (ps aux --sort=-%cpu)
• MariaDB : aucune requête bloquée (SHOW FULL PROCESSLIST : tout en Sleep)
• Apache : répond en 0,0005 s, 14 processus, error.log vide
• Redémarrage du démon seul : ne débloque pas
• Redémarrage d’Apache : ne débloque pas
• Redémarrage de Z2M : ne débloque pas
• Redémarrage de la VM Jeedom (HA éteint) : ne débloque plus depuis que le
  broker est persistant

c) Logs en Debug → cause identifiée (voir section 4)

4. CAUSE IDENTIFIÉE

---

À la connexion, le broker renvoie d’un coup tous les messages retenus. Le démon
les regroupe dans UNE SEULE requête HTTP vers Jeedom, d’environ 1,6 Mo :

homeassistant/… (≈765 configs de découverte) 728 Ko
zigbee2mqtt_Nano/bridge/definitions 517 Ko
zigbee2mqtt_Nano/bridge/devices 295 Ko
zigbee2mqtt_Nano/bridge/info + health 43 Ko
états des appareils + myfox quelques Ko
TOTAL ≈ 1,6 Mo

La partie PHP met environ 4 minutes à importer les configs (démon démarré à
09:03:10, résumé « Nouvelle découverte » à 09:07:06), puis doit encore traiter le
reste. Le démon abandonne à 5 minutes (Timeout à 09:08:11) et RENVOIE LE PAQUET
ENTIER, un peu plus gros à chaque fois → la requête ne passe jamais, aucun état
n’est mis à jour.

Ça explique aussi pourquoi un broker vide « réparait » : les messages arrivent
alors petit à petit, par petits paquets, et Jeedom les traite sans problème.

Note : supprimer seulement bridge/definitions et bridge/devices (≈800 Ko) n’a
pas suffi.

5. EXTRAITS DE LOGS (niveau Debug)

---

Démon :
[2026-09-28 08:46:08][DEBUG] : Try sending to jeedom: {'homeassistant': {...}, 'myfox2mqtt': {...}, 'zigbee2mqtt_Nano': {'bridge': {'definitions': ..., 'devices': ...}}}   (≈1 592 000 caractères)
[2026-09-28 08:46:59][DEBUG] : Try sending to jeedom: ... (≈1 588 000 caractères)
[2026-09-28 08:52:00][DEBUG] : Try sending to jeedom: ... (≈1 612 000 caractères)
[2026-09-28 08:57:01][DEBUG] : Try sending to jeedom: ... (≈1 612 000 caractères)
[2026-09-28 09:02:02][WARNING] : Timeout on send request to jeedom
[2026-09-28 09:02:02][DEBUG] : Try sending to jeedom: ... (≈1 612 000 caractères)

Démarrage de 09:03 :
[2026-09-28 09:03:10][INFO] : Successfully subscribed to zigbee2mqtt_Nano
[2026-09-28 09:08:11][WARNING] : Timeout on send request to jeedom

Plugin (même démarrage) :
[2026-09-28 09:07:06][INFO] Nouvelle découverte, résumé des configuations:
[2026-09-28 09:07:06][INFO] - Total reçues:              765

Pendant le blocage, le démon reçoit pourtant bien les états, par exemple :
[2026-09-28 09:02:42][DEBUG] : message received on topic 'zigbee2mqtt_Nano/Prise Dyson': b'{...}'

6. REMISE EN ROUTE (contournement)

---

Principe : faire démarrer le démon sur un broker VIDE, puis laisser Z2M
republier petit à petit.

1. Jeedom : arrêter le démon MQTT Discovery
2. SMHUB : sudo rc-service mosquitto stop
3. SMHUB : sudo mv /var/lib/mosquitto/mosquitto.db /var/lib/mosquitto/mosquitto.db.old
4. SMHUB : sudo rc-service mosquitto start (broker vide)
5. Jeedom : démarrer le démon, attendre 1 minute
6. Z2M : Paramètres → Outils → Redémarrer
7. Attendre ~5 minutes, vérifier les retours d’état (pas de Timeout)
8. Vérifier les autres publieurs MQTT (Nuki, Myfox2mqtt…) et les redémarrer si
   leurs entités manquent

Annulation :
sudo rc-service mosquitto stop
sudo mv /var/lib/mosquitto/mosquitto.db.old /var/lib/mosquitto/mosquitto.db
sudo rc-service mosquitto start

7. PISTES DE CORRECTION POUR LE PLUGIN

---

• Découper les envois vers Jeedom (par nombre de messages ou par taille)
• Après un timeout, ne pas renvoyer le paquet entier cumulé
• Ignorer <base_topic>/bridge/# (definitions, devices, info, health, logging),
  inutiles pour Jeedom et très volumineux
• Éventuellement, allonger le timeout ou traiter la découverte de façon asynchrone

[Mips]

Curieux que lorsque tu avais un mqtt en local géré par mqtt manager tu n’avais pas le problème… il en pense quoi ton pote?

[xavax59]

j’avais le même probleme. En fait ca marche jusqu’à la prochaine coupure du broker même en local

[Mips]

je n’ai jamais vu cette info… peux-tu me donner le lien vers le post ou tu signales cela?

[xavax59]

Configuration du broker du smhub nano

petit retour sur mon problème de base avec mqtt dsicovery avec les actions qui passent mais sans retour d’état. depuis que je me suis amusé a changer de broker en local c’est revenu, depuis 4 jours ca tourne sans problème. Ce soir je mets la beta qui apporte pas mal de changement est depuis je suis revenu au meme problème… action Ok mais pas d’état. Concernant le nano je n’ai pas essayé de tout mettre dessus pour l’instant j’essaye de comprendre pourquoi j’ai ce problème avant de tout modifier. …

Si je pars sur un broker neuf ca repart a chaque fois. mais ca ne tient pas s’il y a une coupure du broker, qu’elle soit réseau, ou le broker lui même qui redémarre

[Mips]

tu as configuré un cycle particulier sur le démon? (config plugin)
quelle valeur as-tu?

[xavax59]

j’ai laissé par défaut

[Mips]

Pourrais-tu, dans cette ordre et sans rien oublier:

1. stopper le démon et stopper le démarrage auto le temps du test
2. vider les 2 logs: démon & plugin
3. passer le loglevel en mode INFO & sauvegarder la config
4. aller dans l’administration système Jeedom (ou en ssh avec sudo) et executer cette commande:

/var/www/html/plugins/MQTTDiscovery/resources/venv/bin/pip install --force-reinstall --no-deps "https://github.com/Mips2648/jeedom-daemon-py/archive/refs/heads/feat/batch-changes-per-cycle.zip"

Cela va installer une pré-version du démon qui se chargera de limiter la taille des payloads envoyés vers jeedom.

5. Copier les logs d’installation et me les donner dans une réponse ici avec bloc Texte préformaté
6. ne continuer les étapes ci-dessous que si tu vois la dernière ligne « Successfully installed jeedomdaemon-2.0.0 »
7. démarrer le démon => si j’ai bien compris cela va causer ton soucis
8. attendre quelques minutes le temps que la queue d’info à traiter suite au démarrage se vide
9. me montrer les 2 logs démons et plugin (dans un bloc Texte préformaté)

Avec ca on verra si c’était effectivement la cause et si cette nouvelle version permet de régler le problème.

Et s’il te plait, si quoi que ce soit ne se déroule pas comme prévu, ne fais rien ne testes pas plein d’autres combinaisons, expliques moi d’abord.

[xavax59]

root@jeedom:~# /var/www/html/plugins/MQTTDiscovery/resources/venv/bin/pip install --force-reinstall --no-deps "https://github.com/Mips2648/jeedom-daemon-py/archive/refs/heads/feat/batch-changes-per-cycle.zip"
Collecting https://github.com/Mips2648/jeedom-daemon-py/archive/refs/heads/feat/batch-changes-per-cycle.zip
  Downloading batch-changes-per-cycle.zip
     - 25.1 kB 427.5 kB/s 0:00:00
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: jeedomdaemon
  Building wheel for jeedomdaemon (pyproject.toml) ... done
  Created wheel for jeedomdaemon: filename=jeedomdaemon-2.0.0-py3-none-any.whl size=12953 sha256=bc8087dd5c015cd00832db707d61f24ef080f076af9e746436d9b4b2b174c255
  Stored in directory: /root/.cache/pip/wheels/b7/2f/e0/7da93fa24c07ba58d7a76e5eaa950c9243ece32a1bd2fd1221
Successfully built jeedomdaemon
Installing collected packages: jeedomdaemon
  Attempting uninstall: jeedomdaemon
    Found existing installation: jeedomdaemon 1.2.9
    Uninstalling jeedomdaemon-1.2.9:
      Successfully uninstalled jeedomdaemon-1.2.9
Successfully installed jeedomdaemon-2.0.0
root@jeedom:~# 

[2026-09-28 14:19:34] INFO  Lancement démon
[2026-09-28 14:19:35] INFO  Nouvelle découverte, résumé des configuations:
[2026-09-28 14:19:35] INFO  - Importées:                 0
[2026-09-28 14:19:35] INFO  - Auto-création inactive:    0
[2026-09-28 14:19:35] INFO  - Topic ignoré:              9
[2026-09-28 14:19:35] INFO  - Erronées:                  0
[2026-09-28 14:19:35] INFO  - Non supportées:            0
[2026-09-28 14:19:35] INFO  - Total reçues:              9

[2026-09-28 14:19:34] INFO  : Starting daemon (lib version 2.0.0) with log level: info
[2026-09-28 14:19:34] INFO  : Listening on 127.0.0.1:55074
[2026-09-28 14:19:34] INFO  : Send async started with a cycle of 0.5s
[2026-09-28 14:19:34] INFO  : Successfully connected to MQTT server
[2026-09-28 14:19:34] INFO  : Successfully subscribed to discovery topic homeassistant
[2026-09-28 14:19:34] INFO  : Successfully subscribed to zigbee2mqtt_Nano
[2026-09-28 14:19:34] INFO  : Successfully subscribed to Myfox2mqtt
[2026-09-28 14:19:34] INFO  : Successfully subscribed to myfox2mqtt

J’ai suivi pas à pas.

Pour reproduire le probleme un rebut de Jeedom peut suffire mais c’est surtout lorsque je rebut le broker ou qu’on switch coupe le réseau pour se mettre a jour.

Avec cette mise a jour je n’ai plus le timeout. mais je n’ai pas le retour d’état des prises par exemple. Le probleme semble identique mais je pense que si je relance Z2M ca va repartir. Je ne l’ai pas fait j’attends les instructions.
J’ai attendu 10mn pour être sur d’avoir attendu assez

[Mips]

Ici c’est un autre « problème » je pense, car tu n’as pas le timeout.

On va se concentrer sur le problème de timeout;

tu me dis maintenant que cela se produit au démarrage du broker ou de zigbee2mqtt mais avant tu disais que faire ces actions permettait de « remettre en route en cas de problème », ce n’est pas cohérent.

@xavax59

• SMHUB : sudo rc-service mosquitto stop
• SMHUB : sudo mv /var/lib/mosquitto/mosquitto.db /var/lib/mosquitto/mosquitto.db.old
• SMHUB : sudo rc-service mosquitto start (broker vide)
• Jeedom : démarrer le démon, attendre 1 minute
• Z2M : Paramètres → Outils → Redémarrer

du coup comment reproduis-tu? et comment contournes-tu le problème actuellement?

[xavax59]

Quand ça bloque (timeout) : quand le démon démarre ou se reconnecte à un broker qui contient déjà tous les messages retenus. Concrètement : redémarrage du démon, reboot de Jeedom, coupure réseau (switch), ou redémarrage du broker.

Comment je contourne : je fais démarrer le démon sur un broker vide, puis je redémarre Z2M pour qu’il republie pendant que le démon est déjà connecté :

1. arrêt du démon
2. rc-service mosquitto stop, je mets mosquitto.db de côté, rc-service mosquitto start (broker vide)
3. démarrage du démon
4. redémarrage de Z2M → la découverte arrive par lots et ça fonctionne.

[Mips]

@xavax59

quand le démon démarre ou se reconnecte à un broker qui contient déjà tous les messages retenus

Ici c’est ce que tu viens de faire non?

tu me confirmes que tu redémarres le broker pour qu’il soit « vide » mais juste avant tu écris:

@xavax59

mais c’est surtout lorsque je reboot le broker