Sommaire

ESPHome ou Arduino IDE : pourquoi je migre mes projets ESP32 simples vers ESPHome

Pendant longtemps, lorsqu’un nouveau projet à base d’ESP8266 ou d’ESP32 me venait en tête, le réflexe était simple : ouvrir Arduino IDE, créer un nouveau sketch et commencer à coder.

Connexion au Wi-Fi, lecture du capteur, gestion des erreurs, reconnexion, envoi des données, OTA…

Ça fonctionne très bien. Et Arduino IDE reste un excellent outil.

Mais avec le temps, je me suis posé une question toute simple :

Est-ce que j’ai vraiment besoin de recoder tout ça pour chaque petit projet ?

Pour beaucoup de projets simples, et même intermédiaires, ma réponse est maintenant : non.

Et c’est là qu’ESPHome devient particulièrement intéressant.

ESPHome ne remplace pas Arduino

Commençons par quelque chose d’important : je ne pense absolument pas qu’ESPHome puisse remplacer Arduino, PlatformIO ou ESP-IDF dans tous les projets.

Ce serait même une erreur de le présenter ainsi.

ESPHome répond surtout à un autre besoin : décrire ce que l’on souhaite faire et laisser ESPHome générer toute la plomberie autour.

Capteurs, boutons, relais, GPIO, I²C, SPI, Wi-Fi, logs, API, mises à jour OTA…

Au lieu de tout programmer en C++, une grande partie peut être déclarée dans quelques lignes de YAML.

ESPHome génère ensuite le firmware correspondant. Son Device Builder permet d’ailleurs de créer, modifier, compiler et installer les configurations directement depuis une interface Web. (ESPHome – Smart Home Made Simple)

Et pour beaucoup de mes petits montages, c’est exactement ce dont j’ai besoin.

Prenons un projet tout bête

Imaginons :

• un ESP32 ;
• un capteur de température ;
• un relais ;
• quelques informations à faire remonter ;
• et éventuellement Home Assistant derrière.

Avec Arduino, il faut commencer à gérer les bibliothèques, la connexion Wi-Fi, la reconnexion en cas de coupure, le capteur, les échanges réseau, l’OTA, etc.

Avec ESPHome, on se rapproche davantage de ceci :

sensor:
  - platform: dht
    pin: GPIO4
    temperature:
      name: "Température"
    humidity:
      name: "Humidité"

switch:
  - platform: gpio
    pin: GPIO5
    name: "Relais"

api:

ota:
  - platform: esphome

Évidemment, un véritable fichier contiendra quelques paramètres supplémentaires.

Mais l’idée est là.

Je décris ce que possède mon appareil plutôt que de réécrire toute l’infrastructure nécessaire à son fonctionnement.

Si vous avez Home Assistant, le choix devient encore plus évident

C’est probablement le cas où ESPHome devient le plus intéressant.

ESPHome possède une API native permettant de communiquer directement avec Home Assistant. Une fois l’API activée, les capteurs, interrupteurs et autres entités peuvent être découverts et intégrés directement dans Home Assistant. (ESPHome – Smart Home Made Simple)

Plus besoin de construire soi-même tout le système permettant de faire remonter une température ou l’état d’une entrée.

Vous ajoutez un capteur dans ESPHome => Vous compilez => Vous poussez la mise à jour.

Et votre nouvelle information se retrouve dans Home Assistant.

Pour de la domotique, cela permet de passer beaucoup plus de temps sur le projet lui-même et beaucoup moins sur le code nécessaire pour transporter une valeur d’un point A à un point B.

L’OTA devient presque transparent

Autre chose dont il devient rapidement difficile de se passer : les mises à jour OTA.

Le premier flash d’un ESP nécessite généralement de sortir le câble USB.

Mais une fois l’appareil installé, ESPHome permet d’envoyer les mises à jour suivantes directement par le réseau. Le protocole OTA natif ESPHome est notamment celui utilisé par le Device Builder et la ligne de commande. (ESPHome – Smart Home Made Simple)

Et ça paraît être un petit détail… jusqu’au jour où votre ESP se trouve :

• dans les combles ;
• derrière un meuble ;
• dans un coffret électrique ;
• dans le garage ;
• ou à 300 kilomètres de chez vous.

Plus besoin de démonter le boîtier simplement parce que l’on souhaite modifier une temporisation de 30 à 20 secondes.

On modifie le YAML, on compile et on pousse la nouvelle version.

ESPHome permet également d’ajouter une mise à jour directement depuis l’interface Web du périphérique avec web_server et la plateforme OTA correspondante. Le firmware peut alors être sélectionné dans le navigateur et envoyé au microcontrôleur. (ESPHome – Smart Home Made Simple)

web_server:
  port: 80

ota:
  - platform: esphome
  - platform: web_server

Il faut évidemment sécuriser cette interface avec une authentification si elle est utilisée. La documentation ESPHome déconseille explicitement d’autoriser les mises à jour Web sans authentification. (ESPHome – Smart Home Made Simple)

Mettre à jour un ESP même lorsqu’on n’est pas sur place

C’est peut-être l’un des points que je préfère.

Imaginez avoir installé un ESP chez vos parents ou vos grands-parents.

Quelques semaines plus tard, vous trouvez un bug ou souhaitez simplement ajouter une fonctionnalité.

Avec un firmware Arduino classique, on imagine déjà la scène :

« Ne touche à rien, j’apporterai mon ordinateur et mon câble USB la prochaine fois que je passe. »

Avec ESPHome, si le réseau distant est accessible de manière sécurisée, par exemple grâce à un VPN ou Tailscale, le Device Builder peut pousser la nouvelle version OTA sans aucune intervention physique.

Même chose si vous êtes vous-même en vacances et souhaitez mettre à jour un appareil chez vous.

Il faut tout de même être précis : ESPHome n’est pas un service cloud permettant magiquement d’accéder à tous vos ESP depuis Internet.

L’appareil doit être joignable depuis votre réseau.

Un VPN est donc une solution bien plus propre que d’exposer directement son interface Web ou son port OTA sur Internet.

Mais une fois cette connexion mise en place, le confort devient difficile à abandonner.

Une interface Web pour gérer ses appareils

C’est également l’une des différences qui change ma façon de travailler.

ESPHome Device Builder centralise les configurations dans une interface Web : création d’un appareil, modification du YAML, compilation et installation du firmware. (ESPHome – Smart Home Made Simple)

Je n’ai plus forcément besoin de lancer un IDE complet simplement pour modifier trois paramètres.

Arduino IDE reste relativement léger, mais dès que l’on commence à utiliser un environnement de développement plus complet comme PlatformIO, ouvrir tout l’environnement pour modifier une petite valeur paraît parfois disproportionné.

Avec ESPHome, je peux ouvrir le navigateur, modifier :

update_interval: 30s

en :

update_interval: 10s

puis relancer la compilation et envoyer la mise à jour.

C’est particulièrement agréable pendant la phase de prototypage.

Modifier → compiler → envoyer → tester → recommencer.

Les itérations deviennent extrêmement rapides.

Le portail captif : un autre petit détail qui change tout

La configuration du Wi-Fi est également simplifiée.

ESPHome dispose d’un portail captif de secours.

Si le périphérique n’arrive plus à rejoindre le réseau Wi-Fi configuré, il peut créer son propre point d’accès. Après connexion à celui-ci, une petite interface Web permet notamment de modifier les paramètres Wi-Fi et même d’envoyer un nouveau firmware. (ESPHome)

Sa configuration tient pratiquement à ceci :

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  ap:
    ssid: "Mon ESP - Secours"
    password: !secret fallback_password

captive_portal:

Encore une fois, ce n’est pas quelque chose d’impossible à faire avec Arduino.

On peut parfaitement développer son propre portail captif.

Mais justement…

Pourquoi le redévelopper pour chaque projet ?

C’est toute la philosophie qui me fait aujourd’hui préférer ESPHome pour ces petits montages.

Quelques lignes plutôt que beaucoup de plomberie

Ce que me fait surtout gagner ESPHome, ce n’est pas la possibilité de faire quelque chose qu’Arduino serait incapable de faire.

Arduino peut faire pratiquement tout ce que je viens de citer.

Le gain est ailleurs :

ESPHome fournit déjà tout ce dont j’ai besoin dans 80 % de mes petits projets.

Je peux alors passer mon temps à réfléchir au fonctionnement du projet plutôt qu’à réécrire :

• la connexion Wi-Fi ;
• la reconnexion ;
• l’OTA ;
• le serveur Web ;
• le portail captif ;
• les logs ;
• les échanges avec Home Assistant ;
• la lecture standard des capteurs.

Pour un prototype ou un petit montage personnel, le gain de temps est énorme.

Et si le YAML ne suffit plus ?

C’est également une raison pour laquelle je trouve ESPHome intéressant pour des projets intermédiaires, et pas seulement pour allumer une LED.

On peut intégrer directement du C++ à travers les lambda.

Par exemple :

lambda: |-
  if (id(temperature).state > 30) {
    return true;
  }
  return false;

On peut donc commencer avec une configuration extrêmement simple puis ajouter progressivement de la logique personnalisée.

Et pour aller encore plus loin, ESPHome permet également de développer ses propres composants.

La progression peut donc devenir :

YAML → YAML + lambda C++ → composant personnalisé → firmware entièrement spécifique si nécessaire.

On n’est pas forcément bloqué dès que le projet dépasse les possibilités d’un composant standard.

Alors, ESPHome ou Arduino ?

Ma règle personnelle ressemble maintenant à ceci :

Type de projet	Mon choix	Pourquoi ?
Capteur température/humidité	ESPHome	Quelques lignes
Relais connecté	ESPHome	Simple et rapide
Détecteur de présence	ESPHome	Intégration immédiate
Station météo	ESPHome	Capteurs déjà supportés
Projet Home Assistant	ESPHome	API native
Compteur énergie	ESPHome	Remontées simplifiées
Bluetooth Proxy	ESPHome	Quasiment prêt à l’emploi
Petit écran avec quelques valeurs	ESPHome	Suffisant dans beaucoup de cas
Plusieurs ESP similaires	ESPHome	Configurations réutilisables
Prototype rapide	ESPHome	Itérations très rapides
Logique personnalisée légère	ESPHome + lambda	YAML + C++
Matériel/protocole particulier	ESPHome + composant custom	Encore extensible
Robot autonome complexe	Arduino / PlatformIO	Logique spécifique
Traitement temps réel	ESP-IDF / C++	Contrôle précis
Gros traitement local	Arduino / PlatformIO / ESP-IDF	Plus adapté
Firmware très spécifique	Firmware custom	Contrôle total

Quand je continuerais à utiliser Arduino ou PlatformIO

Il ne faut donc pas enterrer Arduino pour autant.

Dès qu’un projet commence à nécessiter énormément de logique personnalisée, des contraintes de timing précises, des interruptions complexes, une gestion très fine des ressources ou un protocole exotique, je préfère reprendre le contrôle du firmware.

Même chose pour un robot autonome, un appareil qui réalise énormément de traitements localement ou un projet qui n’a tout simplement rien à voir avec la domotique.

Et pour apprendre l’électronique embarquée, Arduino reste également extrêmement intéressant.

Comprendre une boucle principale, les GPIO, les interruptions, I²C, SPI ou la gestion de la mémoire est important.

ESPHome masque volontairement une partie de cette complexité.

C’est justement ce qui le rend aussi pratique… mais cela peut aussi devenir son défaut lorsqu’on veut comprendre précisément ce qui se passe sous le capot.

ESPHome me permet surtout de terminer mes projets

Et finalement, c’est peut-être l’argument le plus important.

Comme beaucoup de personnes qui bricolent de l’électronique, j’ai une quantité assez impressionnante d’idées et de projets qui commencent par :

« Ça devrait être assez rapide à faire… »

Puis il faut gérer le Wi-Fi.

Puis MQTT.

Puis une reconnexion.

Puis l’OTA.

Puis une page de configuration.

Puis Home Assistant.

Et le petit projet de deux heures commence tranquillement à prendre tout le week-end.

ESPHome retire une grande partie de cette plomberie.

Je branche le capteur, je le déclare, je teste et je peux rapidement obtenir quelque chose de fonctionnel.

Pour moi, c’est donc là que se situe réellement la différence.

Arduino me permet de programmer exactement le firmware que je veux.

ESPHome me permet souvent de réaliser beaucoup plus rapidement le projet dont j’ai besoin.

Pour un gros projet embarqué, je continuerai à sortir Arduino, PlatformIO ou directement ESP-IDF.

Mais pour un ESP32 qui doit lire quelques capteurs, commander quelques sorties et communiquer avec Home Assistant ?

Aujourd’hui, je commence généralement par ouvrir ESPHome.