Blog
Tutoriel ESP32 WiFiManager pour la configuration WiFi
Si vous avez déjà expédié un projet ESP32 avec des identifiants WiFi codés en dur, vous savez déjà ce qui va suivre. Cela fonctionne très bien sur votre banc de test, connecté à votre réseau domestique, puis il est expédié à un client, dans un autre bâtiment, ou un autre pays, et soudain, il devient une brique jusqu'à ce que quelqu'un le re-flash. C'est l'un des problèmes les plus courants dans le développement de produits IoT, et c'est aussi l'un des plus évitables. C'est précisément le problème que WiFiManager a été conçu pour résoudre.
Alors, entrons dans le vif du sujet : qu'est-ce que c'est, comment cela fonctionne-t-il réellement en coulisses, et comment pouvez-vous le faire fonctionner dans votre propre projet ESP32, en commençant par une vérification d'installation rapide et en progressant vers le type d'installation que vous souhaiteriez réellement déployer.
Pourquoi les identifiants codés en dur ne suffisent pas
Nous avons tous écrit cette ligne à un moment donné :
WiFi.begin("MyHomeNetwork", "password123");
Et pour bricoler sur l'établi, il n'y a rien de mal à cela. Mais le moment où votre projet doit quitter l'établi, cette approche commence à causer de réels problèmes :
- Aucune flexibilité pour celui qui l'utilise. Celui qui déploie l'appareil doit connaître le SSID et le mot de passe exacts avant même de le flasher, sinon vous aurez besoin d'un accès physique ultérieurement juste pour modifier un paramètre.
- Cela représente un risque de sécurité. Les identifiants codés en dur dans le firmware se trouvent là en texte clair, prêts à être découverts par quiconque désassemblerait le binaire.
- Cela ne passe pas à l'échelle. Vous avez dix unités destinées à dix sites différents ? Cela implique dix compilations de micrologiciels différentes, ou une quantité considérable de reconfigurations manuelles.
Ce que nous voulons vraiment, c'est que l'appareil demande simplement à l'utilisateur final ses informations WiFi, les enregistre et se reconnecte automatiquement à chaque démarrage sans que nous ayons jamais à toucher au code. C'est la lacune que WiFiManager comble, et il le fait très bien.
Qu'est-ce que WiFiManager
WiFiManager est une bibliothèque open-source, initialement écrite par tzapu et maintenant maintenue par tablatronix, qui offre à votre projet ESP32 (ou ESP8266) un moyen autonome et basé sur le web pour configurer le WiFi. Au lieu de coder en dur les identifiants, l'appareil démarre en mode Point d'Accès, diffuse son propre petit réseau WiFi et propose une page web simple où l'utilisateur peut choisir son réseau dans une liste scannée et saisir le mot de passe.
Une fois que l'utilisateur clique sur "Enregistrer", WiFiManager écrit les identifiants dans la mémoire flash et tente de s'y connecter. Par la suite, à chaque démarrage de l'appareil, il essaie d'abord les identifiants enregistrés et ne revient au mode configuration que si la connexion échoue. L'ensemble de ce schéma est appelé portail captif, et vous l'avez très certainement déjà rencontré : c'est le même mécanisme qui affiche une page de connexion dès que vous vous connectez au WiFi d'un hôtel ou d'un aéroport.
Comment fonctionne ESP32 WiFiManager
Le Fondement : Modes WiFi ESP32
La radio 2,4 GHz de l'ESP32 peut fonctionner selon trois modes différents :
- Mode Station (STA) : L'ESP32 agit comme un client WiFi normal, se connectant à votre routeur tout comme votre ordinateur portable ou votre téléphone.
- Mode Point d'Accès (AP) : L'ESP32 crée son propre réseau, permettant ainsi à d'autres appareils de s'y connecter directement.
- Mode Double (AP+STA) : et c'est là que cela devient astucieux — l'ESP32 peut diffuser son propre réseau tout en analysant ou en se connectant simultanément à un autre routeur.
Lorsque l'appareil démarre dans un nouvel emplacement sans identifiants enregistrés, WiFiManager le bascule en mode AP et commence à diffuser un SSID – quelque chose comme ESP32-Setup. Cela permet à votre téléphone d'accéder à l'appareil : un pont direct vers le matériel avant qu'il n'ait jamais touché Internet.
L'Interception : redirection DNS
Alors, votre téléphone a rejoint le réseau de l'ESP32. Comment pouvons-nous l'acheminer vers la page de configuration sans qu'une personne ait à saisir manuellement une adresse IP ? Nous piratons le DNS.
Normalement, lorsque vous tapez une URL dans votre navigateur, un serveur DNS la traduit en une adresse IP en arrière-plan. Pendant sa phase de configuration, l'ESP32 exécute son propre micro-serveur DNS – sauf qu'au lieu de répondre correctement, il répond à chaque requête avec sa propre adresse, généralement 192.168.4.1. Peu importe que votre téléphone demande google.com ou autre chose ; la réponse est toujours “ moi ”.”
Le Piège : Les Portails Captifs
Cette astuce DNS est précisément ce qui rend la magie du portail captif possible. Vous l'avez déjà vue, probablement sans vous en rendre compte : en vous connectant au Wi-Fi d'un aéroport ou d'un hôtel.
Les téléphones et ordinateurs portables modernes vérifient automatiquement, au moment où ils se connectent à un nouveau réseau, si ce réseau nécessite une connexion. Les appareils Apple, par exemple, interrogent discrètement une adresse spécifique en arrière-plan pour le savoir. Étant donné que notre ESP32 intercepte chaque requête DNS, il capte également cette vérification en arrière-plan. Au lieu de la réponse attendue, il renvoie notre page de configuration HTML personnalisée. Le système d'exploitation du téléphone le voit et ouvre une fenêtre de navigateur sur-le-champ. Personne n'a à chercher une adresse IP ; elle s'affiche directement.
Mise en attente : Stockage non volatil (NVS)
Une fois que quelqu'un saisit ses détails WiFi et clique sur “ Enregistrer ”, l'ESP32 a besoin d'un moyen de s'en souvenir, même après la coupure de courant.
Les anciennes cartes s'appuyaient sur l'EEPROM pour cela, mais l'ESP32 utilise quelque chose de plus récent appelé NVS, ou Non-Volatile Storage. Pensez-y comme à un simple magasin clé-valeur, logé dans sa propre partition dédiée de mémoire flash.
Le SSID et le mot de passe sont enregistrés en tant que chaînes de caractères sous des clés spécifiques. Lors du prochain démarrage de l'appareil, le firmware vérifie d'abord la NVS et, s'il trouve des données valides, il saute toute la procédure de point d'accès et se connecte silencieusement en mode Station. Pas de portail, pas de tracas, juste un démarrage normal.
Contraintes professionnelles : considérations relatives à la mémoire
Voici une comparaison utile : c'est un peu comme appliquer les règles de conception pour la fabrication à la disposition d'un circuit imprimé pour économiser de l'espace sur la carte. Vous devez gérer la mémoire de votre micrologiciel de la même manière minutieuse.
Faire fonctionner simultanément un point d'accès, un serveur web et un serveur DNS consomme une part importante de la RAM de l'ESP32. Laisser ces services actifs une fois que vous êtes déjà connecté prive votre application réelle de la mémoire dont elle pourrait avoir besoin.
La meilleure approche pour tout élément entrant en production consiste à désactiver ces services de configuration dès que vous avez établi une connexion réussie. Arrêtez les serveurs web et DNS, libérez leurs ressources une fois que `autoConnect()` a retourné, et récupérez ainsi la mémoire pour les activités véritablement importantes : échantillonnage des capteurs, exécution de l'inférence, gestion de l'alimentation, tout ce dont votre projet a besoin.
Comment installer WiFiManager sur ESP32
Si vous utilisez l'IDE Arduino ou PlatformIO, l'installation est sans douleur.
IDE Arduino : ouvrez le gestionnaire de bibliothèques (Croquis > Inclure la bibliothèque > Gérer les bibliothèques), recherchez “WiFiManager by tzapu” et installez la dernière version, actuellement 2.0.17.
- Cliquez sur le gestionnaire de bibliothèques
- Tapez WiFiManager et installez WiFiManager par tzapu
Avant de commencer à câbler des paramètres personnalisés et la persistance NVS, il est judicieux de confirmer d'abord que le strict minimum fonctionne. La bibliothèque fournit un exemple qui fait précisément cela, recherchez Fichier > Exemples > WiFiManager > Basic.
Connectez-vous à cela, et en supposant qu'il n'y ait pas de réseau enregistré, votre téléphone devrait immédiatement proposer de rejoindre “ ESP32-Setup ” et la page de configuration devrait apparaître immédiatement. Une fois que vous aurez confirmé que cela fonctionne, vous serez prêt à construire la version complète.
Une chose à savoir : il existe une poignée de forks de WiFiManager dans l'écosystème, certains avec des correctifs supplémentaires spécifiques à l'ESP32 intégrés. Ainsi, si vous rencontrez des problèmes de compatibilité sur un cœur ESP32 plus récent, il convient de vérifier exactement quel fork vous avez réellement récupéré.
Mise en place d'un WiFiManager ESP32 prêt pour la production
Un appel `autoConnect()` simple est idéal pour prouver le concept, mais un déploiement réel nécessite généralement un peu plus : des champs personnalisés tels qu'une adresse de serveur MQTT, un moyen d'effacer les identifiants enregistrés sans re-clignoter le module, et un délai d'expiration raisonnable pour que l'appareil ne reste pas indéfiniment en mode configuration, ce qui consommerait la batterie.
Voici un schéma complet qui gère les trois, construit autour de trois éléments travaillant ensemble.
- Gestion de la mémoire. Au lieu de disséminer les lectures et écritures de la mémoire flash dans toute la fonction setup(), nous les avons regroupées dans des fonctions d'assistance loadConfig() et saveConfig(). De cette façon, il est immédiatement évident, d'un seul coup d'œil, quelles parties du code accèdent au stockage persistant.
- Le mécanisme de secours. Avant de toucher au WiFi, nous vérifions d'abord un bouton de réinitialisation physique. Ceci est plus important qu'il n'y paraît : si la pile WiFi venait à se bloquer ultérieurement, un utilisateur sans autre recours aurait besoin d'une voie de sortie garantie. La vérification des surcharges matérielles avant toute chose signifie que ce chemin ne pourra jamais être bloqué par ce qui vient après :
- Le flux de configuration. Le flux lui-même est agréable et linéaire : charger ce qui est sauvegardé, le transmettre au portail comme valeurs par défaut, tenter de se connecter, et cette partie est importante : écrire uniquement dans la mémoire flash si l'utilisateur a effectivement modifié quelque chose. Il est inutile de gaspiller un cycle d'écriture flash pour réenregistrer ce qui était déjà là :
En combinant le tout, vous obtenez un flux d'approvisionnement complet et autonome : il vérifie un réinitialisation manuelle, charge ce qui est déjà enregistré, permet à l'utilisateur de le visualiser et de le remplacer via un portail captif, se connecte, et ne conserve que ce qui a effectivement changé. Aucun service cloud, aucune application compagnon et rien en dehors de l'appareil lui-même.
Pièges courants de ESP32 WiFiManager
Quelques éléments posent souvent problème avec WiFiManager et méritent d'être signalés avant que vous ne les rencontriez vous-même :
- Le portail captif n'apparaît pas toujours automatiquement. Certaines versions d'Android et les téléphones gérés par l'entreprise retardent ou désactivent cette détection. Affichez toujours l'adresse IP du portail (192.168.4.1 par défaut) sur la console série, afin que quelqu'un puisse y accéder manuellement si le pop-up ne s'affiche jamais.
- autoConnect() bloque par défaut. Tant que l'appareil reste en mode AP, le reste de votre code setup() ne s'exécutera pas. Si vous avez besoin que d'autres actions se produisent pendant le provisionnement, envisagez plutôt le mode non bloquant de WiFiManager.
- Les NVS peuvent être corrompus après une mise à jour du cœur. La mise à jour du cœur Arduino ESP32 décale parfois la disposition de la partition NVS, et les anciens identifiants commencent à être lus comme des données incohérentes. Une réinitialisation propre des NVS, ou un appel défensif à `resetSettings()` lors d'une connexion échouée, est plus sûr que de supposer que les anciennes données sont toujours valides.
- Protégez votre point d'accès par mot de passe. Par défaut, ce réseau de configuration est complètement ouvert. Toute personne à proximité peut s'y connecter et voir ou modifier vos paramètres WiFi. Passez un mot de passe comme deuxième argument à autoConnect() et cette porte se ferme.
Le WiFiManager est-il adapté à votre projet ESP32
Pour la plupart des projets grand public et des produits commerciaux en petites séries, WiFiManager atteint un juste milieu très appréciable : aucune dépendance externe, un flux de configuration que les gens comprennent déjà à partir du WiFi des hôtels et des aéroports, et à peine quelques lignes de code à intégrer.
Cependant, cela ne convient pas à toutes les situations. Pour les déploiements industriels sans tête, imaginons un appareil fixé à un mur sans écran et sans accès physique facile, il est probablement préférable d'opter pour un réseau de repli codé en dur, complété par une voie de provisionnement à distance via BLE ou une API backend, plutôt que de compter sur quelqu'un pour s'approcher et connecter son téléphone au point d'accès de l'appareil. Et si vous travaillez déjà avec ESP-IDF plutôt qu'avec Arduino, il est intéressant de comparer cela au provisionnement WiFi natif d'Espressif, qui ajoute un provisionnement basé sur BLE à côté de l'approche habituelle SoftAP/portail captif et s'intègre généralement plus naturellement dans une base de code IDF existante.
Cependant, pour tout ce qui se situe entre les projets de fabrication, les petites startups matérielles, le problème “ cet appareil doit fonctionner chez dix clients différents sans dix builds de firmware différents ’, WiFiManager reste l'une des méthodes les plus simples et les plus éprouvées pour résoudre le provisionnement WiFi sur l'ESP32.
Pensées finales
Ceci conclut ce tutoriel ESP32 WiFiManager. Une fois la configuration de base opérationnelle, les identifiants WiFi codés en dur ne devraient plus faire partie de votre flux de déploiement ESP32.
Si vous rencontrez des problèmes lors de la création d'un produit IoT basé sur ESP32, vous pouvez toujours discuter de votre projet avec PCBCool. Nous avons également récemment lancé un Système de devis en ligne, ce qui facilite l'obtention de devis pour les projets de PCB et de PCBA tant pour les entreprises que pour les fabricants. Si vous avez un projet connexe, n'hésitez pas à l'essayer.
FAQ
La raison principale est que chaque couche ajoutée rend le processus de fabrication plus difficile à contrôler. Plus il y a de couches, plus il y a de risques de défauts dans les couches internes, de problèmes d'alignement, de difficultés de laminage et de rebut.
Les pastilles BGA sont petites et espacées de près, de sorte que de petites erreurs de fabrication peuvent facilement devenir des problèmes d'assemblage.
Sam K travaille sur des systèmes électroniques embarqués, avec un accent particulier sur la conception matérielle, le développement de circuits imprimés (PCB), la programmation de firmware, et l'intégration système. Il soutient également l'optimisation des performances et contribue à transformer les idées de produits électroniques en solutions fiables et concrètes.
