ESPHome

ESPHome transforme une carte ESP32, ESP8266 ou RP2040 en appareil domotique sur mesure, à partir d’un fichier YAML plutôt que de C++. Vous décrivez capteurs, broches GPIO et comportement voulu ; ESPHome compile et flashe un vrai binaire de firmware sur la puce. L’appareil parle ensuite à Home Assistant via l’API native d’ESPHome, sans broker MQTT séparé sauf besoin spécifique.

Du fichier YAML au firmware compilé

Chaque appareil ESPHome démarre avec un fichier YAML : type de carte, identifiants Wi-Fi, liste de composants (un DHT22 sur une broche, un relais, un écran OLED, un contact de porte). ESPHome génère le C++ en arrière-plan et le transmet à PlatformIO pour compiler un binaire propre à la puce. Vous n’ouvrez ce code qu’en cas d’erreur, et le message pointe généralement vers une coquille YAML. C’est l’inverse de Tasmota (détaillé plus bas) : un seul binaire précompilé flashé partout, configuré après coup via le web.

La bibliothèque de composants couvre l’essentiel : température, humidité, relais, variateurs, écrans e-ink et OLED, PIR, qualité de l’air, même des caméras ESP32. Chaque nouveau composant, c’est un bloc de config en plus, pas une réécriture ; le même YAML peut cibler un tout autre matériel en changeant juste la ligne board.

Installer ESPHome

Deux chemins couvrent presque tout le monde. Sous Home Assistant OS ou Supervised, l’add-on ESPHome s’installe en deux clics depuis le magasin d’applications, sans terminal. Pour tous les autres (Container, autonome), l’image Docker officielle est la voie à suivre :

services:
  esphome:
    container_name: esphome
    image: ghcr.io/esphome/esphome
    restart: unless-stopped
    volumes:
      - /path/to/your/config:/config
      - /etc/localtime:/etc/localtime:ro
    network_mode: host

docker compose up -d

1. Le mode réseau host est le plus simple sous Linux, pour détecter les appareils en ligne/hors ligne via ping. Sous macOS, Docker Desktop ne gère pas le mode host : mappez -p 6052:6052 et définissez ESPHOME_DASHBOARD_USE_PING=true.
2. Ouvrez http://ip-de-votre-serveur:6052 : le tableau de bord liste chaque appareil créé, avec son YAML sous /config.
3. Cliquez sur « New device », choisissez une carte (ESP32, ESP8266, RP2040, et d’autres) ; le tableau de bord génère un YAML de départ avec Wi-Fi et API configurés.
4. Ajoutez des composants en éditant le YAML, ou via l’éditeur intégré avec validation en direct.

Flashage : USB la première fois, OTA ensuite

Le premier flashage se fait obligatoirement par USB : aucun ESP32 vierge ne parle déjà OTA en sortie d’usine. Branchez la carte sur la machine qui héberge le tableau de bord (ou via le flasher navigateur sur un serveur headless), cliquez sur « Install », choisissez le port USB. ESPHome compile puis pousse le firmware en série via esptool. La plupart des cartes se flashent sans accroc ; le souci le plus courant reste un câble USB sans données, ou un bouton BOOT à maintenir pendant la négociation.

Chaque flashage suivant passe par OTA. Modifiez le YAML, recliquez sur « Install », et ESPHome pousse un nouveau binaire vers l’IP de l’appareil en Wi-Fi, sans câble ni accès physique. C’est ce qui rend ESPHome viable au-delà de deux ou trois appareils : un capteur encastré reste en place pour chaque futur changement.

Intégration native avec Home Assistant, pas MQTT par défaut

ESPHome embarque sa propre API native, une connexion TCP persistante en protocole binaire compact : la voie par défaut vers Home Assistant, pas MQTT. Ajoutez un appareil une fois, auto-découvert ou par IP, et chaque entité apparaît sans toucher configuration.yaml. Les états remontent dès qu’ils changent, sans polling ; l’appareil agit comme son propre serveur plutôt qu’un client dépendant d’un broker. MQTT reste utile quand plusieurs systèmes (Home Assistant, Node-RED, InfluxDB) veulent la même lecture en même temps ; l’API native, elle, ne parle qu’à Home Assistant.

Cette connexion native, c’est aussi ce qui permet à Node-RED d’accéder aux appareils ESPHome : le paquet node-red-contrib-home-assistant-websocket récupère automatiquement les appareils ESPHome dès qu’ils sont ajoutés à Home Assistant, sans nœud dédié.

ESPHome vs Tasmota

Tasmota est l’autre grand firmware ESP open source ; les deux résolvent le même problème dans des sens opposés. Tasmota flashe un seul binaire précompilé, configuré ensuite via interface web ou MQTT, sans compilation. ESPHome compile un binaire sur mesure par appareil depuis votre YAML. Tasmota gagne en rapidité pour une prise générique ; ESPHome devient rentable dès que les appareils se multiplient, la config vivant dans un texte versionnable.

	ESPHome	Tasmota
Modèle de configuration	YAML, compilé en un binaire par appareil	Binaire générique unique, configuré via interface web/console
Intégration Home Assistant	API native, ajout en un clic, pas besoin de MQTT	Basée sur MQTT, broker et config de découverte requis
Profondeur de personnalisation	Élevée, tout composant supporté sur toute broche en YAML	Bonne pour les appareils supportés, le sur-mesure exige une vraie compilation
Chemin de mise à jour	OTA, recompile et pousse automatiquement	OTA, flashe un nouveau binaire précompilé
Licence	MIT (Python) + GPLv3 (runtime C++)	GPLv3

ESPHome : avantages et inconvénients

• Pas besoin de C++ pour la quasi-totalité des cas d’usage ; le YAML couvre des centaines de composants
• API native Home Assistant : remontées d’état instantanées, zéro broker MQTT à maintenir
• OTA après le premier flashage, aucun accès physique requis pour un appareil encastré
• Soutenu par l’Open Home Foundation, la même association que Home Assistant : pas un projet solo

• Le premier flashage exige toujours un câble USB et une connexion série qui fonctionne
• Compiler prend un vrai temps : secondes pour un petit changement, plus pour un premier build
• Ancres et packages YAML aident, mais gérer une dizaine d’appareils demande plus d’entretien que Tasmota
• Suppose une aisance avec les brochages GPIO ; la mauvaise broche est un écueil fréquent au démarrage

FAQ

Est-ce qu’ESPHome est gratuit ?

Oui, gratuit et open source : MIT pour le code Python, GPLv3 pour le runtime C++ embarqué. Pas de palier payant, pas de compte requis.

Faut-il connaître le C++ pour utiliser ESPHome ?

Non, pas pour la majorité des appareils : ESPHome génère le C++ depuis votre YAML. Écrire du C++ brut ne s’impose que pour des composants vraiment sur mesure, absents de la bibliothèque.

ESPHome a-t-il besoin de MQTT pour fonctionner avec Home Assistant ?

Non. La voie par défaut est l’API native, ajoutée directement dans Home Assistant sans broker. MQTT reste une option, utile quand d’autres systèmes ont besoin de la même donnée.

ESPHome appartient-il à Nabu Casa ?

Plus maintenant. Nabu Casa a racheté ESPHome à son créateur Otto Winter en 2021, puis en a fait don à l’Open Home Foundation en 2024, qui gouverne aussi Home Assistant. Nabu Casa reste un soutien commercial, sans posséder ESPHome.

Faut-il choisir ESPHome ou Tasmota ?

Si Home Assistant est le seul consommateur de vos données et que vous aimez les configs en texte, ESPHome convient mieux. Tasmota garde son intérêt pour un flashage rapide de prise générique, ou si vous êtes déjà dans du MQTT existant.

ESPHome vaut le détour dès que vous voulez un capteur ou interrupteur qui n’existe pas en version commerciale, ou remplacer le firmware cloud d’une prise connectée par quelque chose de local. Associez-le à Home Assistant pour le tableau de bord, et à Node-RED une fois vos flows plus complexes que l’éditeur intégré. Notre guide auto-hébergement homelab couvre le matériel de base avant le flashage de microcontrôleurs.