[Interface Température] Mise à jour du firmware par web serveur

[Devdevdavid]

Problème

La mise à jour par OTA permet d'envoyer un nouveau firmware au module par liaison wifi.
Toutefois, cette technique nécessite un logiciel particulier sur un PC pour envoyer le fichier firmware.
L'utilisateur final n'est donc pas en mesure de mettre à jour son module s'il n'a pas les connaissances suffisantes pour installer et utiliser le-dit logiciel.

Solution proposée

Il serait possible de proposer à l'utilisateur de mettre à jour son module au travers du web serveur embarqué. Il pourrait alors réaliser cette opération depuis n'importe qu'elle plateforme ou appareil connecté au même réseau wifi.

Seul un fichier binaire devra être envoyé à l'utilisateur pour qu'il se débrouille.

Points d'attention

• Il convient d'afficher la version actuellement installée sur le module lors du chargement de la page web
• Veiller à informer l'utilisateur des risques qu'il encourt s'il débranche le module ou le réseau wifi lors de l'installation du nouveau firmware
• Ce fonctionnement ne sera disponible qu'après une mise à jour OTA classique ou USB des modules présents sur le terrain

Inspiration

Ce site semble décrire la procédure à suivre pour réaliser le comportement attendu.

[Devdevdavid]

Il faut aussi penser à pouvoir mettre à jour l'image du système de fichier pour être en mesure de pouvoir envoyer des nouvelles version de web serveur.

[Devdevdavid]

L'implémentation est sur une bonne voie. Elle est fonctionnelle pour les modules ESP8266.
En revanche, je rencontre des difficultés pour l'ESP32 car les librairies ESP8266WebServer et ESP32WebServer ne sont pas implémentées de la même façon.

Comme le montre cette structure, nous avons sur l'ESP8266 un paramètre qui indique la taille du fichier qui est en cours d'upload : upload.contentLength

Or dans le cas de l'ESP32, cette même structure ne dispose pas du paramètre de la taille du fichier.

Bien que la taille indiquée par upload.contentLength soit en réalité la taille du binaire + les headers, elle donne une taille suffisamment précise pour allouer la taille nécéssaire avec la librairie Update.

Sans cette taille pour l'ESP32, on est obligé de prévoir beaucoup plus grand pour être sûr que le fichier en cours d'upload puisse être écrit sans dépassement.

Or si l'on prend trop grand (Ex: 0xFFFFFFFF), on dépasse sur la zone flash allouée au filesystem et donc on écrase le webserver existant :

|--------------|-------|---------------|--|--|--|--|--|
^              ^       ^               ^     ^
Sketch    OTA update   File system   EEPROM  WiFi config (SDK)

Flash Layout

L'idéal pour résoudre le problème consisterait à trouver quelles sont les adresses et tailles de chaque partie de flash évoquées sur le graphique ci-dessus. Or, impossible de mettre la main sur cette information !

[Devdevdavid]

J'ai trouvée la pièce manquante dans les exemples du repo Arduino :

uint32_t maxSketchSpace = (ESP.getFreeSketchSpace() - 0x1000) & 0xFFFFF000;

[Devdevdavid]

Fonction développée sur ESP8266 et ESP32 avec commit 215de04

Mais j'ai un problème de taille d'image SPIFFS. Le binaire est trop gros pour le buffet de réception côté ESP32.
En l'ouvrant, on s'aperçoit que c'est presque que du padding à 0xFF. Il faut donc compresser les binaires à la manière de PlatformIO lors de son uploadfs.

[Devdevdavid]

Implémentation réussie avec 085ca4d

Plutôt que de compresser le binaire, j'ai choisi de modifier la table de partition pour les ESP32.
Désormais, on a 1.9Mo pour l'appli et 320ko pour le FileSystem. (Voir cette doc pour plus d'info sur les partitions)

Pour info sur l'ESP8266, on a 1Mo pour l'appli et 1Mo pour le FileSystem. On pourra revoir l'équilibrage entre les deux en cas de manque de place d'appli (37% à ce jour)

✅ On peut désormais faire une Maj complète (Appli + Webserveur) depuis le webserveur !

[Devdevdavid]

Validé ce jour avec Pascal