Tiens-moi au courant dès que tu fais d’autres tests, ou si tu vois qu’il manque des fonctions.
Hello @Will_71
Merci pour cette nouvelle intégration, c’est trop bien de pouvoir intégrer ces devices à Gladys.
J’ai tenté un capteur millimétrique sur un ESP32-C3 Supermini.
ça a été détecté du 1er coup 
Beaucoup de fonctionnalités :
Globalement, tout fonctionne. C’est juste dommage que certaines fonctionnalités sont listées comme inconnu mais je suppose que c’est plus lié au coeur ? Voici à quoi ça ressemble sur le dashboard (extrait) :
Dans les logs je vois 2 problèmes :
Cette première erreur est spammée avec toujours les mêmes données affichées et rien qui permette de voir d’où ça vient.
[2026-08-24T18:27:32.834Z] [WARN] Publishing a state of "capteur-millimetrique" failed: states[0]: must have a numeric "state" or a string "text"
L’autre problème semble indiquer un volume trop important de données mises à jour ?
[2026-08-24T18:00:24.842Z] [WARN] Publishing a state of "capteur-millimetrique" failed: Too Many Requests
Est-ce que tu pourrais me dire à quoi correspondent les fonctionnalités inconnues, cela permettrait peut-être de les intégrer dans le core.
Pour les logs, je regarde dès que je peux et je te tiens au courant.
Je te remercie pour ces tests.
Il s’agit de 2 types de fonctionnalités :
- Compteurs entier, ex. :
- Capteur millimétrique (Moving Target Count) = 1
- Capteur millimétrique (Presence Target Count) = 1
- Capteur millimétrique (Still Target Count) = 1
- Capteurs d’angle, ex. :
- Capteur millimétrique (Target-1 Angle) = -11.809355735778809 °
L’integration va arriver sur le store.
J’ai corriger les points des logs mais j’ai besoin de voir comment gérer les fonctionnalités en inconnu.
Edit: j’ai intégrer les fonctionnalités inconnu. Dispo dans l’intégration EspHome v1.0.2
Hello,
Je suis en train de bidouiller mon détecteur de mouvements millimétrique à base de LD2410C.
Ce type de capteur est capable de détecter une présence même si la « target » est immobile. C’est hyper intéressant pour allumer/éteindre des lumières.
j’aurais besoin de votre aide pour l’utiliser. En effet, les différentes fonctionnalités sont détectées comme des fonctionnalités « présence » et « mouvement ».
Voici une comparaison de l’interprétation entre Gladys et HA :
Est-ce que Gladys interprète bien les données transmises ? La fonctionnalité présence est liée à un utilisateur de Gladys, il me semble, donc impossible à utiliser dans des scènes pour de la détection de mouvements (ça ne fait qu’envoyer des 1 à chaque mouvement détecté). Quant à la fonctionnalité « mouvement », ça ne change jamais de valeur sous Gladys alors que je la vois bien changer sous HA 
Sous ESPHome, ces fonctionnalités sont déclarées comme des « Binary_sensor ».
Je regarde dès que je peux. Je te tiens au courant
J’ai fait un fix, une mise à jour de l’intégration sera bientôt disponible.
Important, il faudra surement que tu supprimes l’appareil déjà créé et le remettre ensuite.
Tiens moi au courant
Bonjour @Will_71
Merci pour la correction !
Il y a du mieux, les fonctionnalités sont déclarées comme il faut sur Gladys :
A l’initialisation, toutes les fonctionnalités sont correctement mises à jour (présence détectée, mouvement détecté) ; en revanche, quand il n’y a plus de mouvement la fonctionnalité reste à « Mouvement détecté » et idem pour les fonctionnalités de présence qui reste « Présence détectée » malgré l’absence de target.
L’ESP envoie pourtant les changements d’état (logs ESP Home) :
[12:26:18.471][S][binary_sensor]: 'Presence' >> ON
[12:26:18.471][S][binary_sensor]: 'Has Target' >> ON
[12:26:18.471][S][binary_sensor]: 'Has Moving Target' >> ON
[12:26:18.472][S][binary_sensor]: 'Has Still Target' >> ON
[12:26:20.394][S][binary_sensor]: 'Has Moving Target' >> OFF
[12:26:28.178][S][binary_sensor]: 'Presence' >> OFF
[12:26:28.178][S][binary_sensor]: 'Has Target' >> OFF
[12:26:28.179][S][binary_sensor]: 'Has Still Target' >> OFF
[12:27:39.272][S][binary_sensor]: 'Presence' >> ON
[12:27:39.272][S][binary_sensor]: 'Has Target' >> ON
[12:27:39.273][S][binary_sensor]: 'Has Moving Target' >> ON
[12:27:39.755][S][binary_sensor]: 'Has Still Target' >> ON
[12:27:40.466][S][binary_sensor]: 'Has Moving Target' >> OFF
[12:27:43.749][S][binary_sensor]: 'Has Moving Target' >> ON
[12:27:48.360][S][binary_sensor]: 'Has Moving Target' >> OFF
[12:28:20.716][S][binary_sensor]: 'Presence' >> OFF
[12:28:20.716][S][binary_sensor]: 'Has Target' >> OFF
[12:28:20.716][S][binary_sensor]: 'Has Still Target' >> OFF
Merci pour tes tests, j’ai fais une autre correction.
Merci, ça fonctionne parfaitement !!
Bonjour,
J’ai débranché mon esp pendant quelques jours. Aujourd’hui, je décide de rebrancher.
L’ESP32 émet des données en temps réel (vu dans le terminal esphome) mais Gladys ne le vois plus. J’ai essayé de redémarrer l’intégration mais le résultat est le même.
Pour que ça refonctionne, j’ai dû :
- Forcer l’inscription de mon device dans les paramètres en indiquant sont adresse IP dans le champ « Nœuds ajoutés à la main » ;
- Redémarrer l’intégration.
A noter : mon ESP était enregistré dans Gladys (je n’y avais pas touché). Je constate que la détection d’un device est aléatoire, un coup il est identifié directement par Gladys sans rien paramétrer et un autre coup, pour le même device, il faut que j’ajoute le nœud à la main.
Les logs :
[2026-09-09T12:00:28.194Z] [WARN] [gladys-sdk] connection to Gladys lost (close code 1006)
[2026-09-09T12:00:28.194Z] [WARN] [gladys-sdk] not connected to Gladys (ws://172.30.0.1:80), retrying in 1000 ms (attempt 1)
[2026-09-09T12:00:28.195Z] [INFO] Received SIGTERM -> graceful shutdown
[2026-09-09T12:00:29.263Z] [INFO] Starting the ESPHome integration...
[2026-09-09T12:00:29.565Z] [INFO] [gladys-sdk] connected to Gladys (http://172.30.0.1:80)
[2026-09-09T12:00:39.678Z] [INFO] [esphome-devices] mDNS scan (_esphomelib._tcp): 0 ESPHome node(s) found
[2026-09-09T12:00:39.679Z] [INFO] [esphome-devices] ESPHome discovery: 0 device(s) built
[2026-09-09T12:08:48.478Z] [WARN] [gladys-sdk] connection to Gladys lost (close code 1006)
[2026-09-09T12:08:48.478Z] [WARN] [gladys-sdk] not connected to Gladys (ws://172.30.0.1:80), retrying in 1000 ms (attempt 1)
[2026-09-09T12:08:48.491Z] [INFO] Received SIGTERM -> graceful shutdown
[2026-09-09T12:08:49.371Z] [INFO] Starting the ESPHome integration...
[2026-09-09T12:08:49.756Z] [INFO] [gladys-sdk] connected to Gladys (http://172.30.0.1:80)
[2026-09-09T12:08:59.959Z] [INFO] [esphome-devices] mDNS scan (_esphomelib._tcp): 0 ESPHome node(s) found
[2026-09-09T12:08:59.959Z] [INFO] [esphome-devices] ESPHome discovery: 0 device(s) built
[2026-09-09T12:09:21.294Z] [INFO] onConfigUpdated -> reconnecting with the new configuration
[2026-09-09T12:09:26.820Z] [WARN] [gladys-sdk] connection to Gladys lost (close code 1006)
[2026-09-09T12:09:26.820Z] [WARN] [gladys-sdk] not connected to Gladys (ws://172.30.0.1:80), retrying in 1000 ms (attempt 1)
[2026-09-09T12:09:26.829Z] [INFO] Received SIGTERM -> graceful shutdown
[2026-09-09T12:09:27.672Z] [INFO] Starting the ESPHome integration...
[2026-09-09T12:09:28.048Z] [INFO] [gladys-sdk] connected to Gladys (http://172.30.0.1:80)
[2026-09-09T12:09:28.250Z] [INFO] [esphome-manager] Connecting to ESPHome node "192.168.50.50" (192.168.50.50:6053)
[2026-09-09T12:09:28.249Z] [WARN] [esphome-devices] mDNS scan unavailable: Conflict
[2026-09-09T12:09:36.517Z] [INFO] [esphome-manager] ESPHome node "192.168.50.50" reports its real name: "detecteur-mvts-millimetrique"
[2026-09-09T12:09:36.518Z] [INFO] ESPHome node "detecteur-mvts-millimetrique" is connected
[2026-09-09T12:09:36.526Z] [INFO] [esphome-devices] ESPHome discovery: 1 device(s) built
A disposition pour tout complément
Mise à jour 17:04 : j’ai demandé à Claude d’y réfléchir. J’ai un fichier patch qui a été généré mais je ne sais pas le mettre sur le forum, à ta dispo pour te le transmettre d’une autre manière.
Le bug principal
src/devices.js → discoverNodes() construit sa liste de nœuds à partir de deux sources seulement : les résultats du scan mDNS, et les nœuds saisis à la main. Les devices déjà créés dans Gladys ne sont jamais consultés.
C’est d’autant plus dommage que l’adresse est déjà stockée exactement pour ça. Dans buildDevice() :
js
params: [
// Keep the address to reconnect without waiting for a new scan
{ name: PARAM_ADDRESS, value: `${node.host}:${node.port}` },
Le commentaire décrit le comportement voulu… mais rien ne relit jamais ce param au démarrage. Même chose dans EsphomeManager : la map this.addresses (« so a reconnection does not depend on a fresh mDNS scan ») est écrite, renommée, supprimée — et jamais lue nulle part. Deux vestiges d’une intention non câblée.
Conséquence exacte de tes logs : 0 ESPHome node(s) found → 0 device(s) built → aucune connexion TCP ouverte → aucun état publié, alors que ton device existe toujours dans Gladys et que son IP est connue.
Le filet de sécurité censé rattraper ça (onPoll dans index.js, qui lit PARAM_ADDRESS) est du code mort : aucun poll_frequency n’est déclaré sur les features (modèle push assumé), donc Gladys ne poll jamais et ce handler n’est jamais appelé.
Les deux bugs secondaires
Le Conflict. C’est un 409 du core, EXTERNAL_INTEGRATION_SCAN_ALREADY_RUNNING : un seul scan à la fois par intégration. Ton onConfigUpdated à 12:09:21 lance un scan de 8 s, le conteneur est redémarré à 12:09:26, et le scan du nouveau process à 12:09:28 tombe pendant la fenêtre restante. Le garde inFlightScan est local au process et ne protège pas d’un redémarrage. L’erreur est avalée sans réessai.
Le silence sur les résultats partiels. parseMdnsResult() retourne null sans un seul log si le nœud n’a pas d’adresse IPv4 dans la réponse. Un PTR reçu mais sans enregistrement A donne donc le même 0 node(s) found qu’une absence totale de réponse — impossible à diagnostiquer.
Pourquoi c’est « aléatoire »
Le core envoie bien une requête PTR active (je suis allé voir networkDiscovery.scanMdns.js), mais mDNS reste du multicast best-effort : ESP32 en power save Wi-Fi, point d’accès qui filtre ou convertit le multicast, fenêtre de 8 s qui rate la réponse. Un scan qui échoue une fois sur trois est normal. Ce qui n’est pas normal, c’est qu’un échec de scan fasse disparaître un device déjà enregistré.
Le correctif
J’ai patché le dépôt, npm test passe (83/83) et eslint est propre. Trois changements :
knownNodes(gladys): nouvelle fonction qui relitPARAM_ADDRESSsur les devices existants, injectée en premier dansdiscoverNodes— un résultat de scan frais l’écrase (bail DHCP qui bouge), une saisie manuelle écrase tout.runScanWithRetry(): sur un 409, attente descan_duration + 2 spuis un réessai.- Un watchdog 60 s dans
index.jsqui reconnecte les nœuds connus sans session vivante — le cas où l’ESP était éteint au démarrage du conteneur, que la reconnexion auto d’esphome-clientne couvre pas (elle ne rattrape qu’une session déjà établie).
@Will_71, si je peux aider davantage pour la résolution n’hésite pas
Désolé mais j’ai repris le boulot, je peux regarder que les weekend maintenant.
@PhilippeMA, je viens de publier une correction, la mise à jour sera bientôt disponible dans le store. Sinon tu peux forcer la mise à jour!
Merci @Will_71, les premiers tests sont concluants :
- Connexion physique de la prise USB du capteur après mise à jour de l’intégration (avec l’ip forcée dans le champ « Nœuds ajoutés à la main ») : OK
- Suppression de l’adresse IP du champ « Nœuds ajoutés à la main » : le capteur se déconnecte après sauvegarde de la configuration et se reconnecte rapidement : OK
- Déconnexion physique de la prise USB du capteur USB puis reconnexion (ie. avec champ « Nœuds ajoutés à la main » vide) : OK
Les reconnexions à Gladys sont quasi immédiates, nickel !
Je vais poursuivre les tests et voir ce que je peux monter comme autre appareil aussi.
Merci encore d’avoir créer cette intégration, ça ouvre beaucoup portes. J’adore
Si tu as d’autres bugs ou d’autres ajouts à faire, n’hésite pas.