Integration EspHome
Cette intégration pourrai permettre aux appareils ESPHome de se connecter directement à Gladys avec l’API native ESPHome.
Il existe des solutions pour connecter son Esp via mqtt, mais avec l’intégration ca serait direct.
Je suis sûr qu’on pourrait faire un plugin Matterbridge super simplement pour ça 
Plugin ESPHome développé sur Matterbridge !
Est ce que c’est pas débloqué par ça ?
Sinon, on pourra faire une intégration externe Gladys 
Quelqu’un nous fait une intégration externe ESPHome ? 
J’ai lancé Claude dessus, il m’a sorti quelquechose mais je n’ai aucun moyen de controle de mon côté.
Bonsoir @pierre-gilles et @Will_71
Si je peux vous être d’une quelconque aide pour ESPHome, je me tiens à votre disposition.
Je tiens une nouvelle fois à remercier très chaleuresement @pierre-gilles pour la piste donnée à ce sujet, qui me semble très prometteuse dans mon cas !
Belle fin de journée,
Jean
Très intéressé aussi ! J’ai plusieurs modules ESPHome à la maison. Le MQTT fonctionne mais l’API native apporterait la découverte mDNS et la création automatique des entités. Avec l’arrivée des intégrations externes, c’est peut-être le bon moment ? Volontaire pour tester.
Analysé avec l’aide de Claude (IA), relu et validé par mes soins.
Voilà l’image de dev pour l’integration esphome. Je n’ai pas testé car je n’ai pas de matériel. Merci d’avance pour vos tests.
Docker build summary
Image pushed (linux/amd64 + linux/arm64):
ghcr.io/william-de71/gladys-esphome:dev
Test this build in Gladys
- In Gladys, open Integrations → Install an integration → Developer mode.
- Copy the manifest below (its
docker_imagealready points to this build):
{
"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."
},
"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"
},
"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."
},
"links": [
{
"url": "https://esphome.io/components/api.html",
"label": {
"en": "ESPHome native API documentation",
"fr": "Documentation de l'API native ESPHome"
}
}
]
},
{
"key": "encryption_key",
"type": "secret",
"label": {
"en": "Encryption key",
"fr": "Clé de chiffrement"
},
"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."
},
"placeholder": {
"en": "kBv1s2f...=",
"fr": "kBv1s2f...="
},
"required": false
},
{
"key": "advanced",
"type": "section",
"label": {
"en": "Nodes with a different key",
"fr": "Nœuds avec une clé différente"
},
"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)."
}
},
{
"key": "encryption_keys",
"type": "secret",
"label": {
"en": "Keys per node",
"fr": "Clés par nœud"
},
"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."
},
"placeholder": {
"en": "salon|kBv1s2f...=\nkitchen|9xQm4Zt...=",
"fr": "salon|kBv1s2f...=\ncuisine|9xQm4Zt...="
},
"required": false
},
{
"key": "nodes",
"type": "string",
"label": {
"en": "Nodes added by hand",
"fr": "Nœuds ajoutés à la main"
},
"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."
},
"placeholder": {
"en": "salon.local\n192.168.1.42:6053",
"fr": "salon.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)"
},
"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."
},
"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)"
},
"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."
},
"required": false,
"default": 10,
"min": 5,
"max": 60
}
],
"actions": [
{
"key": "test_connection",
"label": {
"en": "Test the connection",
"fr": "Tester la connexion"
},
"timeout_seconds": 60
},
{
"key": "reconnect",
"label": {
"en": "Reconnect the nodes",
"fr": "Reconnecter les nœuds"
},
"timeout_seconds": 60
}
]
}
Bonjour @Will_71 ,
Merci pour cette intégration 
Peux-tu toutefois apporter plus d’informations quant à la configuration et l’usage de cette intégration, car elle me semble ne cibler que les bidules WIFI (tu précises un port 6053).
Dans mon cas précis, le souhaitais utiliser ESPHome sur des bidules en Zigbee uniquement, je crains donc qu’il y ait confusion de ma part …
Belle fin de journée,
Jean
C’est à toi de me donner tous les cas d’usage que tu as, car je n’ai pas de devices de ce type. Donc, j’ai juste lancé Claude dessus.
Donc, avec tes cas d’usage, on pourra aiguiller Claude.
En zigbee ? TU peux pas les intégrer dans zigbee2mqtt? Qu’est-ce que tu attends de l’intégration du coup?
Je viens de retrouver un vieux distributeur automatique de croquettes. La carte électronique est probablement HS, mais le moteur fonctionne encore (de mémoire, il serait en 9 V).
Je voudrais profiter de l’occasion pour le remettre en service avec un petit ESP8266 + ESPHome, en pilotant simplement le moteur ON/OFF, et surtout tester au passage l’intégration ESPHome actuellement en développement pour Gladys.
J’ai déjà quelques ESP8266 qui traînent, donc pas besoin de grand-chose pour commencer.
Et je suis aussi tombé sur ce projet d’écran e-ink intégré dans la déco : https://community.home-assistant.io/t/use-esphome-with-e-ink-displays-to-blend-in-with-your-home-decor/435428 — je trouve ça vraiment très cool !
Est-ce que ce genre d’écran pourrait également être exploité avec Gladys via ESPHome ?
Si certains ont déjà utilisé ESPHome avec Gladys ou ont des conseils pour ce genre de bricolage, je suis preneur ! 
Salut @b3n.0
Tes deux sujets ont des réponses assez différentes, je les sépare.
Le distributeur de croquettes : c’est le cas nominal, ça fonctionne déjà. Un switch: dans ton YAML ESPHome remonte directement en interrupteur on/off dans Gladys, sans rien à configurer. Pour un moteur 9 V, ESP8266 + un module relais (ou un MOSFET si tu veux du silencieux) et tu déclares :
switch:
- platform: gpio
pin: D1
name: "Distributeur croquettes"
id: moteur
Un conseil : ajoute plutôt un on_turn_on avec un delay puis extinction automatique, ça évite de laisser le moteur tourner si une scène Gladys plante. Et alimente le moteur séparément de l’ESP8266 — un moteur qui démarre fait chuter la tension et l’ESP redémarre.
Si tu testes ça, ton retour m’intéresse énormément : je n’ai pas de matériel ESPHome de mon côté, donc je développe à l’aveugle. Savoir que le chemin de base fonctionne vraiment sur du vrai matériel serait le retour le plus utile que
je puisse recevoir.
L’écran e-ink : très bonne question, et la réponse est moins évidente qu’elle n’en a l’air.
Le point à comprendre : dans ESPHome, un écran n’est pas une entité. Le composant display: est entièrement local au firmaware - c’est ton YAML qui dessine, via des lambdas. Rien n’est exposé sur l’API native, donc il n’y a rien que Gladys puisse « découvrir » ou piloter directement.
Le projet Home Assistant que tu cites fonctionne en fait par ricochet : le firmware déclare des entités d’entrée que HA alimente, et le lambda du display: lit ces valeurs pour dessiner. Ce n’est pas HA qui pilote l’écran, c’est l’ESP
qui lit des valeurs et se dessine lui-même.
Et ça, c’est parfaitement faisable avec Gladys. Je viens justement d’ajouter le support de l’entité text en écriture pour ce cas précis (elle était ignorée jusqu’ici). Le principe :
text:
- platform: template
name: "Message écran"
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());
Tu obtiens une feature texte modifiable dans Gladys : tu y écris « Poubelles jaunes demain », l’ESP reçoit la chaîne et redessine. Les scènes Gladys peuvent donc alimenter l’écran.
À noter : les entités number: étaient déjà supportées en écriture. Donc si tu veux afficher des valeurs numériques, tu peux commencer à expérimenter tout de suite, sans attendre la prochaine image.
Deux avertissements sur l’e-ink, pour t’éviter des déconvenues : ces écrans ont un nombre de rafraîchissements complets limité et chaque refresh prend plusieurs secondes — donc on met à jour à la minute ou à l’événement, jamais en continu. Et vérifie que ton modèle est dans la liste waveshare_epaper d’ESPHome avant d’acheter, tous ne sont pas gérés.
Si tu te lances, je suis preneur de tes retours — c’est exactement le genre de cas d’usage concret dol’intégration.
L’image de test est la même, si déjà installés il suffit de forcer la mise à jour.
Salut @Will_71
Merci pour tes deux réponses et pour le travail sur l’intégration ESPHome ! 
J’avais, en fouillant à la recherche de projet ESP, trouvé l’écran e-ink vraiment très cool. Je n’en ai pas pour le moment sous la main pour tester ce genre de choses, mais je garde clairement l’idée de côté pour plus tard. 
Et merci également pour tes conseils concernant le distributeur de croquettes.
J’ai finalement pu tester l’intégration ESPHome
Comme tu indiquais ne pas être équipé pour pouvoir la tester, j’ai utilisé un petits NodeMCU v2 ESP8266.
J’ai installé ESPHome Device Builder, créé un premier appareil test-esphome avec la configuration standard :
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:
J’ai flashé l’ESP en USB depuis ESPHome Device Builder.
Il se connecte correctement au Wi-Fi et obtient :
IP Address: 192.168.0.39
Hostname: test-esphome
Signal strength: -49 dBm
Mon Gladys est en 192.168.0.36.
Et là, après avoir entré la config dans l’intégration ESP Home, rien n’est trouvé rien lors du scan.
J’ai même essayé dans un second temps d’ajouter le nœud manuellement dans la configuration :
192.168.0.39:6053
Autre info, les logs de l’ESP montrent clairement que Gladys arrive bien à se connecter à son API :
Accept 192.168.0.36
esphome-client (192.168.0.36): connected
Donc le réseau et le port 6053 semblent OK.
En revanche, ensuite ça devient assez bizarre :
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
Puis plusieurs :
Reading failed CONNECTION_CLOSED errno=11
L’ESP indique bien :
API:
Address: test-esphome.local:6053
Max connections: 4
Noise encryption: YES
Le résultat final côté Gladys reste :
Aucun appareil découvert pour le moment.
Alors que l’ESP, lui, voit clairement Gladys se connecter.
Je ne sais pas si on peut en tirer des conclusions…
Merci encore pour le développement de cette intégration !
Ok je te remercie pour le test. Dès qu’un fix est prêt je te tiens au courant
merci beaucoup !
Salut @b3n.0
Ton retour a été extrêmement utile — il contenait exactement les bons indices. J’ai trouvé le problème, et ce n’était ni ton matériel, ni ta config, ni ta clé de chiffrement. Ton installation était bonne depuis le début.
Ce qui se passait
Ton YAML test-esphome ne déclare aucune entité : api, ota, wifi, logger, et c’est tout. C’est le YAML par défaut d’ESPHome Device Builder, rien à te reprocher.
Or mon code écartait purement et simplement tout nœud n’exposant aucune fonctionnalité utilisable. La connexion réussissait parfaitement — c’est bien ce que montraient tes logs ESP (esphome-client (192.168.0.36): connected), le handshake chiffré passait sans problème — mais le nœud était jeté juste après, en silence. Résultat côté Gladys : « Aucun appareil découvert », impossible à distinguer d’une mauvaise clé ou d’un ESP injoignable.
C’est aussi pour ça que l’ajout manuel de 192.168.0.39:6053 ne changeait rien : le problème était en aval de la connexion, pas au niveau de la découverte réseau.
Le Max connections (4)
Ton second symptôme était un bug distinct, que ton log a permis d’identifier. La bibliothèque cliente que j’utilise retente une connexion 3 fois par défaut, soit 1 tentative + 3 reprises = 4 sockets. Et le firmware ESPHome accepte… exactement 4 clients API. Un seul scan en échec saturait donc tout le quota de ton ESP, d’où le rejecting puis les CONNECTION_CLOSED errno=11. J’ai ramené ça à 1 reprise (2 sockets max), ce qui laisse de la marge au nœud tout en absorbant un ESP en cours de redémarrage.
Corrigé
- Un nœud joignable est désormais toujours remonté dans Gladys, même sans aucune entité. Il apparaîtra sans fonctionnalité, mais il apparaîtra — tu sauras ainsi que la connexion fonctionne.
- Plus de saturation des connexions de l’ESP.
- Le log est devenu explicite et donne directement la marche à suivre :
ESPHome node « test-esphome » (192.168.0.39:6053) is reachable but exposes no feature
Gladys can use (0 entity(ies) seen): declare an entity (switch, sensor…) in its YAML
J’ai ajouté un test de régression qui reproduit ton cas précis, et j’ai vérifié qu’il échouait bien sur l’ancien code — pour que ce scénario ne puisse plus repasser.
Pour ton prochain test
En attendant la nouvelle image, tu peux déjà valider le chemin complet en ajoutant une entité à ton YAML. Le plus simple, et ça tombe bien puisque c’est ton projet de distributeur :
switch:
- platform: gpio
pin: D1
name: "Distributeur croquettes"
id: moteur
Tu reflashes, et l’interrupteur devrait remonter directement dans Gladys. C’est ce retour-là qui m’intéresse le plus maintenant : savoir si la commande on/off fonctionne vraiment sur du vrai matériel. Je développe toujours sans ESP sous la main, donc tes tests sont ce qui fait avancer cette intégration.
Je te préviens dès que l’image de dev est publiée.
L’image de dev est prête, tu as juste à forcer la mise à jour depuis Gladys.
