Pixelia 0.3.2 – System und Schutz

Pixelia 0.3.2 – System und Schutz

Optionaler PIN mit Sperre, Werksreset auch am Gerät, Sicherung der Einstellungen und Farbwahl auf dem Gerät · 2026-10-19

Neu

• System: Optionaler PIN oder Passwort (Standard aus) schützt Einstellungen, Updates, Neustart, Werksreset, Befehle, Absturzbericht löschen und Gerätenamen; Lesen bleibt offen
• System: PIN als gesalzener SHA-256-Hash (1000 Runden) im NVS, Sitzungs-Token nur im RAM, Sperre nach 5 Fehlversuchen ab 30 s, verdoppelnd bis 15 min
• System: Werksreset löscht WLAN-Netze, Einstellungen, Farbwahl, Gerätenamen und PIN, danach Setup-Modus; Startzähler und Reset-Historie bleiben für die Diagnose
• Display: Info-Karte mit Knopf „Zurücksetzen …“: PIN entfernen oder Werksreset, jeweils 3 s halten (Fortschrittsbalken), Abbrechen; der Weg für einen vergessenen PIN
• Web: Seite System mit den Karten Schutz (PIN festlegen, ändern, ausschalten, abmelden), Sicherung (herunterladen, einspielen) und Werksreset
• Web: Geschützte Aktionen fragen einmal nach dem PIN (neuer Baustein promptDialog mit Prüfung) und wiederholen sich; Updates prüfen die Anmeldung vor dem Hochladen
• Web: Sicherung als JSON-Datei (/api/backup) mit Anzeige, Farbwahl und Gerätenamen, ohne WLAN-Passwörter und PIN; der Import zeigt vorher, was übernommen wird
• Web: Farbwahl liegt jetzt auf dem Gerät und gilt für alle Browser; ohne Anmeldung bleibt eine Änderung im Browser, mit Knopf zum Speichern
• Web: Neue Schnittstellen /api/auth, /api/login, /api/logout, /api/pin, /api/factory-reset, /api/backup; der Status meldet auth.pin und set.ui

Verbessert

• Web: Einrichtungsseite /setup fragt bei Bedarf nach dem PIN; im Setup-Modus braucht das WLAN-Speichern keinen (das Passwort des Setup-WLANs steht auf dem Display)
• Update: tools/ota.ps1 mit -Pin bzw. $env:PIXELIA_PIN; netlog.ps1 und crash.ps1 kannten -Pin schon
• Simulator: Systemanzeigen reset, reset-ohne-pin und reset-halten für Screenshots; npm run mock spielt PIN, Anmeldung, Sicherung und Werksreset nach

Behoben

• Web: npm run mock leitete den Status-WebSocket ans echte Gerät weiter (Proxy war auch im Mock aktiv), die Oberfläche zeigte dann dessen Werte

Geprüft

• Gerät: PIN per API: alle geschützten Endpunkte 401 ohne Anmeldung, Token, Kopf und Formularfeld gehen, Sperre beim 5. Fehlversuch (429, 30 s), Anmeldung 140–250 ms
• Gerät: Touch-Geste vom User geprüft: Info-Karte → Zurücksetzen, Abbrechen, kurzes Tippen ohne Wirkung, PIN entfernen nach 3 s Halten, Werksreset mit Neustart
• Gerät: Nach dem Werksreset Captive Portal unter Windows: Windows öffnet die Einrichtung von selbst, WLAN neu eingetragen, Startzähler lief weiter; iOS nicht geprüft
• Gerät: 29,8–29,9 fps, interner RAM 113 KB frei (Tiefstwert 110 KB, mit Setup-Modus 97 KB); Firmware 1321 KB = 21,5 % der Partition; Update per WLAN in 8 s
• Web: Bundle gzip 120 KB (app.js 81 KB, CSS 7 KB, Schrift 32 KB), Ziel ≤ 150 KB

Hinweise

• System: PIN vergessen? Am Gerät lange aufs Display drücken, auf der Info-Karte „Zurücksetzen …“ tippen und „PIN entfernen“ 3 Sekunden halten. Über das Netz geht das bewusst nicht.

Pull Requests

#16

Installation

• Update (ab 0.2.0): auf der Einrichtungsseite des Geräts unter „Update“ die Datei pixelia-v0.3.2.bin hochladen.
• Erstinstallation: Web-Flasher https://baldesarra.github.io/pixelia/ öffnen (Chrome oder Edge am PC), Board per USB-Datenkabel anschließen, auf „Installieren“ klicken.
• Von Hand: pixelia-v0.3.2-factory.bin mit esptool ab Adresse 0x0 schreiben.

Pixelia 0.3.1 – Weboberfläche: Seiten

Pixelia 0.3.1 – Weboberfläche: Seiten

WLAN, System mit Update, Live-Log, Info, Hardware und verbundene Geräte in der neuen Oberfläche; Setup-Modus und Einrichtungsseite im M3-Look · 2026-10-19

Neu

• Web: Seite WLAN: Verbindung mit Router, DNS, Zugangspunkt und Dauer, gespeicherte Netze entfernen, Netzsuche mit Signalbalken, Netz hinzufügen mit Passwort-Prüfung
• Web: Seite System: Update hochladen (Datei wird im Browser geprüft, Fortschritt, Probelauf), Drehung, Helligkeit, langer Druck, Diagnosepaket, Absturzbericht löschen, letzte Starts, Neustart
• Web: Seite Live-Log über /ws/log (Rückfall auf /api/log): Filter nach Stufe, Suche, Pause, Neustart-Trenner, Download als Text, Befehle über /api/cmd mit Rückfrage bei gefährlichen
• Web: Seiten Info (Laufzeit, Netz, NTP, Speicherbalken, Partitionswarnung) und Hardware (Panel, Touch, Chip mit Temperatur, Flash, PSRAM, MACs, Pins, Partitionstabelle)
• Web: Seite Verbundene Geräte: jeder Browser mit zufälliger ID, Browser · System, IP, Seite, online, erste/letzte Verbindung; eigener Name pro Gerät; im Setup-Modus die Geräte am Access Point
• Web: Neue Bausteine Textfeld, Schieberegler (M3 Expressive), Bestätigungsdialog, Signalbalken; Navigation auf dem Handy mit fünf Zielen und Seite Mehr, Schiene am Desktop mit allen
• Web: Neue Schnittstellen /api/system (Hardware, Netz, Partitionen, Temperatur) und /api/clients(/name) in web_info.cpp; Browser melden sich über /ws an, bis zu 12 Geräte im NVS
• Web: Setup-Modus zeigt jetzt die neue Oberfläche und startet auf der WLAN-Seite mit kurzer Anleitung; die einfache Einrichtungsseite bleibt unter /setup
• Web: Einfache Einrichtungsseite im M3-Look (Farben der Standardpalette, Roboto Flex, Formen), alle Funktionen erhalten: WLAN, Update, Anzeige, System, Diagnosepaket

Verbessert

• Web: Übersicht verweist auf die Seiten System und WLAN statt auf die Einrichtungsseite; npm run mock liefert alle neuen Schnittstellen und /setup (PIXELIA_MOCK=setup für den Setup-Modus)

Behoben

• Web: Abstände über Text unter Knöpfen (System: Update, Diagnose), abgeschnittene Chips in der Geräteliste, Fußzeile der Einrichtungsseite, Fokus beim Umbenennen (am Gerät gefunden)

Geprüft

• Gerät: Setup-Modus im Captive Portal von Android: das Anmeldefenster (WebView) lädt die neue Oberfläche, meldet sich live an, Netzsuche und /setup funktionieren; Windows nicht geprüft
• Gerät: Alle Seiten per WLAN-Update geprüft: Netzsuche, Live-Log, Befehl wifi, Geräte-Anmeldung mit Umbenennen, /api/system in 36 ms, Chiptemperatur 41,8 °C
• Gerät: Mit offener Oberfläche und Live-Log 29,8–30,3 fps, Zeichnen ≤ 4,2 ms, 0 Aussetzer, interner RAM-Tiefstwert 111 KB; Firmware 1305 KB = 21 % der Partition
• Web: Bundle gzip 119 KB (app.js 79 KB, CSS 7 KB, Schrift 33 KB), Ziel ≤ 150 KB

Pull Requests

#15

Installation

• Update (ab 0.2.0): auf der Einrichtungsseite des Geräts unter „Update“ die Datei pixelia-v0.3.1.bin hochladen.
• Erstinstallation: Web-Flasher https://baldesarra.github.io/pixelia/ öffnen (Chrome oder Edge am PC), Board per USB-Datenkabel anschließen, auf „Installieren“ klicken.
• Von Hand: pixelia-v0.3.1-factory.bin mit esptool ab Adresse 0x0 schreiben.

Pixelia 0.3.0 – Weboberfläche: Grundgerüst

Pixelia 0.3.0 – Weboberfläche: Grundgerüst

Neue Oberfläche im Material 3 Expressive Design: Übersicht mit Live-Werten, dynamische Farben, hell und dunkel, komplett offline · 2026-10-19

Neu

• Web: Neue Weboberfläche unter http://pixelia/ mit Svelte 5, TypeScript und Vite, komplett offline und gzip in die Firmware eingebettet (4 Dateien, 89 KB)
• Web: Eigene M3-Expressive-Bibliothek: Tokens für Formen, Typografie und Federbewegungen, Buttons mit Form-Morphing, Button-Gruppe, Karten, Chips, Icon-Buttons
• Web: Wellige Fortschrittsanzeigen (linear und kreisförmig) und die morphende Ladeanzeige aus M3 Expressive, als SVG ohne Fremdbibliothek
• Web: Dynamische Farben aus einer Akzentfarbe (Material Color Utilities, Spezifikation 2025), drei Farbstile, hell/dunkel/System; die Wahl speichert der Browser
• Web: Navigation unten als Leiste (Handy) bzw. ab 600 px Breite als Schiene links (Desktop), Seiten per Hash-Route
• Web: Seite Übersicht: Version, Laufzeit, fps, Bildzeit, CPU je Kern, RAM und PSRAM, WLAN mit Signalbalken, Neustart-Grund, Fehlerzähler, Hinweise zu Update, Probelauf, Rückfall und Absturz
• Web: Live-Werte über den WebSocket /ws (1/s), Rückfall auf Abfrage von /api/status, Neuverbindung mit 2–15 s Abstand; nach 60 s im Hintergrund wird die Verbindung geschlossen
• Web: Seite Darstellung mit Farbwahl und Vorschau aller Komponenten
• Web: Schrift Roboto Flex reduziert auf 135 Zeichen und die Achsen Stärke und Breite (33 KB statt 250 KB, tools/font_subset.py), Icons nur die 23 benutzten Material Symbols
• Web: Dateien mit ETag (Inhalts-Hash) und no-cache: der Browser fragt nach und bekommt nach einem Update sofort die neuen Dateien, sonst nur 304
• Web: Die Einrichtungsseite bleibt unter /setup und im Setup-Modus unter / (Captive Portal), mit Link zurück zur Übersicht
• Werkzeuge: tools/web_embed.py baut die Oberfläche beim Firmware-Build bei Bedarf neu (npm) und erzeugt web_assets.cpp; npm run mock zeigt sie ohne Gerät; tools/web_screens.mjs macht Screenshots

Verbessert

• CI: Eigener Job baut die Oberfläche (npm ci, svelte-check, Build, Größenprüfung: Warnung ab 150 KB, Fehler ab 400 KB) und reicht web/dist an den Firmware-Build weiter
• Doku: Arbeitsweise mit Claude (docs/ARBEITSWEISE.md): Planungs-Chat und eine frische Arbeits-Sitzung pro Version mit Übergabe übers Repo. Anlass: 0.2.2 verbrauchte ein ganzes Nutzungslimit
• Doku: CLAUDE.md mit neuen Regeln für Sitzungen, Übergabe und Protokoll; ROADMAP „Aktueller Stand“ mit Zeile „Offen“
• Doku: Changelog kürzer: höchstens 220 Zeichen pro Stichpunkt und 24 Stichpunkte pro Version, release_notes.py --check prüft das ab 0.2.1
• Doku: Changelogs 0.2.1 und 0.2.2 gekürzt, die Details stehen weiter in den PR-Beschreibungen
• Doku: 0.3.x in drei Patches aufgeteilt (0.3.0 Grundgerüst, 0.3.1 Seiten, 0.3.2 System und Schutz)
• Doku: Inselwelt: Idee einer Lagerübersicht in der Weboberfläche aufgenommen

Behoben

• Web: Abgebrochene WebSocket-Verbindungen (Browser hart geschlossen, Handy schläft) erzeugten je eine Warnung von httpd_ws und trieben den Warnungszähler hoch; jetzt nur noch Fehler

Geprüft

• Gerät: Oberfläche per WLAN-Update installiert, Selbsttest bestanden; Seiten laden in je ~0,1 s (app.js 53,7 KB gzip), ETag liefert 304, /setup weiter erreichbar
• Gerät: Mit offener Oberfläche (Live-WebSocket, 16 Seitenaufrufe) 29,8–30,3 fps, Zeichnen höchstens 6,4 ms, 0 Aussetzer, interner RAM-Tiefstwert 113 KB
• Gerät: Firmware 1261 KB = 21 % der App-Partition; Setup-Modus nicht am Gerät geprüft (Code-Pfad unverändert die bisherige Einrichtungsseite)

Pull Requests

#12, #13, #14

Installation

• Update (ab 0.2.0): auf der Einrichtungsseite des Geräts unter „Update“ die Datei pixelia-v0.3.0.bin hochladen.
• Erstinstallation: Web-Flasher https://baldesarra.github.io/pixelia/ öffnen (Chrome oder Edge am PC), Board per USB-Datenkabel anschließen, auf „Installieren“ klicken.
• Von Hand: pixelia-v0.3.0-factory.bin mit esptool ab Adresse 0x0 schreiben.

Pixelia 0.2.2 – Fernwartung

Pixelia 0.2.2 – Fernwartung

Log, Befehle, Leistung, Neustarts und Absturzberichte per WLAN, Diagnosepaket zum Verschicken vom Handy · 2026-10-19

Neu

• System: Log-Ringpuffer: Jede Log-Zeile geht weiter unverändert auf die serielle Konsole und zusätzlich in einen 256-KB-Ringpuffer im PSRAM (No-Init-Bereich, den der Speichertest beim Start ausspart). Jede Zeile trägt eine fortlaufende Nummer, die Laufzeit in ms, die Uhrzeit und den Startzähler. Der Puffer übersteht Software-Neustarts, Updates, Abstürze und Watchdog-Resets, erst ein Stromausfall löscht ihn. Jede Zeile wird sofort aus dem Write-Back-Cache in den PSRAM zurückgeschrieben, sonst fehlen nach einem Neustart genau die letzten Zeilen. Zwei Köpfe mit Prüfsumme in einer Cache-Zeile; beim Start werden alle Datensätze nachgezählt, Unstimmiges wird abgeschnitten
• System: RTC-Sicherung der letzten 6 KB (feste Adresse 0x50000000) für den Fall, dass der nächste Start eine andere Version ist, bei der der PSRAM-Puffer an anderer Stelle liegt (die Lage verschiebt sich in 64-KB-Schritten mit der Größe von Code und Konstanten): Im Probelauf nach einem Update wird jede Zeile mitgeschrieben (Absturz → Rückfall auf die alte Version), sonst kopiert ein Shutdown-Handler die neuesten Zeilen einmal vor jedem Software-Neustart. Beim Start meldet Pixelia, woher der Puffer kommt („übernommen“, „aus RTC-Sicherung“, „neu“), mit Befund beider Köpfe
• Web: GET /api/log liefert Zeilen aus dem Puffer, inkrementell mit since=, außerdem tail=, boot= (nur ein bestimmter Start), rid (erkennt einen neu angelegten Puffer), max= und format=text. WebSocket /ws/log für das Live-Log: zuerst die letzten 50 Zeilen (tail bzw. since), dann jede neue Zeile, bis zu fünfmal pro Sekunde gebündelt. Der Hook selbst sendet nie
• Web: POST /api/cmd führt dieselben Diagnose-Befehle aus wie die serielle Konsole (in derselben Task, nacheinander) und liefert ihre Log-Zeilen als Antwort (bis 16 KB, bei mehr bleibt das Ende erhalten). Gefährliche Befehle (reboot, wifi forget/setup/connect, flash, pclk, timing, pol, bounce, clk, buf, touchrst, log clear, coredump erase) lehnt das Gerät ohne confirm=1 mit Grund ab (409). WLAN-Passwörter lassen sich weiterhin nicht über Befehle eintragen. Für den optionalen PIN aus 0.3.x vorbereitet (Kopf X-Pixelia-Pin bzw. Feld pin; ohne PIN ist alles erlaubt)
• Web: GET /api/perf mit allen Werten des Leistungsmonitors (Panel, Pixeltakt, Interrupt mit Höchstwert, Aussetzer, Engine mit Zeichen- und Logikzeit, CPU pro Kern, interner RAM, DMA und PSRAM mit Tiefstwerten und größtem Block, WLAN) und den Kosten des Log-Hooks; mit tasks=1 zusätzlich alle Tasks mit Kern, Priorität, Stack-Reserve und CPU-Last
• System: Reset-Historie der letzten 16 Starts im NVS (Namensraum diag): Startnummer, Uhrzeit (nach einem Einschalten nach dem NTP-Abgleich nachgetragen), Grund, Version, Partition, Probelauf, Rückfall mit Grund, Absturz-Task und PC, dazu die Laufzeit des vorigen Starts und der Zeitpunkt seines letzten Lebenszeichens (Herzschlag alle 2 s im RTC-Speicher). Abruf über GET /api/resets und den Befehl resets
• System: Absturzbericht per WLAN: GET /api/coredump liefert die Rohdaten aus der Partition, GET /api/coredump/summary Panic-Grund (bei CPU-Ausnahmen deren Name, z. B. StoreProhibited), Task, PC, Backtrace-Adressen, Ausnahme und die passende Version über den ELF-SHA256; POST /api/coredump/erase löscht ihn. Konsolenbefehle coredump und coredump erase
• Web: Diagnosepaket GET /api/diag: eine JSON-Datei mit Status, System (Chip, Flash, PSRAM, Partitionen mit Version und Zustand, NVS), Einstellungen samt Namen der gespeicherten WLANs (ohne Passwörter), Leistung mit Task-Liste, Reset-Historie, Absturzbericht (Zusammenfassung und Rohdaten als Base64) und dem kompletten Log-Puffer. Auf der Einrichtungsseite neuer Bereich „Diagnose“ mit Startnummer, Resetgrund, Fehlern und Warnungen seit dem Start, Zeilen im Log, Absturzbericht und dem Knopf „Diagnosepaket herunterladen“ (auf dem Handy landet die Datei unter Downloads und lässt sich von dort verschicken)
• Engine: Passwort-Filter (engine/redact.h): ersetzt jedes Vorkommen der gespeicherten WLAN-Passwörter und des Setup-WLAN-Passworts durch Sternchen gleicher Länge, auch in JSON-Schreibweise und über Blockgrenzen hinweg, längstes Geheimnis zuerst. Läuft über alle Ausgaben mit freiem Text: /api/log, /ws/log, /api/cmd und /api/diag. Das Diagnosepaket meldet am Ende secretCheck (geprüft, ersetzt)
• System: Werkzeug tools/netlog.ps1 für Claude: Live-Log per WebSocket mit Filter wie monitor.ps1 (-Full, -Filter, -Until, -MaxLines), Befehle per -Send (mit -Confirm für gefährliche), frühere Starts mit -Boot prev bzw. -Boot , ganzer Puffer mit -All; Befehlsausgaben erscheinen nicht doppelt. Volles Log in .logs\netlog-last.log
• System: Werkzeug tools/crash.ps1: Absturzbericht per WLAN (oder mit -File aus einem Diagnosepaket vom Handy) holen, das passende ELF über den SHA256 finden (lokaler Build, Testvarianten, Zwischenspeicher oder pixelia-vX.Y.Z.elf aus dem GitHub-Release), PC und Backtrace mit Funktion, Datei und Zeile dekodieren, den Eintrag der Reset-Historie und die letzten Log-Zeilen des abgestürzten Starts zeigen. -Full ruft zusätzlich esp-coredump mit GDB auf (alle Tasks), -Erase löscht den Bericht
• System: Neue Konsolenbefehle log (Puffer und Kosten des Hooks), log bench [n] (Messung), log clear, tasks, resets, coredump und coredump erase. Die Leistungszeile alle 2 s geht weiter auf die serielle Konsole, in den Puffer nur einmal pro Minute (sonst bestünde er nach einer halben Stunde nur aus Leistungszeilen)
• System: Testvariante -DPIXELIA_TEST=crash-shift: stürzt wie crash im Probelauf ab und verschiebt mit 64 KB zusätzlichen Konstanten den Log-Puffer um eine MMU-Seite (prüft den Weg über die RTC-Sicherung, wie nach einem echten Update mit mehr Code)
• Simulator: Selbsttest --test redact mit 9 Fällen (Blockgrenzen Zeichen für Zeichen und in 7er-Stücken, JSON-Schreibweise, ineinander enthaltene Geheimnisse in beiden Reihenfolgen, zu kurze Geheimnisse, 100 KB ohne Geheimnis, Abbruch des Ziels), läuft in der CI

Verbessert

• Web: /api/status enthält jetzt auch Startnummer, letzten Resetgrund, Fehler und Warnungen seit dem Start, Zeilen im Log-Puffer und einen vorhandenen Absturzbericht (Feld diag)
• System: Der Leistungsmonitor hält mehr Werte bereit (Pixeltakt, längster Interrupt, Zeichen-Höchstwert, Logikzeit, Logik-Schritte, Sprites, Weltzeit, DMA-Speicher, größter PSRAM-Block)
• Web: JSON-Schreiber als eigene Datei (json.cpp) statt inline im Header: Der Compiler (-O2) kopierte die Zeichenkettenarbeit sonst in jede Aufrufstelle, das kostete in der Entwicklung über 100 KB Code. Firmware jetzt 1170 KB (19 % der App-Partition)
• Web: Große Zwischenpuffer (WebSocket-Rahmen, gestreamte Antworten, Befehlsausgaben) werden bewusst ab 16 KB angelegt und landen so im PSRAM statt im internen RAM
• Doku: HARDWARE.md (Diagnose per WLAN mit allen Schnittstellen, Werkzeugen und Messwerten, Lage des Log-Puffers, Kernel-Sperre), Roadmap mit 0.2.2, Entscheidungsprotokoll, CLAUDE.md (netlog.ps1 und crash.ps1)
• Doku: Neue Code-Landkarte docs/CODEMAP.md: Ordner, Engine-Bausteine, Firmware-Module mit Startablauf, Tasks mit Kern und Priorität, Speicher (Partitionen, NVS-Namensräume, No-Init-Bereiche), Schnittstellen, Simulator, Werkzeuge und CI. Neue Sitzungen müssen damit nicht mehr den halben Code lesen
• Doku: CLAUDE.md mit Abschnitt „Sitzungen und Nutzungslimit“ (Vorschlag des Users): eine Sitzung pro Phase, neue Sitzung nur bei Phasenwechsel oder ab ca. 300 K Kontext, schlanke Einarbeitung über CLAUDE.md, Roadmap und CODEMAP, Denkstufe normal „high“; CODEMAP.md unter „Zuerst lesen“

Behoben

• Web: Der Status-WebSocket /ws hat unter ESP-IDF 6.1 nie gesendet: Beim Handschlag ruft der Webserver den URI-Handler nicht mehr auf, die Anmeldung stand aber genau dort. Die Einrichtungsseite lief deshalb unbemerkt über ihre Ersatz-Abfrage alle 2 s. Jetzt mit Post-Handshake-Callback (CONFIG_HTTPD_WS_POST_HANDSHAKE_CB_SUPPORT); gemessen 5 Nachrichten in 3,5 s
• System: In der Entwicklung gefunden: Die Datensatzköpfe des Log-Puffers wurden über einen uint32_t-Zeiger in eine Struktur mit uint16_t-Feldern gelesen (Verstoß gegen die Aliasing-Regeln von C++). Der Compiler nahm Länge, Größe und Startnummer als 0 an: alle Zeilen kamen leer zurück, nach einem Neustart galten 0 Zeilen als gültig. Jetzt per memcpy; die Compiler-Warnung „may be used uninitialized“ war das Symptom
• System: In der Entwicklung gefunden: Die Task-Liste (uxTaskGetSystemState) hält die Kernel-Sperre 1,1 ms, während sie die Stacks aller Tasks durchsucht. Tick- und Display-Interrupt auf Kern 1 warten so lange, der Bounce-Buffer kommt zu spät: etwa ein Display-Aussetzer pro Abfrage (im Lasttest mit 39 Abfragen pro Sekunde 368 Aussetzer und 27 fps). Die Task-Liste gibt es deshalb nur auf Wunsch (tasks, /api/perf?tasks=1, einmal im Diagnosepaket), /api/perf ohne Parameter ist aussetzerfrei
• System: In der Entwicklung gefunden: Der Puffer-Teil des Hooks kostete zuerst 34 µs pro Zeile, je etwa zur Hälfte PSRAM (mit esp_cache_msync) und RTC-Speicher (~0,3 µs pro 32-Bit-Zugriff). Jetzt RTC-Sicherung nur im Probelauf zeilenweise, Cache-Rückschreiben direkt über die HAL unter dem Spinlock von ESP-IDF, beide Köpfe in einer Cache-Zeile: 16–19 µs
• System: In der Entwicklung gefunden: Die Ausgabe eines Befehls brach bei 16 KB ab, ausgerechnet vor der Zusammenfassung. Jetzt fällt bei Überlauf der Anfang weg und das Ende bleibt erhalten

Geprüft

• System: Alle Nachweise am Gerät ausschließlich per WLAN (tools/ota.ps1, netlog.ps1, crash.ps1, kein serieller Port): Software-Neustart über /api/cmd reboot und Updates auf neue Stände: Puffer „übernommen“ (z. B. 158 bzw. 711 Zeilen früherer Starts), die Zeilen vor dem Neustart stehen im Verlauf
• System: Absturz-Testvariante crash (gleiche Puffer-Lage 0x3C120000) per Update aufgespielt: Absturz nach 20 s im Probelauf, Rückfa...

Pixelia 0.2.1 – Immer erreichbar

Pixelia 0.2.1 – Immer erreichbar

Info-Karte mit IP und QR-Code per langem Druck aufs Display, IP in der Kurzmeldung, Updates per WLAN aus der Kommandozeile · 2026-10-18

Neu

• Display: Info-Karte per langem Druck (3 s irgendwo aufs Display): IP-Adresse groß, QR-Code mit http:// und der IP, z. B. http://192.168.178.42/ (funktioniert in jedem Netz, auch ohne passenden DNS), die Adressen http://pixelia.local (Handy, Mac), http://pixelia/ (Windows) und http://pixelia.fritz.box, WLAN-Name, Signal als 4 Balken und in dBm, Hostname und Firmware-Version. Tippen schließt die Karte, sonst nach 20 s. Die Werte werden alle 2 s aufgefrischt, die Welt läuft abgedunkelt (Pixelraster) dahinter weiter
• Display: Info-Karte im Setup-Modus mit Name und Passwort des Setup-WLANs, QR-Code zum Beitreten, Adresse http://192.168.4.1 und Zahl der verbundenen Geräte; ohne Verbindung mit dem laufenden Verbindungsversuch und dem letzten Fehler
• Touch: Halte-Anzeige „Halten für Info …“ mit Fortschrittsbalken, sobald ein Viertel der Haltezeit erreicht ist, damit klar ist, dass der Druck zählt
• Engine: Gestenerkennung als eigener, plattformunabhängiger Baustein (engine/gesture.h): Tippen (bis 800 ms) und langer Druck. Der lange Druck löst noch während der Finger liegt aus, auch wenn der GT911 bei ruhigem Finger keine neuen Messwerte liefert. Bewegung über 24 Panel-Pixel oder ein zweiter Finger heben beides auf, damit spätere Wischgesten nicht kollidieren. Verteilt wird zentral in firmware/main/input.cpp: heute an die System-Oberfläche, später an die Welten
• System: Dauer des langen Drucks im NVS einstellbar (1–10 s, Standard 3 s): Konsole „set lp 3000“ (Millisekunden), Schnittstelle POST /api/settings mit lp, zu sehen in /api/status unter set.lp. Konsolenbefehl „card“ bzw. „card off“ zeigt oder schließt die Karte
• Update: Werkzeug tools/ota.ps1 spielt eine .bin per WLAN auf (POST /api/ota, Standardziel http://pixelia/, sonst -Target mit der IP, -Build baut vorher). Vorab prüft es den Kopf der Datei (ESP-Image, Projekt „pixelia“, Version) und ob das Gerät antwortet. Es zeigt den Fortschritt in 10-%-Schritten mit KB/s, wartet den Neustart ab und meldet erst Erfolg, wenn /api/status die neue Version mit bestandenem Selbsttest zeigt. Ein Rückfall wird mit Grund gemeldet (Exit 1). USB ist damit nur noch für das serielle Log und die Erstinstallation nötig
• Simulator: Info-Karte, Halte-Anzeige und neue Kurzmeldung per --screen info, info-setup, info-offline, hold und toast-ip. Im Fenster ersetzt die Maus den Touch mit derselben Gestenerkennung: 3 s gedrückt halten zeigt die Info-Karte, ein Klick schließt sie
• Simulator: Selbsttest --test gestures mit 11 nachgestellten Touch-Abläufen (Tippen, langer Druck mit und ohne neue Messwerte, Zittern bis 10 px, Bewegung, zwei Finger, zu langes Tippen, Halte-Fortschritt, einstellbare Dauer, Tippen nach langem Druck, Überlauf der ms-Uhr nach 49 Tagen). Läuft in der CI bei jedem Push
• Doku: Rohkonzept der neuen Welt „Inselwelt“ gesichert (docs/welten/inselwelt-konzept.md), als eingeplante Welt in Roadmap und Projektplan aufgenommen
• Doku: Lebendigkeits-Charta um die Regel „Zuverlässiges Gedächtnis“ ergänzt: exakte Bestände, angefangene Arbeiten und Besuche bleiben erhalten, belegt durch einen Bilanz-Test
• Doku: Pixel-Dorf als Aufbau-Wirtschaft geplant: begrenzte Rohstoffe, Bauprojekte mit exaktem Materialverbrauch, neue Häuser als Voraussetzung für neue Bewohner

Verbessert

• WLAN: Kurzmeldung nach jedem Verbinden jetzt mit IP-Adresse, z. B. „Verbunden mit „Heimnetz“ · 192.168.178.42“ (10 s nach dem Start, 6 s bei späteren Verbindungen). In fremden Netzen (Handy-Hotspot, anderer Router) ist die IP oft der einzige Weg zur Seite
• WLAN: Die Meldung nach der Einrichtung nennt zusätzlich die Adresse mit IP (z. B. http://192.168.178.42/) und weist auf den langen Druck hin
• Display: Der Merker für unbewegte Systemanzeigen umfasst jetzt Anzeige, Version, Info-Karte und Halte-Fortschritt (64 Bit, Fortschritt in 1-%-Schritten). Unbewegte Anzeigen werden weiterhin nur bei einer Änderung neu gezeichnet
• Doku: HARDWARE.md (Info-Karte, Gestenregeln, Update per WLAN), sim/README.md (neue Anzeigen, Selbsttest, Maus) und CLAUDE.md (Updates bevorzugt per WLAN mit tools/ota.ps1)
• Doku: Changelog ausführlicher im Stil der Pull-Request-Beschreibungen. Neue Felder „Geprüft“ (g), „Hinweise“ (h) und „Pull Requests“ (pr); die Einträge 0.1.0 und 0.2.0 sind mit allen Änderungen, Messwerten und Fehlerbehebungen nachgetragen
• System: tools/release_notes.py prüft das Format von CHANGELOG.json (--check): Pflichtfelder, Bereich am Anfang jedes Stichpunkts, Reihenfolge der Versionen, Datum. Die CI prüft das bei jedem Push
• Update: Release-Notes auf GitHub zeigen zusätzlich „Geprüft“, „Hinweise“ und verlinkte Pull Requests; ein Release ohne Datum, Titel oder Untertitel wird abgelehnt

Behoben

• Update: tools/ota.ps1 lehnte in der Entwicklung jede echte Firmware ab, weil PowerShell 5.1 den Hex-Wert 0xABCD5432 (Kennung der App-Beschreibung) als negative Int32 liest. Behoben mit 64-Bit-Literal. Außerdem behandelt PowerShell die deutschen Anführungszeichen „ “ als Zeichenketten-Grenzen; Texte damit stehen jetzt in einfachen Anführungszeichen

Geprüft

• Simulator: Gestentest 11/11 bestanden; Info-Karte in allen drei Zuständen, Halte-Anzeige, Kurzmeldung mit IP und Meldung nach der Einrichtung als Screenshot kontrolliert
• Display: QR-Codes der Info-Karte aus dem Screenshot mit zxing-cpp gelesen: http://192.168.178.42/ (Version 2, 25 × 25 Module, 4 px pro Modul, auf dem Display 8 px) und der WLAN-Code für „Pixelia-Setup“ samt Passwort (Version 3, 3 px pro Modul). Auch die längste mögliche IP passt in Version 2
• Update: tools/ota.ps1 gegen einen nachgebauten Pixelia-Server geprüft: Update mit Neustart und Probelauf (Exit 0), Rückfall mit Grund (Exit 1), vom Gerät abgelehnte Datei mit dessen Meldung, nicht erreichbares Ziel, nicht auflösbarer Name und Datei ohne ESP-Kennung (Exit 2)
• System: Firmware 1134 KB (18,5 % der App-Partition, +21 KB gegenüber 0.2.0), Build ohne Warnungen; Simulator unter Windows (Fenster und kopflos) gebaut
• System: Format-Prüfung und Release-Notes für 0.1.0 und 0.2.0 lokal erzeugt und kontrolliert

Hinweise

• Display: Am Gerät noch nicht geprüft, das Board war beim Bau nicht angeschlossen: Bildrate mit offener Karte, langer Druck und Tippen am echten Touch, QR-Scan mit dem Handy und die Kurzmeldung nach dem Neustart. Der User prüft das selbst nach dem Update
• System: Die Dauer des langen Drucks lässt sich vorerst über Konsole und Schnittstelle ändern, in der Weboberfläche ab 0.3.x
• Touch: Nur kurzes Tippen (bis 0,8 s) schließt die Karte. Wischen schließt sie nicht, Wischgesten bleiben für die Welten frei

Pull Requests

#6, #7, #8

Installation

• Update (ab 0.2.0): auf der Einrichtungsseite des Geräts unter „Update“ die Datei pixelia-v0.2.1.bin hochladen.
• Erstinstallation: Web-Flasher https://baldesarra.github.io/pixelia/ öffnen (Chrome oder Edge am PC), Board per USB-Datenkabel anschließen, auf „Installieren“ klicken.
• Von Hand: pixelia-v0.2.1-factory.bin mit esptool ab Adresse 0x0 schreiben.

Pixelia 0.2.0 – Vernetzt

Pixelia 0.2.0 – Vernetzt

WLAN mit Setup-Modus, Einrichtungsseite im Browser und Updates ohne USB · 2026-10-18

Neu

• WLAN: Manager für bis zu 5 gespeicherte Netze; nach einem Scan verbindet sich Pixelia mit dem stärksten. Hostname „Pixelia“ im Router
• WLAN: mDNS-Name pixelia.local; Uhrzeit per NTP (Zeitzone Europa/Berlin), die Weltzeit folgt der echten Uhrzeit
• WLAN: Setup-Modus mit eigenem Netz „Pixelia-Setup“ (WPA2, Passwort steht auf dem Display) und Captive Portal: Mini-DNS, Prüfadressen von Android, iOS, Windows und Firefox, DHCP-Option 114. Die Einrichtungsseite öffnet sich am Handy von selbst
• WLAN: ohne Verbindung alle 2 Minuten ein neuer Versuch im Hintergrund; der Setup-Modus bleibt dabei erreichbar (Access Point und Station gleichzeitig)
• Display: Anleitung im Setup-Modus mit zwei QR-Codes (1. WLAN „Pixelia-Setup“ beitreten, 2. Einrichtungsseite öffnen), Setup-Passwort groß daneben
• Web: Webserver mit WebSocket (/ws, Status jede Sekunde) und einfacher Einrichtungsseite: WLAN, Update, Anzeige und Live-Systemwerte. Die richtige Oberfläche folgt in 0.3.x
• Web: JSON-Schnittstelle GET /api/status, GET /api/wifi, POST /api/wifi/scan, /api/wifi/add, /api/wifi/remove, POST /api/settings, POST /api/ota, POST /api/reboot, POST /api/speedtest (misst die Übertragungsrate)
• Update: neue Version als .bin im Browser hochladen, Fortschritt im Browser und als Balken auf dem Display
• Update: Prüfung vor dem Installieren: Pixelia-Firmware (Projektname), passender Chip und Revision, Prüfsumme. Ungeeignete Dateien werden abgelehnt, das Gerät läuft dabei ohne Neustart weiter
• Update: Probelauf mit Selbsttest (60 s). Rückfall auf die alte Version bei Absturz, bei einem Hänger (Watchdog nach 10 s) oder wenn der Selbsttest scheitert (nach 120 s); die alte Version meldet Grund, Task und Absturzstelle
• System: Einstellungen im NVS: Bilddrehung 0°/180° und Helligkeit, bleiben über Neustarts und Updates erhalten
• Engine: Systemschrift 5×7 Pixel, proportional, mit Kleinbuchstaben, Umlauten, ß und deutschen Anführungszeichen
• Engine: eigener QR-Code-Erzeuger und Systemanzeigen für Setup, Update, Meldungen und Kurzmeldungen am unteren Rand. Die Palettenindizes 240–255 gehören der System-Oberfläche
• Simulator: Systemanzeigen auch am PC (--screen)
• System: Diagnose-Befehle für Netzwerk und Updates: wifi, wifi scan/list/forget/setup/connect, ota, ntp, web, toast. WLAN-Passwörter lassen sich bewusst nur über die Einrichtungsseite eintragen

Verbessert

• Display: unbewegte Systemanzeigen werden nur bei Änderung neu gezeichnet: 0,02 ms statt bis zu 9,5 ms pro Bild
• WLAN: beim Start 45 s Geduld, bevor der Setup-Modus kommt. Router beantworten die ersten Anmeldungen nach einem harten Reset oft nicht (Grund 2, 4 oder 202)
• System: die Firmware-Version im lokalen Build wird nach jedem Commit aktualisiert

Behoben

• WLAN: Eine FritzBox im WPA2/WPA3-Mischmodus lehnte die Anmeldung ab (Grund 17, „IE in 4-Way-Handshake weicht ab“), weil ESP-IDF 6.1 standardmäßig den WPA3-Kompatibilitätsmodus (RSN Override) nutzt. Pixelia versucht es dann ohne diesen Modus und merkt sich das pro Netz im NVS
• Update: Ein Upload blieb bei schwachem Empfang (−71 dBm) ganz stehen. TCP-Fenster von 5,7 auf 32 KB vergrößert und SACK eingeschaltet, hängende Uploads werden sauber abgebrochen (die Seite meldet 30 s ohne Fortschritt). Übertragungsrate 37 → 158–233 KB/s
• Update: Der Zielbereich wird vorab in 64-KB-Blöcken gelöscht statt während der Übertragung: Update in 7 s statt 26 s
• Display: Lange Kurzmeldungen wurden abgeschnitten. Jetzt mit Zeilenumbruch, zu lange Texte enden mit Auslassungszeichen
• System: Der scheinbare Einbruch von ~31 KB internem RAM beim Start war ein Messartefakt: ESP-IDF reserviert einen DMA-Pool (32 KB), der bis zur ersten Anforderung einen Tiefstwert von 0 meldet. Die Tiefstwert-Messung startet jetzt zu Beginn von app_main

Geprüft

• Display: 30 fps, Panel 60 Hz, 0 Aussetzer mit WLAN, Webserver, offener Seite und während Updates. Kern 0 ist beim Update bis 100 % ausgelastet, Kern 1 (Grafik) bleibt unberührt; Hochskalier-Interrupt 20,2 %
• System: freier interner RAM im Betrieb 125–128 KB (Tiefstwert 119 KB), im Setup-Modus ≥ 115 KB, während eines Updates ≥ 121 KB (Budget 60 KB); PSRAM frei 6,9 MB. Speicherbedarf: Display und Engine 62 KB, WLAN 83 KB (Setup-Modus 92 KB), Webserver 16 KB
• WLAN: Einrichtung per Android-Handy: Die Seite öffnete sich von selbst, die Verbindung ins Heimnetz stand wenige Sekunden nach dem Speichern (Test des Users)
• WLAN: nach einem Software-Neustart in 3,6 s wieder verbunden, die Uhrzeit bleibt dabei erhalten
• Update: echtes Update auf die veröffentlichte .bin im Browser: 1113 KB in 7,1–7,4 s (3,2 s Löschen, Übertragen und Schreiben mit 176 KB/s), Selbsttest bestanden (Test des Users)
• Update: Rückfall mit drei Testvarianten geprüft: Absturz im Probelauf (StoreProhibited), Hänger (Watchdog) und gescheiterter Selbsttest. Jedes Mal startete die alte Version mit passender Meldung
• Update: abgelehnt werden Factory-Image, fremde Datei (Kennung ≠ 0xE9), anderes Projekt, anderer Chip, ein verfälschtes Byte und eine abgeschnittene Datei
• System: Einstellungen überleben Neustart und Update

Hinweise

• Update: Geräte mit 0.1.0 brauchen einmal den Web-Flasher, weil 0.1.0 noch keine Update-Funktion hat. Ab 0.2.0 laufen Updates ohne USB
• WLAN: Am Windows-PC mit FritzBox funktioniert pixelia.local nicht, weil der FritzBox-DNS .local-Adressen mit 0.0.0.0 beantwortet. Dort http://pixelia/ oder http://pixelia.fritz.box verwenden; Android öffnet pixelia.local direkt

Pull Requests

#4, #5

Installation

• Update (ab 0.2.0): auf der Einrichtungsseite des Geräts unter „Update“ die Datei pixelia-v0.2.0.bin hochladen.
• Erstinstallation: Web-Flasher https://baldesarra.github.io/pixelia/ öffnen (Chrome oder Edge am PC), Board per USB-Datenkabel anschließen, auf „Installieren“ klicken.
• Von Hand: pixelia-v0.2.0-factory.bin mit esptool ab Adresse 0x0 schreiben.

Pixelia 0.1.0 – Fundament

Pixelia 0.1.0 – Fundament

Hardware geprüft, Engine-Prototyp mit 30 fps, Simulator und Web-Flasher · 2026-10-18

Neu

• System: Firmware auf ESP-IDF 6.1 (C++20) mit eigener Partitionstabelle: zwei App-Plätze à 6 MB (A/B), Datenspeicher für Spielstände, Absturzberichte im Flash (Core-Dump), Rückfall über den Bootloader
• System: Programmcode und Konstanten laufen aus dem PSRAM (XIP), dadurch stört Flash-Schreiben die Anzeige nicht; der RGB-Interrupt ist IRAM-sicher
• Display: RGB-Panel 800×480 ohne eigenen Bildspeicher, Pixeltakt 24,6 MHz = 60 Hz, Timings 8/4/8, Bounce-Buffer 2 × 8 Zeilen im internen RAM
• Display: Bilddrehung um 180° ohne Mehrlast (Interrupt 20,2 → 20,5 %), Touch-Koordinaten drehen mit
• Display: Hintergrundbeleuchtung an GPIO 2 dimmbar (LEDC-PWM 200 Hz, 12 Bit)
• Touch: GT911 auf I²C-Adresse 0x5D (SDA 19, SCL 20, RST 38), Abfrage alle 20 ms ohne INT-Leitung
• Engine: 400×240 Pixel mit 256-Farben-Palette. Palette und 2× Hochskalieren laufen im Bounce-Buffer-Callback (ca. 1,8 CPU-Takte pro Ausgabepixel), Doppelpuffer im PSRAM mit Tausch am Bildende: stabil 30 fps
• Engine: Logik-Takt aus dem Bildzähler des Panels: ein Schritt pro Engine-Bild, nach einem verpassten Bild zwei, höchstens vier
• Engine: Szenen-Schnittstelle, die Gerät und Simulator gemeinsam nutzen; Zufallsgenerator PCG32; eigener PNG-Encoder (Deflate + LZ77) ohne Fremdbibliothek
• Engine: Weltzeit mit Zeitraffer; die Testszene zeigt Tag und Nacht mit Himmel nach Uhrzeit, Licht, Sternen und nachts schlafenden Vögeln
• System: Hardware-Detektiv mit Prüfbild (Farbbalken, Verläufe, Rand), Touch-Eckentest, Helligkeitsstufen, Pixeltakt- und Flash-Lasttest sowie geführten Tests im Tempo des Users (tour, tour2)
• System: Diagnose über die serielle Konsole mit Leistungsmonitor alle 2 s: Bildrate, Pixeltakt, Interrupt-Last, Aussetzer, Zeichen- und Logikzeit, CPU-Last pro Kern, freier RAM und PSRAM
• System: Weltzeit per Konsolenbefehl einstellbar (time HH:MM, speed X)
• Simulator: gleiche Szenen am PC im SDL3-Fenster (3.4.16) oder kopflos mit fester Uhrzeit, Vorspulen, Zeitraffer, PNG-Screenshot und Kontaktbogen mit 24 zufälligen Momenten
• Update: Web-Flasher auf GitHub Pages (ESP Web Tools 10.4.0) für die Erstinstallation per USB aus Chrome oder Edge
• Update: Release-Weg: Tag vX.Y.Z → Firmware mit dieser Version, Factory-Image und Release-Notes aus CHANGELOG.json
• System: GitHub Actions bauen bei jeder Änderung die Firmware (mit Größenbudget 75 % der App-Partition) und den Simulator (mit Screenshots und Kontaktbogen als Artefakt)
• System: Hilfsskripte zum Bauen, Flashen, Log-Mitlesen ohne Interaktion (mit Backtrace-Dekodierung) und für den Simulator
• Doku: Projektplan, Roadmap, geprüfte Hardware-Doku und verbindliche Lebendigkeits-Charta

Behoben

• Simulator: Der Linux-Build in der CI scheiterte an einem fehlenden Include (size_t mit GCC) und brauchte die ausdrückliche Erlaubnis, SDL ohne X11/Wayland zu bauen

Geprüft

• System: ESP32-S3 Revision v0.2, 16 MB Flash (QIO 80 MHz), 8 MB Octal-PSRAM im Chip (80 MHz), USB-UART CH340 mit Auto-Reset; per esptool und Systeminfo bestätigt
• Display: alle 16 Datenleitungen sowie DE, VSYNC, HSYNC und PCLK per Prüfbild bestätigt (Farbreihenfolge, gleichmäßige Verläufe ohne Sprünge, 1-Pixel-Rand an allen vier Seiten)
• Display: Pixeltakt fehlerfrei bis 40 MHz (ESP ohne Aussetzer, Panel ohne Bildfehler); gewählt 24,6 MHz mit Sicherheitsabstand
• Display: Hintergrundbeleuchtung mit 200 Hz still und flackerfrei; 500 Hz–1 kHz pfeifen hörbar, ab 2 kHz geht das Display unter 100 % aus
• Engine: Zeichenzeit 4,1 ms (48 Sprites), 8,4 ms (500) und 22,6 ms (2000); Interrupt-Last 20 %; interner RAM frei 299 KB, PSRAM frei 7,7 MB
• Engine: 664 KB Flash löschen und schreiben während der Animation: 0 Aussetzer, 30 fps, Zeichenzeit unverändert, im A/B-Sichtvergleich gleich flüssig
• Touch: Eckentest bestanden, Koordinaten passen auch bei 180°-Drehung
• Update: Factory-Image ab Adresse 0x0 startet normal; Web-Flasher am Board des Users getestet (Pixelia 0.1.0 aus dem Release, 60 Hz, 30 fps)

Hinweise

• Update: 0.1.0 hat noch keine Update-Funktion über WLAN, installiert wird per Web-Flasher
• Display: Steht das Gerät mit dem USB-Kabel rechts, braucht es die 180°-Drehung (Konsolenbefehl rot 180)

Pull Requests

#1, #2, #3

Installation

• Update (ab 0.2.0): auf der Einrichtungsseite des Geräts unter „Update“ die Datei pixelia-v0.1.0.bin hochladen.
• Erstinstallation: Web-Flasher https://baldesarra.github.io/pixelia/ öffnen (Chrome oder Edge am PC), Board per USB-Datenkabel anschließen, auf „Installieren“ klicken.
• Von Hand: pixelia-v0.1.0-factory.bin mit esptool ab Adresse 0x0 schreiben.