EspHome Integration

[Will_71]

Keep me posted as soon as you run more tests, or if you notice any missing features.

[PhilippeMA]

Hello @Will_71

Thanks for this new integration, it’s great to be able to integrate these devices with Gladys.

I tried a millimeter sensor on an ESP32-C3 Supermini.

It was detected on the first try Many features:

Overall, everything works. It’s just a shame that some features are listed as unknown, but I suppose that’s more related to the core? Here’s what it looks like on the dashboard (excerpt):

In the logs, I see 2 issues:

This first error is spammed with the same data displayed and nothing that allows to see where it comes from.

[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"

The other problem seems to indicate too much data being updated?

[2026-08-24T18:00:24.842Z] [WARN] Publishing a state of "capteur-millimetrique" failed: Too Many Requests

[Will_71]

Could you tell me what the unknown features correspond to? Maybe we could integrate them into the core.
For the logs, I’ll look into them as soon as I can and keep you updated.
Thanks for these tests.

[PhilippeMA]

There are 2 types of features:

• Integer counters, ex.:
  • Millimeter sensor (Moving Target Count) = 1
  • Millimeter sensor (Presence Target Count) = 1
  • Millimeter sensor (Still Target Count) = 1
• Angle sensors, ex.:
  • Millimeter sensor (Target-1 Angle) = -11.809355735778809 °

[Will_71]

The integration is coming to the store.
I’ve fixed the log points but I need to see how to handle the unknown features.

Edit: I’ve integrated the unknown features. Available in EspHome integration v1.0.2

[PhilippeMA]

Hello,

I’m currently tinkering with my millimeter-wave motion detector based on the LD2410C.

This type of sensor is capable of detecting a presence even if the « target » is stationary. It’s very interesting for turning lights on and off.

I would need your help to use it. Indeed, the different functionalities are detected as « presence » and « movement » features.

Here is a comparison of the interpretation between Gladys and HA:

Does Gladys correctly interpret the transmitted data? The presence feature seems to be linked to a Gladys user, so it cannot be used in scenes for motion detection (it just sends a 1 every time a movement is detected). As for the « movement » feature, it never changes value under Gladys, whereas I can see it change under HA

Under ESPHome, these features are declared as « Binary_sensor ».

[Will_71]

I’ll watch as soon as I can. I’ll keep you posted.

[Will_71]

I made a fix, an update to the integration will be available soon.
Important, you will probably need to delete the already created device and then add it again.

Keep me posted

[PhilippeMA]

Hello @Will_71

Thanks for the correction!

It’s getting better, the features are properly declared on Gladys:

At initialization, all features are correctly updated (presence detected, movement detected); however, when there is no more movement, the feature remains at « Movement detected » and the same goes for the presence features which remain « Presence detected » despite the absence of a target.

The ESP is still sending the state changes (ESP Home logs):

[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

[Will_71]

Thanks for your tests, I made another correction.

[PhilippeMA]

Thanks, it works perfectly!!

[PhilippeMA]

Hello,

I unplugged my ESP for a few days. Today, I decided to plug it back in.

The ESP32 emits real-time data (seen in the esphome terminal) but Gladys no longer sees it. I tried restarting the integration but the result is the same.

To get it working again, I had to:

1. Force the registration of my device in the settings by entering its IP address in the « Manually Added Nodes » field;
2. Restart the integration.

Note: my ESP was registered in Gladys (I hadn’t touched it). I notice that device detection is random; sometimes it is identified directly by Gladys without any configuration, and other times, for the same device, I have to add the node manually.

The 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

Available for any additional information

Update 17:04: I asked Claude to look into it. I have a patch file that was generated, but I don’t know how to put it on the forum. I’m available to send it to you in another way.

The main bug

src/devices.js → discoverNodes() builds its list of nodes from two sources only: the results of the mDNS scan, and the manually entered nodes. Devices already created in Gladys are never consulted.

This is all the more unfortunate because the address is already stored exactly for this purpose. In buildDevice():

js

params: [
  // Keep the address to reconnect without waiting for a new scan
  { name: PARAM_ADDRESS, value: `${node.host}:${node.port}` },

The comment describes the desired behavior… but this parameter is never read on startup. The same goes for EsphomeManager: the map this.addresses (« so a reconnection does not depend on a fresh mDNS scan ») is written, renamed, deleted — and never read anywhere. Two remnants of an unconnected intention.

Exact consequence of your logs: 0 ESPHome node(s) found → 0 device(s) built → no TCP connection opened → no state published, although your device still exists in Gladys and its IP is known.

The safety net supposed to catch this (onPoll in index.js, which reads PARAM_ADDRESS) is dead code: no poll_frequency is declared on the features (push model assumed), so Gladys never polls and this handler is never called.

The two secondary bugs

The Conflict. This is a 409 from the core, EXTERNAL_INTEGRATION_SCAN_ALREADY_RUNNING: only one scan at a time per integration. Your onConfigUpdated at 12:09:21 starts an 8-second scan, the container is restarted at 12:09:26, and the scan of the new process at 12:09:28 falls during the remaining window. The inFlightScan guard is local to the process and does not protect against a restart. The error is swallowed without retry.

The silence on partial results. parseMdnsResult() returns null without a single log if the node does not have an IPv4 address in the response. A received PTR but without an A record thus gives the same 0 node(s) found as a total absence of response — impossible to diagnose.

Why it’s « random »

The core does send an active PTR request (I checked networkDiscovery.scanMdns.js), but mDNS remains multicast best-effort: ESP32 in Wi-Fi power save mode, access point that filters or converts multicast, 8-second window that misses the response. A scan that fails one out of three times is normal. What is not normal is that a scan failure makes a previously registered device disappear.

The fix

I patched the repository, npm test passes (83/83) and eslint is clean. Three changes:

1. knownNodes(gladys): new function that reads PARAM_ADDRESS on existing devices, injected first into discoverNodes — a fresh scan result overrides it (moving DHCP bail), a manual entry overrides everything.
2. runScanWithRetry(): on a 409, wait scan_duration + 2 s then retry.
3. A 60-second watchdog in index.js that reconnects known nodes without a live session — the case where the ESP was turned off when the container started, which the auto-reconnect of esphome-client does not cover (it only catches an already established session).

[PhilippeMA]

@Will_71, if I can help further with the resolution, don’t hesitate

[Will_71]

Sorry but I’ve gone back to work, I can only look at the weekends now.

[Will_71]

@PhilippeMA, I just published a fix, the update will soon be available in the store. Otherwise, you can force the update!

[PhilippeMA]

Thanks @Will_71, the initial tests are conclusive:

• Physical connection of the sensor’s USB port after updating the integration (with the IP forced in the « Manually Added Nodes » field): OK
• Removal of the IP address from the « Manually Added Nodes » field: the sensor disconnects after saving the configuration and reconnects quickly: OK
• Physical disconnection of the USB sensor’s USB port then reconnection (i.e., with the « Manually Added Nodes » field empty): OK

Reconnections to Gladys are almost immediate, perfect!

I will continue testing and see what other devices I can set up as well.

Thanks again for creating this integration, it opens many doors. I love it

[Will_71]

If you have other bugs or other features to add, don’t hesitate.