Halte mich auf dem Laufenden, sobald du weitere Tests durchführst oder wenn du siehst, dass Funktionen fehlen.
Hallo @Will_71
Danke für diese neue Integration, es ist toll, dass man diese Geräte in Gladys einbinden kann.
Ich habe einen Millimeter-Sensor an einem ESP32-C3 Supermini ausprobiert.
Es wurde sofort erkannt 
Viele Funktionen:
Alles in allem funktioniert alles. Es ist nur schade, dass einige Funktionen als unbekannt aufgelistet sind, aber ich vermute, dass das eher mit dem Kern zusammenhängt? Hier ist ein Ausschnitt, wie es im Dashboard aussieht:
In den Logs sehe ich zwei Probleme:
Dieser erste Fehler wird immer mit denselben Daten angezeigt und es gibt nichts, was darauf hindeutet, woher er kommt.
[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"
Das andere Problem scheint darauf hinzudeuten, dass zu viele Daten aktualisiert werden?
[2026-08-24T18:00:24.842Z] [WARN] Publishing a state of "capteur-millimetrique" failed: Too Many Requests
Könntest du mir bitte sagen, wofür die unbekannten Funktionen stehen? Vielleicht kann man sie dann in den Kern integrieren.
Bei den Logs schaue ich, sobald ich kann, und halte dich auf dem Laufenden.
Danke für die Tests.
Es gibt 2 Arten von Funktionen:
- Ganzzahlige Zähler, z. B.:
- Millimeter-Sensor (Moving Target Count) = 1
- Millimeter-Sensor (Presence Target Count) = 1
- Millimeter-Sensor (Still Target Count) = 1
- Winkelsensoren, z. B.:
- Millimeter-Sensor (Target-1 Angle) = -11,809355735778809 °
Die Integration wird im Store verfügbar sein.
Ich habe die Punkte in den Logs korrigiert, aber ich muss sehen, wie ich mit den unbekannten Funktionen umgehen soll.
Edit: Ich habe die unbekannten Funktionen integriert. Verfügbar in der EspHome-Integration v1.0.2
Hallo,
Ich bastle gerade an meinem Millimeter-Bewegungssensor auf Basis des LD2410C.
Dieser Sensortyp kann eine Präsenz erkennen, selbst wenn das „Ziel“ unbewegt ist. Das ist super interessant, um Lichter ein- und auszuschalten.
Ich bräuchte eure Hilfe, um ihn zu nutzen. Die verschiedenen Funktionen werden nämlich als „Präsenz“ und „Bewegung“ erkannt.
Hier ein Vergleich der Interpretation zwischen Gladys und HA:
Interpretiert Gladys die übertragenen Daten richtig? Die Präsenzfunktion ist, glaube ich, mit einem Gladys-Benutzer verknüpft, daher nicht für Bewegungsdetektion in Szenen nutzbar (sie sendet nur eine 1 bei jeder erkannten Bewegung). Was die Bewegungsfunktion betrifft, ändert sich der Wert unter Gladys nie, obwohl ich ihn unter HA gut wechseln sehe 
Unter ESPHome werden diese Funktionen als „Binary_sensor“ deklariert.
Ich schaue, sobald ich kann. Ich halte dich auf dem Laufenden.
Ich habe einen Fix gemacht, ein Update der Integration wird bald verfügbar sein.
Wichtig, du wirst wahrscheinlich das bereits erstellte Gerät löschen und es anschließend neu einrichten müssen.
Halte mich auf dem Laufenden
Hallo @Will_71
Vielen Dank für die Korrektur!
Es gibt Fortschritte, die Funktionen sind korrekt auf Gladys deklariert:
Bei der Initialisierung werden alle Funktionen korrekt aktualisiert (Präsenz erkannt, Bewegung erkannt); andererseits bleibt die Funktion bei „Bewegung erkannt“, wenn keine Bewegung mehr vorhanden ist, und ebenso bei den Präsenzfunktionen, die bei „Präsenz erkannt“ bleiben, obwohl kein Ziel vorhanden ist.
Der ESP sendet dennoch die Statusänderungen (ESP Home-Logs):
[12:26:18.471][S][binary_sensor]: 'Präsenz' >> AN
[12:26:18.471][S][binary_sensor]: 'Ziel vorhanden' >> AN
[12:26:18.471][S][binary_sensor]: 'Bewegtes Ziel vorhanden' >> AN
[12:26:18.472][S][binary_sensor]: 'Stillstehendes Ziel vorhanden' >> AN
[12:26:20.394][S][binary_sensor]: 'Bewegtes Ziel vorhanden' >> AUS
[12:26:28.178][S][binary_sensor]: 'Präsenz' >> AUS
[12:26:28.178][S][binary_sensor]: 'Ziel vorhanden' >> AUS
[12:26:28.179][S][binary_sensor]: 'Stillstehendes Ziel vorhanden' >> AUS
[12:27:39.272][S][binary_sensor]: 'Präsenz' >> AN
[12:27:39.272][S][binary_sensor]: 'Ziel vorhanden' >> AN
[12:27:39.273][S][binary_sensor]: 'Bewegtes Ziel vorhanden' >> AN
[12:27:39.755][S][binary_sensor]: 'Stillstehendes Ziel vorhanden' >> AN
[12:27:40.466][S][binary_sensor]: 'Bewegtes Ziel vorhanden' >> AUS
[12:27:43.749][S][binary_sensor]: 'Bewegtes Ziel vorhanden' >> AN
[12:27:48.360][S][binary_sensor]: 'Bewegtes Ziel vorhanden' >> AUS
[12:28:20.716][S][binary_sensor]: 'Präsenz' >> AUS
[12:28:20.716][S][binary_sensor]: 'Ziel vorhanden' >> AUS
[12:28:20.716][S][binary_sensor]: 'Stillstehendes Ziel vorhanden' >> AUS
Danke für deine Tests, ich habe eine weitere Korrektur vorgenommen.
Danke, es funktioniert perfekt !!
Hallo,
Ich habe meinen ESP für einige Tage vom Netz getrennt. Heute habe ich ihn wieder angeschlossen.
Der ESP32 sendet Echtzeitdaten (im esphome-Terminal sichtbar), aber Gladys erkennt ihn nicht mehr. Ich habe versucht, die Integration neu zu starten, aber das Ergebnis ist dasselbe.
Damit es wieder funktioniert, musste ich:
- Die Registrierung meines Geräts in den Einstellungen erzwingen, indem ich seine IP-Adresse im Feld « Manuell hinzugefügte Knoten » angebe;
- Die Integration neu starten.
Hinweis: Mein ESP war in Gladys registriert (ich habe nichts verändert). Ich stelle fest, dass die Erkennung eines Geräts zufällig erfolgt, manchmal wird es direkt von Gladys ohne Konfiguration erkannt, und manchmal muss ich für dasselbe Gerät den Knoten manuell hinzufügen.
Die Logs:
[2026-09-09T12:00:28.194Z] [WARN] [gladys-sdk] Verbindung zu Gladys verloren (Schließcode 1006)
[2026-09-09T12:00:28.194Z] [WARN] [gladys-sdk] Nicht mit Gladys verbunden (ws://172.30.0.1:80), versuche es in 1000 ms erneut (Versuch 1)
[2026-09-09T12:00:28.195Z] [INFO] SIGTERM empfangen -> sanftes Herunterfahren
[2026-09-09T12:00:29.263Z] [INFO] Starte die ESPHome-Integration...
[2026-09-09T12:00:29.565Z] [INFO] [gladys-sdk] Verbunden mit Gladys (http://172.30.0.1:80)
[2026-09-09T12:00:39.678Z] [INFO] [esphome-devices] mDNS-Scan (_esphomelib._tcp): 0 ESPHome-Knoten gefunden
[2026-09-09T12:00:39.679Z] [INFO] [esphome-devices] ESPHome-Erkennung: 0 Geräte erstellt
[2026-09-09T12:08:48.478Z] [WARN] [gladys-sdk] Verbindung zu Gladys verloren (Schließcode 1006)
[2026-09-09T12:08:48.478Z] [WARN] [gladys-sdk] Nicht mit Gladys verbunden (ws://172.30.0.1:80), versuche es in 1000 ms erneut (Versuch 1)
[2026-09-09T12:08:48.491Z] [INFO] SIGTERM empfangen -> sanftes Herunterfahren
[2026-09-09T12:08:49.371Z] [INFO] Starte die ESPHome-Integration...
[2026-09-09T12:08:49.756Z] [INFO] [gladys-sdk] Verbunden mit Gladys (http://172.30.0.1:80)
[2026-09-09T12:08:59.959Z] [INFO] [esphome-devices] mDNS-Scan (_esphomelib._tcp): 0 ESPHome-Knoten gefunden
[2026-09-09T12:08:59.959Z] [INFO] [esphome-devices] ESPHome-Erkennung: 0 Geräte erstellt
[2026-09-09T12:09:21.294Z] [INFO] onConfigUpdated -> Verbinde mit der neuen Konfiguration
[2026-09-09T12:09:26.820Z] [WARN] [gladys-sdk] Verbindung zu Gladys verloren (Schließcode 1006)
[2026-09-09T12:09:26.820Z] [WARN] [gladys-sdk] Nicht mit Gladys verbunden (ws://172.30.0.1:80), versuche es in 1000 ms erneut (Versuch 1)
[2026-09-09T12:09:26.829Z] [INFO] SIGTERM empfangen -> sanftes Herunterfahren
[2026-09-09T12:09:27.672Z] [INFO] Starte die ESPHome-Integration...
[2026-09-09T12:09:28.048Z] [INFO] [gladys-sdk] Verbunden mit Gladys (http://172.30.0.1:80)
[2026-09-09T12:09:28.250Z] [INFO] [esphome-manager] Verbindung zum ESPHome-Knoten "192.168.50.50" (192.168.50.50:6053)
[2026-09-09T12:09:28.249Z] [WARN] [esphome-devices] mDNS-Scan nicht verfügbar: Konflikt
[2026-09-09T12:09:36.517Z] [INFO] [esphome-manager] ESPHome-Knoten "192.168.50.50" meldet seinen echten Namen: "detecteur-mvts-millimetrique"
[2026-09-09T12:09:36.518Z] [INFO] ESPHome-Knoten "detecteur-mvts-millimetrique" ist verbunden
[2026-09-09T12:09:36.526Z] [INFO] [esphome-devices] ESPHome-Erkennung: 1 Gerät erstellt
Ich stehe für weitere Informationen zur Verfügung
Update 17:04: Ich habe Claude gebeten, sich damit zu beschäftigen. Es wurde eine Patch-Datei generiert, aber ich weiß nicht, wie ich sie ins Forum stellen soll. Ich kann sie dir auf andere Weise zur Verfügung stellen.
Der Hauptfehler
src/devices.js → discoverNodes() baut seine Liste der Knoten aus zwei Quellen auf: den Ergebnissen des mDNS-Scans und den manuell eingegebenen Knoten. Geräte, die bereits in Gladys erstellt wurden, werden nie abgefragt.
Das ist besonders schade, weil die Adresse genau dafür gespeichert ist. In buildDevice():
js
params: [
// Behalte die Adresse, um ohne erneuten Scan eine Verbindung herzustellen
{ name: PARAM_ADDRESS, value: `${node.host}:${node.port}` },
Der Kommentar beschreibt das gewünschte Verhalten… aber es wird nie ein Parameter beim Starten neu gelesen. Dasselbe gilt für EsphomeManager: Die Map this.addresses (« damit eine erneute Verbindung nicht von einem neuen mDNS-Scan abhängt ») wird geschrieben, umbenannt, gelöscht — und nirgendwo gelesen. Zwei Überreste einer nicht verkabelten Absicht.
Genaues Ergebnis deiner Logs: 0 ESPHome-Knoten gefunden → 0 Geräte erstellt → keine TCP-Verbindung geöffnet → kein Status veröffentlicht, obwohl dein Gerät weiterhin in Gladys existiert und seine IP-Adresse bekannt ist.
Die Sicherheitsnetz, das dies auffangen sollte (onPoll in index.js, das PARAM_ADDRESS liest), ist totes Code: Keine poll_frequency wird auf den Features deklariert (Push-Modell angenommen), daher wird Gladys nie gepollt und dieser Handler wird nie aufgerufen.
Die beiden Nebenfehler
Der Konflikt. Es ist ein 409 des Kerns, EXTERNAL_INTEGRATION_SCAN_ALREADY_RUNNING: Nur ein Scan pro Integration gleichzeitig. Dein onConfigUpdated um 12:09:21 startet einen 8-Sekunden-Scan, der Container wird um 12:09:26 neu gestartet, und der Scan des neuen Prozesses um 12:09:28 fällt in das verbleibende Fenster. Der Wächter inFlightScan ist lokal zum Prozess und schützt nicht vor einem Neustart. Der Fehler wird ohne erneuten Versuch verschluckt.
Die Stille über die teilweisen Ergebnisse. parseMdnsResult() gibt null ohne ein einziges Log aus, wenn der Knoten keine IPv4-Adresse in der Antwort hat. Ein empfangener PTR ohne A-Eintrag ergibt also dasselbe 0 Knoten gefunden wie eine vollständige Nichtantwort — nicht diagnostizierbar.
Warum ist es „zufällig“
Der Kern sendet tatsächlich eine aktive PTR-Anfrage (ich habe networkDiscovery.scanMdns.js überprüft), aber mDNS ist ein best-effort-Multicast: ESP32 im Wi-Fi-Energiesparmodus, Zugangspunkt, der den Multicast filtert oder umwandelt, 8-Sekunden-Fenster, das die Antwort verpasst. Ein Scan, der einmal in drei Fällen fehlschlägt, ist normal. Was nicht normal ist, ist, dass ein Scan-Fehler ein bereits registriertes Gerät verschwinden lässt.
Der Patch
Ich habe das Repository gepatcht, npm test läuft durch (83/83) und eslint ist sauber. Drei Änderungen:
knownNodes(gladys): Neue Funktion, diePARAM_ADDRESSauf bestehenden Geräten neu liest, injiziert als erste indiscoverNodes— ein frisches Scanergebnis überschreibt es (DHCP-Bail, das sich bewegt), eine manuelle Eingabe überschreibt alles.runScanWithRetry(): Bei einem 409 wirdscan_duration + 2 sgewartet und dann ein erneuter Versuch unternommen.- Ein Watchdog von 60 s in
index.js, der Knoten ohne aktive Sitzung neu verbindet — der Fall, in dem der ESP beim Starten des Containers ausgeschaltet war, denesphome-clientnicht abdeckt (er fängt nur eine bereits etablierte Sitzung ab).
@Will_71, falls ich bei der Lösung weiterhelfen kann, zögere nicht
Tut mir leid, aber ich habe wieder angefangen zu arbeiten, ich kann nur noch am Wochenende schauen.
@PhilippeMA, ich habe gerade ein Update veröffentlicht, das Update wird bald im Store verfügbar sein. Alternativ kannst du das Update erzwingen!
Danke @Will_71, die ersten Tests sind erfolgreich:
- Physischer Anschluss des USB-Anschlusses des Sensors nach dem Update der Integration (mit der erzwungenen IP im Feld « Manuell hinzugefügte Knoten ») : OK
- Löschen der IP-Adresse aus dem Feld « Manuell hinzugefügte Knoten »: Der Sensor trennt sich nach dem Speichern der Konfiguration und verbindet sich schnell wieder: OK
- Physisches Trennen des USB-Anschlusses des USB-Sensors und erneutes Verbinden (d. h. mit leerem Feld « Manuell hinzugefügte Knoten ») : OK
Die erneuten Verbindungen zu Gladys sind fast sofort, perfekt!
Ich werde die Tests fortsetzen und sehen, was ich noch für andere Geräte machen kann.
Nochmals danke für die Erstellung dieser Integration, das öffnet viele Türen. Ich liebe es
Wenn du noch weitere Fehler oder Ergänzungen hast, zögere nicht.