Integración de ESPHome
Esta integración permitiría a los dispositivos ESPHome conectarse directamente a Gladys con la API nativa de ESPHome.
Existen soluciones para conectar tu ESP mediante MQTT, pero con la integración sería directo.
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é.
Buenas noches @pierre-gilles y @Will_71
Si puedo ser de alguna ayuda con ESPHome, estaré encantado de ayudarles.
Quiero agradecer una vez más muy calurosamente a @pierre-gilles por la pista dada sobre este tema, que me parece muy prometedora en mi caso.
¡Buen final de día,
Jean
¡Muy interesado también! Tengo varios módulos ESPHome en casa. MQTT funciona, pero la API nativa traería la detección mDNS y la creación automática de entidades. Con la llegada de las integraciones externas, ¿quizás es el momento adecuado? Voluntario para probar.
Analizado con la ayuda de Claude (IA), revisado y validado por mí.
Aquí está la imagen de desarrollo para la integración de esphome. No la he probado porque no tengo el material. Gracias de antemano por sus pruebas.
Resumen de la construcción de Docker
Imagen enviada (linux/amd64 + linux/arm64):
ghcr.io/william-de71/gladys-esphome:dev
Prueba esta construcción en Gladys
- En Gladys, abre Integrations → Install an integration → Developer mode.
- Copia el manifiesto a continuación (su
docker_imageya apunta a esta construcción):
{
"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.",
"es": "Controla tus dispositivos ESPHome (ESP32/ESP8266) localmente, a través de la API nativa."
},
"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",
"es": "Empezar"
},
"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.",
"es": "Esta integración se comunica con tus nodos ESPHome en tu red local, a través de su API nativa (puerto 6053). Pega tu clave de cifrado a continuación, luego ve a la pantalla de Descubrimiento y ejecuta un escaneo: los nodos encontrados en tu red aparecen allí con todas sus entidades, listos para ser añadidos. No es necesario escribir la dirección IP."
},
"links": [
{
"url": "https://esphome.io/components/api.html",
"label": {
"en": "ESPHome native API documentation",
"fr": "Documentation de l'API native ESPHome",
"es": "Documentación de la API nativa de ESPHome"
}
}
]
},
{
"key": "encryption_key",
"type": "secret",
"label": {
"en": "Encryption key",
"fr": "Clé de chiffrement",
"es": "Clave de cifrado"
},
"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.",
"es": "La clave base64 declarada bajo `api: encryption: key:` en tu YAML de ESPHome. Se utiliza para todos los nodos que no tienen una clave específica a continuación. Déjala vacía solo si tus nodos no tienen cifrado."
},
"placeholder": {
"en": "kBv1s2f...=",
"fr": "kBv1s2f...=",
"es": "kBv1s2f...="
},
"required": false
},
{
"key": "advanced",
"type": "section",
"label": {
"en": "Nodes with a different key",
"fr": "Nœuds avec une clé différente",
"es": "Nodos con una clave diferente"
},
"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).",
"es": "Rellena los dos campos siguientes solo si algunos nodos no comparten la clave anterior, o si un nodo no es encontrado por el escaneo de la red (otro VLAN, mDNS filtrado por tu router)."
}
},
{
"key": "encryption_keys",
"type": "secret",
"label": {
"en": "Keys per node",
"fr": "Clés par nœud",
"es": "Claves por nodo"
},
"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.",
"es": "Un nodo por línea, en la forma `nodo|clave`. El nombre del nodo es el de tu YAML de ESPHome (`esphome: name:`), o su dirección. Estas claves tienen prioridad sobre la clave anterior."
},
"placeholder": {
"en": "salon|kBv1s2f...=\nkitchen|9xQm4Zt...=",
"fr": "salon|kBv1s2f...=\ncuisine|9xQm4Zt...=",
"es": "salon|kBv1s2f...=\nkitchen|9xQm4Zt...="
},
"required": false
},
{
"key": "nodes",
"type": "string",
"label": {
"en": "Nodes added by hand",
"fr": "Nœuds ajoutés à la main",
"es": "Nodos añadidos manualmente"
},
"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.",
"es": "Una dirección por línea (`salon.local`, `192.168.1.42`, o `192.168.1.42:6053`), para los nodos que el escaneo de la red no encuentra. Los nodos encontrados por el escaneo no necesitan nada aquí."
},
"placeholder": {
"en": "salon.local\n192.168.1.42:6053",
"fr": "salon.local\n192.168.1.42:6053",
"es": "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)",
"es": "Duración del descubrimiento (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.",
"es": "Duración durante la cual el escaneo mDNS escucha los nodos ESPHome en la red."
},
"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)",
"es": "Tiempo de espera de conexión (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.",
"es": "Tiempo de espera para que un nodo responda antes de abandonarlo."
},
"required": false,
"default": 10,
"min": 5,
"max": 60
}
],
"actions": [
{
"key": "test_connection",
"label": {
"en": "Test the connection",
"fr": "Tester la connexion",
"es": "Probar la conexión"
},
"timeout_seconds": 60
},
{
"key": "reconnect",
"label": {
"en": "Reconnect the nodes",
"fr": "Reconnecter les nœuds",
"es": "Reconectar los nodos"
},
"timeout_seconds": 60
}
]
}
Hola @Will_71,
Gracias por esta integración 
¿Podrías, sin embargo, proporcionar más información sobre la configuración y el uso de esta integración, ya que parece que solo se dirige a los dispositivos WiFi (mencionas un puerto 6053).
En mi caso concreto, quería usar ESPHome en dispositivos Zigbee únicamente, por lo que temo que haya confusión por mi parte…
¡Que tengas una buena tarde,
Jean
Tú debes darme todos los casos de uso que tengas, porque yo no tengo dispositivos de ese tipo. Así que simplemente ejecuté Claude en ellos.
Por lo tanto, con tus casos de uso, podremos orientar a Claude.
¿En Zigbee? ¿No puedes integrarlos en Zigbee2MQTT? ¿Qué esperas de la integración entonces?
Acabo de encontrar un viejo dispensador de croquetas. La tarjeta electrónica probablemente esté HS, pero el motor aún funciona (si la memoria no me falla, sería de 9 V).
Quiero aprovechar la oportunidad para ponerlo en servicio de nuevo con un ESP8266 + ESPHome, controlando simplemente el motor ON/OFF, y sobre todo probar la integración de ESPHome actualmente en desarrollo para Gladys.
Ya tengo algunos ESP8266 por ahí, así que no necesito gran cosa para empezar.
También me encontré con este proyecto de pantalla e-ink integrada en la decoración: https://community.home-assistant.io/t/use-esphome-with-e-ink-displays-to-blend-in-with-your-home-decor/435428 — ¡me parece realmente muy chulo!
¿Podría este tipo de pantalla también utilizarse con Gladys a través de ESPHome?
Si alguien ya ha utilizado ESPHome con Gladys o tiene consejos para este tipo de bricolaje, ¡estoy interesado! 
Hola @b3n.0
Tus dos temas tienen respuestas bastante diferentes, los separo.
El distribuidor de croquetas: es el caso nominal, ya funciona. Un switch: en tu YAML ESPHome se envía directamente como un interruptor on/off en Gladys, sin nada que configurar. Para un motor de 9 V, ESP8266 + un módulo de relé (o un MOSFET si quieres silencio) y declaras:
switch:
- platform: gpio
pin: D1
name: "Distribuidor de croquetas"
id: motor
Un consejo: añade mejor un on_turn_on con un delay y luego apagado automático, esto evita dejar el motor girando si una escena Gladys falla. Y alimenta el motor por separado del ESP8266 — un motor que arranca hace caer la tensión y el ESP se reinicia.
Si pruebas esto, tu feedback me interesa enormemente: no tengo material ESPHome de mi lado, así que desarrollo a ciegas. Saber que el camino base funciona realmente en hardware real sería el feedback más útil que
pueda recibir.
La pantalla e-ink: muy buena pregunta, y la respuesta no es tan evidente como parece.
El punto a entender: en ESPHome, una pantalla no es una entidad. El componente display: es completamente local al firmware - es tu YAML el que dibuja, a través de lambdas. Nada se expone en la API nativa, por lo que no hay nada que Gladys pueda « descubrir » o controlar directamente.
El proyecto Home Assistant que mencionas funciona en realidad por ricochet: el firmware declara entidades de entrada que HA alimenta, y el lambda del display: lee estos valores para dibujar. No es HA el que controla la pantalla, es el ESP
el que lee los valores y se dibuja a sí mismo.
Y eso, es perfectamente factible con Gladys. Acabo de añadir el soporte de la entidad text en escritura para este caso específico (hasta ahora se ignoraba). El principio:
text:
- platform: template
name: "Mensaje pantalla"
optimistic: true
mode: text
id: mensaje_pantalla
display:
- platform: waveshare_epaper
# ... lambda: |-
it.printf(0, 0, id(mi_fuente), "%s", id(mensaje_pantalla).state.c_str());
Obtienes una característica de texto modificable en Gladys: escribes « Basura amarilla mañana », el ESP recibe la cadena y redibuja. Las escenas Gladys pueden alimentar la pantalla.
Nota: las entidades number: ya eran soportadas en escritura. Por lo tanto, si quieres mostrar valores numéricos, puedes empezar a experimentar de inmediato, sin esperar la próxima imagen.
Dos advertencias sobre el e-ink, para evitarte sorpresas: estas pantallas tienen un número limitado de actualizaciones completas y cada actualización tarda varios segundos — por lo que se actualiza por minuto o por evento, nunca en continuo. Y verifica que tu modelo esté en la lista waveshare_epaper de ESPHome antes de comprar, no todos están gestionados.
Si te lanzas, estoy interesado en tus comentarios — es exactamente el tipo de caso de uso concreto de la integración.
La imagen de prueba es la misma, si ya está instalada, basta con forzar la actualización.
Hola @Will_71
Gracias por tus dos respuestas y por el trabajo en la integración de ESPHome! 
Mientras buscaba proyectos de ESP, encontré la pantalla e-ink realmente muy cool. No tengo una a mano en este momento para probar este tipo de cosas, pero definitivamente guardaré la idea para más adelante. 
Y también gracias por tus consejos sobre el dispensador de croquetas.
Finalmente pude probar la integración de ESPHome
Como mencionaste que no tenías el equipo para probarla, usé un pequeño NodeMCU v2 ESP8266.
Instalé ESPHome Device Builder, creé un primer dispositivo test-esphome con la configuración estándar:
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:
Flashée el ESP en USB desde ESPHome Device Builder.
Se conecta correctamente al Wi-Fi y obtiene:
IP Address: 192.168.0.39
Hostname: test-esphome
Signal strength: -49 dBm
Mi Gladys está en 192.168.0.36.
Y ahí, después de ingresar la configuración en la integración de ESP Home, no se encuentra nada durante el escaneo.
Incluso intenté en un segundo momento agregar el nodo manualmente en la configuración:
192.168.0.39:6053
Otra información, los registros del ESP muestran claramente que Gladys puede conectarse a su API:
Accept 192.168.0.36
esphome-client (192.168.0.36): connected
Por lo tanto, la red y el puerto 6053 parecen estar bien.
Sin embargo, luego se vuelve bastante extraño:
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
Luego varios:
Reading failed CONNECTION_CLOSED errno=11
El ESP indica:
API:
Address: test-esphome.local:6053
Max connections: 4
Noise encryption: YES
El resultado final en Gladys sigue siendo:
No se ha descubierto ningún dispositivo por el momento.
Mientras que el ESP, por su parte, ve claramente a Gladys conectarse.
No sé si se pueden sacar conclusiones…
¡Gracias de nuevo por el desarrollo de esta integración!
Ok, te agradezco por la prueba. Tan pronto como un parche esté listo, te aviso
¡Muchas gracias!
Hola @b3n.0
Tu respuesta fue extremadamente útil, contenía exactamente las pistas correctas. Encontré el problema, y no era tu hardware, ni tu configuración, ni tu clave de cifrado. Tu instalación estaba bien desde el principio.
Lo que pasaba
Tu YAML test-esphome no declara ninguna entidad: api, ota, wifi, logger, y eso es todo. Es el YAML por defecto de ESPHome Device Builder, no hay nada que reprocharte.
Pero mi código descartaba pura y simplemente cualquier nodo que no expusiera ninguna funcionalidad utilizable. La conexión se realizaba perfectamente, como mostraban tus logs ESP (esphome-client (192.168.0.36): connected), el handshake cifrado pasaba sin problemas, pero el nodo era descartado justo después, en silencio. Resultado en Gladys: «Ningún dispositivo descubierto», imposible de distinguir de una mala clave o un ESP inalcanzable.
Por eso la adición manual de 192.168.0.39:6053 no cambiaba nada: el problema estaba después de la conexión, no a nivel de la detección de red.
El Max connections (4)
Tu segundo síntoma era un error distinto, que tu log permitió identificar. La biblioteca cliente que uso reintenta una conexión 3 veces por defecto, es decir 1 intento + 3 reintentos = 4 sockets. Y el firmware ESPHome acepta… exactamente 4 clientes API. Un solo escaneo fallido saturaba entonces todo el cupo de tu ESP, de ahí el rejecting y luego los CONNECTION_CLOSED errno=11. Reduje esto a 1 reintento (2 sockets máx.), lo que deja margen al nodo mientras absorbe un ESP en proceso de reinicio.
Corregido
- Un nodo accesible se reporta ahora siempre en Gladys, incluso sin ninguna entidad. Aparecerá sin funcionalidad, pero aparecerá, así sabrás que la conexión funciona.
- Ya no hay saturación de conexiones del ESP.
- El log se ha vuelto explícito y da directamente la acción a seguir:
El nodo ESPHome « test-esphome » (192.168.0.39:6053) es accesible pero no expone ninguna funcionalidad
Gladys puede usar (0 entidad(es) vista(s)): declarar una entidad (interruptor, sensor…) en su YAML
He añadido una prueba de regresión que reproduce tu caso específico, y he verificado que fallaba en el código antiguo, para que este escenario no pueda volver a pasar.
Para tu próxima prueba
Mientras tanto, puedes validar el camino completo añadiendo una entidad a tu YAML. Lo más simple, y es una coincidencia ya que es tu proyecto de distribuidor:
switch:
- platform: gpio
pin: D1
name: "Distribuidor de croquetas"
id: motor
Reflashas, y el interruptor debería aparecer directamente en Gladys. Es ese retorno el que me interesa ahora: saber si el comando on/off funciona realmente en hardware real. Siempre desarrollo sin tener un ESP a mano, así que tus pruebas son lo que hace avanzar esta integración.
Te aviso tan pronto como se publique la imagen de desarrollo.
La imagen de desarrollo está lista, solo tienes que forzar la actualización desde Gladys.
