ESPHome-Integration
Diese Integration könnte es ESPHome-Geräten ermöglichen, sich direkt mit Gladys über die native ESPHome-API zu verbinden.
Es gibt Lösungen, um ESP über MQTT zu verbinden, aber mit der Integration wäre es direkt.
Ich bin sicher, dass wir dafür super einfach ein Matterbridge-Plugin erstellen könnten 
Plugin ESPHome auf Matterbridge entwickelt!
Wird das dadurch nicht freigeschaltet?
Falls nicht, können wir eine externe Gladys-Integration machen 
Kann uns jemand eine externe ESPHome-Integration machen? 
Ich habe Claude darauf angesetzt, aber er hat mir etwas ausgegeben, und ich habe keine Möglichkeit, es von meiner Seite aus zu kontrollieren.
Guten Abend @pierre-gilles und @Will_71
Falls ich euch bei ESPHome irgendwie helfen kann, stehe ich euch gerne zur Verfügung.
Ich möchte mich noch einmal ganz herzlich bei @pierre-gilles für den Hinweis zu diesem Thema bedanken, der in meinem Fall sehr vielversprechend erscheint!
Schönen Abend noch,
Jean
Sehr interessiert! Ich habe mehrere ESPHome-Module zu Hause. MQTT funktioniert, aber die native API würde mDNS-Entdeckung und automatische Entity-Erstellung bringen. Mit der Ankunft der externen Integrationen ist das vielleicht der richtige Zeitpunkt? Freiwillig zum Testen.
Analysiert mit Hilfe von Claude (KI), überprüft und freigegeben von mir.
Hier ist das Entwicklerbild für die ESPHome-Integration. Ich habe es nicht getestet, da ich keine Hardware habe. Vielen Dank im Voraus für eure Tests.
Docker-Build-Zusammenfassung
Bild hochgeladen (linux/amd64 + linux/arm64):
ghcr.io/william-de71/gladys-esphome:dev
Teste diesen Build in Gladys
- In Gladys, öffne Integrationen → Integration installieren → Entwicklermodus.
- Kopiere das Manifest unten (dessen
docker_imagebereits auf diesen Build verweist):
{
"manifest_version": 1,
"type": "device",
"name": "ESPHome",
"description": {
"en": "Control your ESPHome devices (ESP32/ESP8266) locally, over the native API.",
"fr": "Pilotez vos appareils ESPHome (ESP32/ESP8266) en local, via l'API native.",
"de": "Steuern Sie Ihre ESPHome-Geräte (ESP32/ESP8266) lokal über die native API."
},
"version": "1.0.0",
"docker_image": "ghcr.io/william-de71/gladys-esphome:dev",
"gladys_version": ">=4.86.0",
"cover_image": "https://raw.githubusercontent.com/William-De71/gladys-esphome/master/cover.jpg",
"categories": [
"protocols",
"environment",
"lighting"
],
"transports": [
"local"
],
"network_discovery": [
{
"type": "mdns",
"service": "_esphomelib._tcp"
}
],
"config_schema": [
{
"key": "intro",
"type": "section",
"label": {
"en": "Getting started",
"fr": "Pour commencer",
"de": "Einführung"
},
"description": {
"en": "This integration talks to your ESPHome nodes on your local network, through their native API (port 6053). Paste your encryption key below, then go to the Discover screen and run a scan: the nodes found on your network appear there with all their entities, ready to be added. No IP address to type.",
"fr": "Cette intégration communique avec vos nœuds ESPHome sur votre réseau local, via leur API native (port 6053). Collez votre clé de chiffrement ci-dessous, puis allez dans l'écran Découverte et lancez un scan : les nœuds trouvés sur votre réseau y apparaissent avec toutes leurs entités, prêts à être ajoutés. Aucune adresse IP à saisir.",
"de": "Diese Integration kommuniziert mit Ihren ESPHome-Knoten in Ihrem lokalen Netzwerk über deren native API (Port 6053). Fügen Sie Ihren Verschlüsselungsschlüssel unten ein, gehen Sie dann zum Entdecken-Bildschirm und führen Sie einen Scan aus: Die im Netzwerk gefundenen Knoten erscheinen dort mit allen ihren Entitäten und sind bereit, hinzugefügt zu werden. Keine IP-Adresse erforderlich."
},
"links": [
{
"url": "https://esphome.io/components/api.html",
"label": {
"en": "ESPHome native API documentation",
"fr": "Documentation de l'API native ESPHome",
"de": "Dokumentation zur nativen ESPHome-API"
}
}
]
},
{
"key": "encryption_key",
"type": "secret",
"label": {
"en": "Encryption key",
"fr": "Clé de chiffrement",
"de": "Verschlüsselungsschlüssel"
},
"description": {
"en": "The base64 key declared under `api: encryption: key:` in your ESPHome YAML. Used for every node that has no specific key below. Leave empty only if your nodes have no encryption.",
"fr": "La clé base64 déclarée sous `api: encryption: key:` dans votre YAML ESPHome. Utilisée pour tous les nœuds n'ayant pas de clé spécifique ci-dessous. À laisser vide uniquement si vos nœuds n'ont pas de chiffrement.",
"de": "Der unter `api: encryption: key:` in Ihrer ESPHome-YAML deklarierte base64-Schlüssel. Wird für jeden Knoten verwendet, der keinen spezifischen Schlüssel unten hat. Nur leer lassen, wenn Ihre Knoten keine Verschlüsselung haben."
},
"placeholder": {
"en": "kBv1s2f...=",
"fr": "kBv1s2f...=",
"de": "kBv1s2f...="
},
"required": false
},
{
"key": "advanced",
"type": "section",
"label": {
"en": "Nodes with a different key",
"fr": "Nœuds avec une clé différente",
"de": "Knoten mit einem anderen Schlüssel"
},
"description": {
"en": "Fill the two fields below only if some nodes do not share the key above, or if a node is not found by the network scan (another VLAN, mDNS filtered by your router).",
"fr": "Ne remplissez les deux champs ci-dessous que si certains nœuds ne partagent pas la clé ci-dessus, ou si un nœud n'est pas trouvé par le scan réseau (autre VLAN, mDNS filtré par votre routeur).",
"de": "Füllen Sie die beiden unten stehenden Felder nur aus, wenn einige Knoten den Schlüssel oben nicht teilen oder wenn ein Knoten nicht durch den Netzwerk-Scan gefunden wird (anderes VLAN, mDNS durch Ihren Router gefiltert)."
}
},
{
"key": "encryption_keys",
"type": "secret",
"label": {
"en": "Keys per node",
"fr": "Clés par nœud",
"de": "Schlüssel pro Knoten"
},
"description": {
"en": "One node per line, in the form `node|key`. The node name is the one from your ESPHome YAML (`esphome: name:`), or its address. These keys take precedence over the key above.",
"fr": "Un nœud par ligne, sous la forme `nœud|clé`. Le nom du nœud est celui de votre YAML ESPHome (`esphome: name:`), ou son adresse. Ces clés sont prioritaires sur la clé ci-dessus.",
"de": "Ein Knoten pro Zeile in der Form `Knoten|Schlüssel`. Der Knotenname ist der aus Ihrer ESPHome-YAML (`esphome: name:`) oder dessen Adresse. Diese Schlüssel haben Vorrang vor dem Schlüssel oben."
},
"placeholder": {
"en": "salon|kBv1s2f...=\nkitchen|9xQm4Zt...=",
"fr": "salon|kBv1s2f...=\ncuisine|9xQm4Zt...=",
"de": "Wohnzimmer|kBv1s2f...=\nKüche|9xQm4Zt...="
},
"required": false
},
{
"key": "nodes",
"type": "string",
"label": {
"en": "Nodes added by hand",
"fr": "Nœuds ajoutés à la main",
"de": "Manuell hinzugefügte Knoten"
},
"description": {
"en": "One address per line (`salon.local`, `192.168.1.42`, or `192.168.1.42:6053`), for the nodes the network scan does not find. Nodes found by the scan need nothing here.",
"fr": "Une adresse par ligne (`salon.local`, `192.168.1.42`, ou `192.168.1.42:6053`), pour les nœuds que le scan réseau ne trouve pas. Les nœuds trouvés par le scan n'ont rien à faire ici.",
"de": "Eine Adresse pro Zeile (`Wohnzimmer.local`, `192.168.1.42` oder `192.168.1.42:6053`), für die Knoten, die der Netzwerk-Scan nicht findet. Knoten, die durch den Scan gefunden wurden, benötigen hier nichts."
},
"placeholder": {
"en": "salon.local\n192.168.1.42:6053",
"fr": "salon.local\n192.168.1.42:6053",
"de": "Wohnzimmer.local\n192.168.1.42:6053"
},
"required": false
},
{
"key": "scan_duration",
"type": "number",
"label": {
"en": "Discovery duration (s)",
"fr": "Durée de la découverte (s)",
"de": "Dauer der Entdeckung (s)"
},
"description": {
"en": "How long the mDNS scan listens for ESPHome nodes on the network.",
"fr": "Durée pendant laquelle le scan mDNS écoute les nœuds ESPHome sur le réseau.",
"de": "Wie lange der mDNS-Scan nach ESPHome-Knoten im Netzwerk sucht."
},
"required": false,
"default": 8,
"min": 3,
"max": 30
},
{
"key": "connection_timeout",
"type": "number",
"label": {
"en": "Connection timeout (s)",
"fr": "Délai d'attente de connexion (s)",
"de": "Verbindungszeitlimit (s)"
},
"description": {
"en": "How long to wait for a node to answer before giving up on it.",
"fr": "Temps d'attente pour qu'un nœud réponde avant de l'abandonner.",
"de": "Wie lange auf eine Antwort eines Knotens gewartet wird, bevor aufgegeben wird."
},
"required": false,
"default": 10,
"min": 5,
"max": 60
}
],
"actions": [
{
"key": "test_connection",
"label": {
"en": "Test the connection",
"fr": "Tester la connexion",
"de": "Verbindung testen"
},
"timeout_seconds": 60
},
{
"key": "reconnect",
"label": {
"en": "Reconnect the nodes",
"fr": "Reconnecter les nœuds",
"de": "Knoten neu verbinden"
},
"timeout_seconds": 60
}
]
}
Hallo @Will_71,
Vielen Dank für diese Integration 
Könntest du jedoch mehr Informationen zur Konfiguration und Nutzung dieser Integration geben, da sie mir nur für WLAN-Gadgets zu gelten scheint (du gibst einen Port 6053 an).
In meinem speziellen Fall möchte ich ESPHome auf Zigbee-Gadgets verwenden, daher befürchte ich, dass ich etwas durcheinanderbringe …
Schönen Abend noch,
Jean
Du musst mir alle deine Anwendungsfälle geben, denn ich habe keine Geräte dieser Art. Also habe ich einfach Claude darauf losgelassen.
Mit deinen Anwendungsfällen können wir Claude dann gezielt einsetzen.
In Zigbee? Kannst du sie nicht in zigbee2mqtt integrieren? Was erwartest du denn von der Integration?
Ich habe gerade einen alten Futterautomaten wiedergefunden. Die Elektronik ist wahrscheinlich kaputt, aber der Motor funktioniert noch (soweit ich mich erinnere, läuft er mit 9 V).
Ich möchte die Gelegenheit nutzen, um ihn mit einem kleinen ESP8266 + ESPHome wieder in Betrieb zu nehmen, indem ich einfach den Motor ein- und ausschalte, und vor allem die Integration von ESPHome, die derzeit für Gladys in Entwicklung ist, zu testen.
Ich habe schon ein paar ESP8266 herumliegen, also brauche ich nicht viel, um anzufangen.
Und ich bin auch auf dieses Projekt eines E-Ink-Bildschirms, der in die Deko integriert ist, gestoßen: https://community.home-assistant.io/t/use-esphome-with-e-ink-displays-to-blend-in-with-your-home-decor/435428 — ich finde das wirklich sehr cool!
Könnte so ein Bildschirm auch mit Gladys über ESPHome genutzt werden?
Falls jemand bereits ESPHome mit Gladys verwendet hat oder Tipps für solche Bastelprojekte hat, bin ich dankbar! 
Hallo @b3n.0
Deine beiden Themen haben sehr unterschiedliche Antworten, ich trenne sie.
Der Futterautomat: Das ist der Nominalfall, es funktioniert bereits. Ein Schalter: In deinem YAML meldet ESPHome direkt einen Ein-/Ausschalter an Gladys, ohne dass etwas konfiguriert werden muss. Für einen 9-V-Motor, ESP8266 + ein Relaismodul (oder ein MOSFET, wenn du es leise haben willst) und du erklärst:
switch:
- platform: gpio
pin: D1
name: "Futterautomat"
id: motor
Ein Tipp: Füge lieber ein on_turn_on mit einer Verzögerung und dann automatische Abschaltung hinzu, das verhindert, dass der Motor läuft, wenn eine Gladys-Szene abstürzt. Und versorge den Motor separat vom ESP8266 — ein startender Motor lässt die Spannung abfallen und der ESP startet neu.
Wenn du das testest, interessiert mich dein Feedback enorm: Ich habe keine ESPHome-Hardware auf meiner Seite, also entwickle ich blind. Zu wissen, dass der Basisweg wirklich auf echter Hardware funktioniert, wäre das nützlichste Feedback, das
ich erhalten könnte.
Der E-Ink-Bildschirm: Sehr gute Frage, und die Antwort ist weniger offensichtlich, als sie scheint.
Der Punkt, den man verstehen muss: In ESPHome ist ein Bildschirm keine Entität. Die Komponente display: ist vollständig lokal zur Firmware - es ist dein YAML, das über Lambdas zeichnet. Nichts wird auf der nativen API exponiert, also gibt es nichts, was Gladys „entdecken“ oder direkt steuern könnte.
Das Home Assistant-Projekt, das du zitierst, funktioniert tatsächlich indirekt: Die Firmware erklärt Eingabeentitäten, die HA versorgt, und das Lambda des display: liest diese Werte zum Zeichnen. Es ist nicht HA, das den Bildschirm steuert, sondern der ESP
der Werte liest und sich selbst zeichnet.
Und das ist perfekt mit Gladys machbar. Ich habe gerade den Support der Entität text zum Schreiben für diesen speziellen Fall hinzugefügt (sie wurde bisher ignoriert). Das Prinzip:
text:
- platform: template
name: "Bildschirmnachricht"
optimistic: true
mode: text
id: message_ecran
display:
- platform: waveshare_epaper
# ... lambda: |-
it.printf(0, 0, id(ma_police), "%s", id(message_ecran).state.c_str());
Du erhältst ein Text-Feature, das in Gladys bearbeitet werden kann: Du schreibst „Gelbe Mülltonnen morgen“, der ESP erhält die Zeichenkette und zeichnet neu. Gladys-Szenen können also den Bildschirm versorgen.
Zu beachten: Die Entitäten number: wurden bereits zum Schreiben unterstützt. Wenn du also numerische Werte anzeigen möchtest, kannst du sofort mit dem Experimentieren beginnen, ohne auf das nächste Bild warten zu müssen.
Zwei Warnungen zu E-Ink, um dir Unannehmlichkeiten zu ersparen: Diese Bildschirme haben eine begrenzte Anzahl vollständiger Aktualisierungen und jede Aktualisierung dauert mehrere Sekunden — also aktualisieren wir pro Minute oder bei Ereignissen, nie kontinuierlich. Und überprüfe, ob dein Modell in der Liste waveshare_epaper von ESPHome steht, bevor du kaufst, nicht alle werden unterstützt.
Wenn du es versuchst, bin ich an deinem Feedback interessiert — das ist genau die Art von konkreten Anwendungsfall für die Integration.
Das Testbild ist dasselbe, wenn bereits installiert, reicht es, das Update zu erzwingen.
Hallo @Will_71
Vielen Dank für deine beiden Antworten und die Arbeit an der ESPHome-Integration! 
Beim Stöbern nach ESP-Projekten bin ich auf den E-Ink-Bildschirm gestoßen, der wirklich sehr cool aussieht. Ich habe gerade keinen zur Hand, um so etwas zu testen, aber ich behalte die Idee definitiv für später im Hinterkopf. 
Und danke auch für deine Ratschläge bezüglich des Futterautomaten.
Ich konnte die ESPHome-Integration schließlich testen
Da du angegeben hast, nicht ausgestattet zu sein, um sie zu testen, habe ich einen kleinen NodeMCU v2 ESP8266 verwendet.
Ich habe ESPHome Device Builder installiert und ein erstes Gerät test-esphome mit der Standardkonfiguration erstellt:
esphome:
name: test-esphome
friendly_name: test-esphome
esp8266:
board: nodemcuv2
logger:
api:
encryption:
key: "..."
ota:
- platform: esphome
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: test-esphome Fallback Hotspot
password: "..."
captive_portal:
Ich habe den ESP per USB von ESPHome Device Builder aus geflasht.
Er verbindet sich korrekt mit dem Wi-Fi und erhält:
IP Address: 192.168.0.39
Hostname: test-esphome
Signal strength: -49 dBm
Mein Gladys ist unter 192.168.0.36.
Und dann, nachdem ich die Konfiguration in die ESPHome-Integration eingegeben habe, wird beim Scan nichts gefunden.
Ich habe sogar versucht, den Knoten später manuell in der Konfiguration hinzuzufügen:
192.168.0.39:6053
Weitere Information: Die Logs des ESP zeigen deutlich, dass Gladys sich erfolgreich mit seiner API verbindet:
Accept 192.168.0.36
esphome-client (192.168.0.36): connected
Also scheinen das Netzwerk und der Port 6053 in Ordnung zu sein.
Andererseits wird es dann etwas seltsam:
Accept 192.168.0.36
esphome-client (192.168.0.36): connected
Accept 192.168.0.36
esphome-client (192.168.0.36): connected
...
Max connections (4), rejecting 192.168.0.36
Dann mehrere:
Reading failed CONNECTION_CLOSED errno=11
Der ESP zeigt an:
API:
Address: test-esphome.local:6053
Max connections: 4
Noise encryption: YES
Das endgültige Ergebnis auf Gladys-Seite lautet:
Bisher wurden keine Geräte gefunden.
Dabei sieht der ESP klar, dass Gladys sich verbindet.
Ich weiß nicht, ob man daraus Schlüsse ziehen kann…
Nochmals vielen Dank für die Entwicklung dieser Integration!
Okay, danke für den Test. Sobald ein Fix bereit ist, lasse ich dich wissen.
vielen Dank!
Hallo @b3n.0
Dein Feedback war extrem hilfreich — es enthielt genau die richtigen Hinweise. Ich habe das Problem gefunden, und es lag weder an deiner Hardware, deiner Konfiguration noch an deinem Verschlüsselungsschlüssel. Deine Installation war von Anfang an korrekt.
Was passiert ist
Deine YAML-Datei für test-esphome deklariert keine Entitäten: keine API, kein OTA, kein WLAN, kein Logger, nichts. Das ist die Standard-YAML-Datei des ESPHome Device Builders, also nichts, was du falsch gemacht hast.
Mein Code ignorierte jedoch einfach alle Knoten, die keine nutzbare Funktion anbieten. Die Verbindung war erfolgreich — das zeigten deine ESP-Logs (esphome-client (192.168.0.36): connected), der verschlüsselte Handshake funktionierte problemlos — aber der Knoten wurde direkt danach stillschweigend verworfen. Ergebnis bei Gladys: „Kein Gerät entdeckt“, was sich nicht von einem falschen Schlüssel oder einem nicht erreichbaren ESP unterscheiden ließ.
Deshalb änderte das manuelle Hinzufügen von 192.168.0.39:6053 auch nichts: Das Problem lag nach der Verbindung, nicht auf Netzwerkebene.
Max connections (4)
Dein zweites Symptom war ein separates Problem, das dein Log identifizierbar machte. Die Client-Bibliothek, die ich verwende, versucht standardmäßig dreimal eine Verbindung herzustellen, also 1 Versuch + 3 Wiederholungen = 4 Sockets. Und das ESPHome-Firmware akzeptiert genau 4 API-Clients. Ein einzelner fehlgeschlagener Scan verbrauchte also das gesamte Kontingent deines ESP, was zu den „rejecting“- und CONNECTION_CLOSED errno=11-Fehlern führte. Ich habe das auf 1 Wiederholung (max. 2 Sockets) reduziert, was dem Knoten Spielraum lässt, während er einen ESP beim Neustart abfängt.
Korrekturen
- Ein erreichbarer Knoten wird nun immer in Gladys gemeldet, selbst wenn er keine Entitäten hat. Er wird ohne Funktionen angezeigt, aber er wird angezeigt — du wirst also wissen, dass die Verbindung funktioniert.
- Keine Überlastung der ESP-Verbindungen mehr.
- Der Log ist nun explizit und gibt direkt die nächsten Schritte an:
ESPHome-Knoten « test-esphome » (192.168.0.39:6053) ist erreichbar, bietet aber keine Funktionen
Gladys kann (0 Entitäten gesehen) verwenden: Deklariere eine Entität (Schalter, Sensor…) in seiner YAML
Ich habe einen Regressions-Test hinzugefügt, der deinen speziellen Fall reproduziert, und ich habe überprüft, dass er im alten Code fehlschlägt — damit dieses Szenario nicht wieder auftreten kann.
Für deinen nächsten Test
Bis die neue Image-Version veröffentlicht ist, kannst du bereits den gesamten Pfad validieren, indem du eine Entität zu deiner YAML hinzufügst. Das Einfachste, und es passt gut, da es dein Futterautomaten-Projekt ist:
switch:
- platform: gpio
pin: D1
name: "Futterautomat"
id: motor
Du flashst neu, und der Schalter sollte direkt in Gladys angezeigt werden. Das ist das Feedback, das mich jetzt am meisten interessiert: ob der On/Off-Befehl wirklich auf echter Hardware funktioniert. Ich entwickle immer ohne ESP zur Hand, also sind deine Tests es, was diese Integration voranbringt.
Ich informiere dich, sobald das Dev-Image veröffentlicht wird.
Das Entwickler-Image ist bereit, du musst nur noch das Update von Gladys aus erzwingen.
