Manténme informado en cuanto hagas más pruebas, o si ves que faltan funciones.
Hola @Will_71
Gracias por esta nueva integración, es genial poder integrar estos dispositivos en Gladys.
He probado un sensor milimétrico en un ESP32-C3 Supermini.
Fue detectado a la primera 
Muchas funcionalidades:
En general, todo funciona. Es una pena que algunas funcionalidades estén listadas como desconocidas, pero supongo que está más relacionado con el núcleo. Así es como se ve en el panel (extracto):
En los registros veo 2 problemas:
Este primer error se repite con los mismos datos mostrados y nada que permita ver de dónde viene.
[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"
El otro problema parece indicar un volumen demasiado grande de datos actualizados?
[2026-08-24T18:00:24.842Z] [WARN] Publishing a state of "capteur-millimetrique" failed: Too Many Requests
¿Podrías decirme a qué corresponden las funciones desconocidas? Quizás podríamos integrarlas en el núcleo.
En cuanto a los registros, los reviso en cuanto pueda y te aviso.
Gracias por estas pruebas.
Se trata de 2 tipos de características:
- Contadores enteros, ej.:
- Sensor milimétrico (Moving Target Count) = 1
- Sensor milimétrico (Presence Target Count) = 1
- Sensor milimétrico (Still Target Count) = 1
- Sensores de ángulo, ej.:
- Sensor milimétrico (Target-1 Angle) = -11.809355735778809 °
La integración llegará a la tienda.
He corregido los puntos de los registros, pero necesito ver cómo manejar las características desconocidas.
Edición: he integrado las características desconocidas. Disponible en la integración EspHome v1.0.2
Hola,
Estoy probando mi detector de movimiento milimétrico basado en LD2410C.
Este tipo de sensor es capaz de detectar una presencia incluso si el « objetivo » está inmóvil. Es muy interesante para encender/apagar luces.
Necesitaría su ayuda para usarlo. De hecho, las diferentes funcionalidades se detectan como funcionalidades « presencia » y « movimiento ».
Aquí hay una comparación de la interpretación entre Gladys y HA:
¿Gladys interpreta bien los datos transmitidos? La funcionalidad de presencia está vinculada a un usuario de Gladys, me parece, por lo que es imposible usarla en escenas para la detección de movimientos (solo envía 1 cada vez que se detecta un movimiento). En cuanto a la funcionalidad « movimiento », nunca cambia de valor en Gladys, aunque lo veo cambiar en HA 
En ESPHome, estas funcionalidades se declaran como « Binary_sensor ».
Lo miro en cuanto puedo. Te aviso
He realizado un parcheo, una actualización de la integración estará disponible pronto.
Importante, probablemente tendrás que eliminar el dispositivo ya creado y volver a instalarlo después.
Manténme informado
Hola @Will_71
¡Gracias por la corrección!
Hay una mejora, las funcionalidades están declaradas correctamente en Gladys:
Al inicializar, todas las funcionalidades se actualizan correctamente (presencia detectada, movimiento detectado); sin embargo, cuando no hay movimiento, la funcionalidad sigue en « Movimiento detectado » y lo mismo ocurre con las funcionalidades de presencia que siguen en « Presencia detectada » a pesar de la ausencia de objetivo.
El ESP envía los cambios de estado (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
Gracias por tus pruebas, he hecho otra corrección.
¡Gracias, funciona perfectamente! !
Hola,
He desconectado mi esp durante unos días. Hoy he decidido volver a conectarlo.
El ESP32 emite datos en tiempo real (visto en el terminal esphome) pero Gladys ya no lo ve. He intentado reiniciar la integración, pero el resultado es el mismo.
Para que vuelva a funcionar, he tenido que:
- Forzar el registro de mi dispositivo en la configuración indicando su dirección IP en el campo « Nodos añadidos manualmente »;
- Reiniciar la integración.
Nota: mi ESP estaba registrado en Gladys (no lo había tocado). Observo que la detección de un dispositivo es aleatoria, a veces es identificado directamente por Gladys sin configurar nada y otras veces, para el mismo dispositivo, tengo que añadir el nodo manualmente.
Los registros:
[2026-09-09T12:00:28.194Z] [WARN] [gladys-sdk] conexión a Gladys perdida (código de cierre 1006)
[2026-09-09T12:00:28.194Z] [WARN] [gladys-sdk] no conectado a Gladys (ws://172.30.0.1:80), reintentando en 1000 ms (intento 1)
[2026-09-09T12:00:28.195Z] [INFO] Recibida SIGTERM -> apagado sin errores
[2026-09-09T12:00:29.263Z] [INFO] Iniciando la integración de ESPHome...
[2026-09-09T12:00:29.565Z] [INFO] [gladys-sdk] conectado a Gladys (http://172.30.0.1:80)
[2026-09-09T12:00:39.678Z] [INFO] [esphome-devices] escaneo mDNS (_esphomelib._tcp): 0 nodos ESPHome encontrados
[2026-09-09T12:00:39.679Z] [INFO] [esphome-devices] descubrimiento ESPHome: 0 dispositivo(s) construido(s)
[2026-09-09T12:08:48.478Z] [WARN] [gladys-sdk] conexión a Gladys perdida (código de cierre 1006)
[2026-09-09T12:08:48.478Z] [WARN] [gladys-sdk] no conectado a Gladys (ws://172.30.0.1:80), reintentando en 1000 ms (intento 1)
[2026-09-09T12:08:48.491Z] [INFO] Recibida SIGTERM -> apagado sin errores
[2026-09-09T12:08:49.371Z] [INFO] Iniciando la integración de ESPHome...
[2026-09-09T12:08:49.756Z] [INFO] [gladys-sdk] conectado a Gladys (http://172.30.0.1:80)
[2026-09-09T12:08:59.959Z] [INFO] [esphome-devices] escaneo mDNS (_esphomelib._tcp): 0 nodos ESPHome encontrados
[2026-09-09T12:08:59.959Z] [INFO] [esphome-devices] descubrimiento ESPHome: 0 dispositivo(s) construido(s)
[2026-09-09T12:09:21.294Z] [INFO] onConfigUpdated -> reconectando con la nueva configuración
[2026-09-09T12:09:26.820Z] [WARN] [gladys-sdk] conexión a Gladys perdida (código de cierre 1006)
[2026-09-09T12:09:26.820Z] [WARN] [gladys-sdk] no conectado a Gladys (ws://172.30.0.1:80), reintentando en 1000 ms (intento 1)
[2026-09-09T12:09:26.829Z] [INFO] Recibida SIGTERM -> apagado sin errores
[2026-09-09T12:09:27.672Z] [INFO] Iniciando la integración de ESPHome...
[2026-09-09T12:09:28.048Z] [INFO] [gladys-sdk] conectado a Gladys (http://172.30.0.1:80)
[2026-09-09T12:09:28.250Z] [INFO] [esphome-manager] Conectando al nodo ESPHome "192.168.50.50" (192.168.50.50:6053)
[2026-09-09T12:09:28.249Z] [WARN] [esphome-devices] escaneo mDNS no disponible: Conflicto
[2026-09-09T12:09:36.517Z] [INFO] [esphome-manager] El nodo ESPHome "192.168.50.50" informa su nombre real: "detecteur-mvts-millimetrique"
[2026-09-09T12:09:36.518Z] [INFO] El nodo ESPHome "detecteur-mvts-millimetrique" está conectado
[2026-09-09T12:09:36.526Z] [INFO] [esphome-devices] descubrimiento ESPHome: 1 dispositivo(s) construido(s)
A disposición para cualquier complemento
Actualización 17:04: le he pedido a Claude que lo revise. Tengo un archivo de parche que se ha generado, pero no sé cómo subirlo al foro, a tu disposición para enviártelo de otra manera.
El error principal
src/devices.js → discoverNodes() construye su lista de nodos a partir de dos fuentes solo: los resultados del escaneo mDNS y los nodos introducidos manualmente. Los dispositivos ya creados en Gladys nunca se consultan.
Es aún más lamentable porque la dirección ya está almacenada exactamente para eso. En buildDevice():
js
params: [
// Mantener la dirección para reconectar sin esperar un nuevo escaneo
{ name: PARAM_ADDRESS, value: `${node.host}:${node.port}` },
El comentario describe el comportamiento deseado… pero nunca se vuelve a leer este parámetro al inicio. Lo mismo ocurre en EsphomeManager: el mapa this.addresses (« para que la reconexión no dependa de un escaneo mDNS fresco ») se escribe, se renombra, se elimina — y nunca se lee en ningún lugar. Dos vestigios de una intención no cableada.
Consecuencia exacta de tus registros: 0 ESPHome node(s) found → 0 device(s) built → ninguna conexión TCP abierta → ningún estado publicado, aunque tu dispositivo sigue existiendo en Gladys y su IP es conocida.
La red de seguridad destinada a solucionar esto (onPoll en index.js, que lee PARAM_ADDRESS) es código muerto: ninguna poll_frequency se declara en las características (asumido modelo push), por lo que Gladys nunca pollea y este controlador nunca se llama.
Los dos errores secundarios
El Conflict. Es un 409 del núcleo, EXTERNAL_INTEGRATION_SCAN_ALREADY_RUNNING: un solo escaneo a la vez por integración. Tu onConfigUpdated a las 12:09:21 inicia un escaneo de 8 s, el contenedor se reinicia a las 12:09:26, y el escaneo del nuevo proceso a las 12:09:28 cae durante la ventana restante. El guardián inFlightScan es local al proceso y no protege de un reinicio. El error se traga sin reintentar.
El silencio sobre los resultados parciales. parseMdnsResult() devuelve null sin un solo registro si el nodo no tiene una dirección IPv4 en la respuesta. Un PTR recibido pero sin registro A da, por lo tanto, el mismo 0 node(s) found que una ausencia total de respuesta — imposible de diagnosticar.
Por qué es «aleatorio»
El núcleo envía bien una solicitud PTR activa (fui a ver networkDiscovery.scanMdns.js), pero mDNS sigue siendo multicast best-effort: ESP32 en modo de ahorro de energía Wi-Fi, punto de acceso que filtra o convierte el multicast, ventana de 8 s que pierde la respuesta. Un escaneo que falla una de cada tres veces es normal. Lo que no es normal es que un fallo de escaneo haga desaparecer un dispositivo ya registrado.
La corrección
He parcheado el repositorio, npm test pasa (83/83) y eslint está limpio. Tres cambios:
knownNodes(gladys): nueva función que vuelve a leerPARAM_ADDRESSen los dispositivos existentes, inyectada primero endiscoverNodes— un resultado de escaneo fresco lo sobrescribe (bail DHCP que se mueve), una entrada manual sobrescribe todo.runScanWithRetry(): en un 409, esperascan_duration + 2 sy luego un reintento.- Un watchdog de 60 s en
index.jsque reconecta los nodos conocidos sin sesión viva — el caso en el que el ESP estaba apagado al inicio del contenedor, que la reconexión automática deesphome-clientno cubre (solo recupera una sesión ya establecida).
@Will_71, si puedo ayudar más para resolverlo, no dudes
Lo siento, pero he vuelto al trabajo, ahora solo puedo mirar los fines de semana.
@PhilippeMA, acabo de publicar una corrección, la actualización estará disponible pronto en la tienda. ¡De lo contrario, puedes forzar la actualización!
Gracias @Will_71, los primeros tests son concluyentes:
- Conexión física del puerto USB del sensor después de actualizar la integración (con la ip forzada en el campo « Nodos añadidos manualmente »): OK
- Eliminación de la dirección IP del campo « Nodos añadidos manualmente »: el sensor se desconecta después de guardar la configuración y se reconecta rápidamente: OK
- Desconexión física del puerto USB del sensor USB y luego reconexión (es decir, con el campo « Nodos añadidos manualmente » vacío): OK
Las reconexiones a Gladys son casi inmediatas, ¡genial!
Voy a seguir con las pruebas y ver qué otro dispositivo puedo montar también.
Gracias de nuevo por crear esta integración, abre muchas puertas. ¡Me encanta!
Si tienes otros errores o cosas que añadir, no dudes en decírmelo.