Phase 7: archive migration docs to docs/, rewrite README for WT32-SC01 Plus

- Move SPEC-old.md, PLAN.md, TODO.md -> docs/ (migrationshistorie nachvollziehbar, nicht geloescht laut Auftrag) - README.md neu: WT32-SC01-Plus-Setup, Touch-Bedienung, Projektstruktur, Verweis auf m5stack-dashboard als Referenz - deploy.sh unverändert (hardwareunabhaengig, ruft nur pio run --target upload auf)
2026-09-17 17:30:25 +00:00 · 2026-08-02 10:44:29 +02:00
parent 65e7ec8523
commit a686689787
4 changed files with 55 additions and 31 deletions
@@ -0,0 +1,110 @@
+# PLAN – WT32-SC01 Plus Dashboard (Migration von m5stack-dashboard)
+
+_Letztes Update: 2026-08-02_
+
+Referenzprojekt: [skoelle/m5stack-dashboard](https://github.com/skoelle/m5stack-dashboard) (Struktur bekannt, Quelltext-Details noch nicht vollständig eingesehen – siehe Abschnitt 6 „Offene Punkte“).
+
+Ziel: Neues, eigenständiges Repository `wt32sc01-dashboard`, das fachlich dieselbe Funktionalität liefert wie das M5Stack-Projekt (siehe `SPEC.md`), aber mit Touch-UI im Hochformat auf dem WT32-SC01 Plus. **So viel wie möglich vom bestehenden Code wird übernommen bzw. 1:1 portiert**, nur die Display-/Eingabe-Schicht wird neu gebaut.
+
+## 1. Migrationsprinzip: Was bleibt, was wird neu gebaut
+
+Die bestehende Architektur trennt bereits sauber zwischen **Datenschicht** (API-Clients, JSON-Parsing) und **Darstellungsschicht** (Screens, Buttons). Diese Trennung ist der Hebel für die Migration:
+
+| Modul (Original) | Migrationsstrategie | Begründung |
+|---|---|---|
+| `src/api/http_client.h/cpp` | **1:1 übernehmen**, ggf. minimal anpassen (Timeout/Retry-Verhalten prüfen) | Reiner HTTP-GET-Wrapper, hardwareunabhängig, gleiche APIs im gleichen Netz |
+| `src/api/weather_api.h/cpp` | **1:1 übernehmen** | Reines JSON-Parsing gegen unveränderten Endpoint, keine Display-Abhängigkeit |
+| `src/api/calendar_api.h/cpp` | **1:1 übernehmen** | Gleiche Begründung wie Wetter |
+| `src/api/departures_api.h/cpp` | **1:1 übernehmen** | Gleiche Begründung wie Wetter |
+| `src/icons/icons.h` (RGB565-Bitmaps) | **Teilweise übernehmen, teilweise neu rendern** | Farbkonzept/Symbolik bleibt, aber Icons werden für größeres Display in größerer Auflösung neu exportiert (siehe Task 3) |
+| `src/screens/screen_base.h` | **Konzept übernehmen, Implementierung neu** | Abstraktion "Screen mit Lifecycle" bleibt sinnvoll, aber Rendering-API wechselt von M5GFX-Direktzeichnung auf LVGL-Widgets |
+| `src/screens/home_screen.h/cpp` | **Fachlogik übernehmen, UI neu bauen** | Datenaufbereitung (welche Werte werden wie angezeigt) bleibt, Layout wird von Button-Screen zu Touch-Kacheln (siehe SPEC.md Abschnitt 5.1) |
+| `src/screens/weather_detail_screen.h/cpp` | **Fachlogik übernehmen, UI neu bauen** | Liste wird scrollbar statt starr, Zurück-Button neu (unten links) |
+| `src/screens/calendar_detail_screen.h/cpp` | **Fachlogik übernehmen, UI neu bauen** | Gleiche Begründung |
+| `src/screens/mvg_screen.h/cpp` | **Fachlogik übernehmen, UI neu bauen** | Gleiche Begründung |
+| `src/main.cpp` | **Neu schreiben** | Boot-Flow, Setup/Loop müssen an LVGL-Tick-Handler, Touch-Init und Display-Rotation angepasst werden |
+| `platformio.ini` | **Neu schreiben** | Anderes Board (`esp32-s3`), andere Libs (LovyanGFX + LVGL9 statt M5Stack-Lib), andere Build-Flags |
+| Button-Navigation (A/B/C) | **Entfällt komplett** | Ersetzt durch Touch-Event-Handler auf Kacheln/Buttons |
+| `.gitignore`, `secrets.h.example` | **1:1 übernehmen** | Muster ist hardwareunabhängig |
+
+**Kurzfassung**: Die komplette `src/api/`-Schicht wandert praktisch unverändert ins neue Repo. Die `src/screens/`-Schicht wird pro Screen in zwei Teile zerlegt: Datenaufbereitung (übernehmen) und Rendering (neu, LVGL-basiert). Nur `main.cpp`, `platformio.ini` und die neue Touch-/Display-Init sind komplett neuer Code.
+
+## 2. Zielarchitektur (neues Repo)
+
+```
+wt32sc01-dashboard/
+├── .gitignore                      (übernommen aus m5stack-dashboard)
+├── platformio.ini                  (neu: esp32-s3, LovyanGFX, LVGL9)
+├── include/
+│   ├── secrets.h.example           (übernommen)
+│   ├── secrets.h                   (lokal)
+│   └── board_pins.h                (neu: WT32-SC01-Plus-Pinout)
+├── src/
+│   ├── main.cpp                    (neu)
+│   ├── display/
+│   │   └── display_setup.cpp/.h    (neu: LovyanGFX-Config, Portrait-Rotation, Touch-Init)
+│   ├── api/                        (portiert, siehe Abschnitt 1)
+│   │   ├── http_client.h/cpp
+│   │   ├── weather_api.h/cpp
+│   │   ├── calendar_api.h/cpp
+│   │   └── departures_api.h/cpp
+│   ├── ui/
+│   │   ├── screen_base.h           (Konzept portiert, LVGL-Basis neu)
+│   │   ├── home_screen.h/cpp       (Datenlogik portiert, Kachel-UI neu)
+│   │   ├── weather_detail_screen.h/cpp   (Datenlogik portiert, Listen-UI neu)
+│   │   ├── calendar_detail_screen.h/cpp  (Datenlogik portiert, Listen-UI neu)
+│   │   ├── mvg_screen.h/cpp        (Datenlogik portiert, Listen-UI neu)
+│   │   └── widgets/
+│   │       ├── tile_button.h/cpp   (neu: wiederverwendbare Touch-Kachel)
+│   │       └── back_button.h/cpp   (neu: wiederverwendbarer Zurück-Button unten links)
+│   └── icons/
+│       └── icons.h                 (teilweise übernommen, teilweise neu gerendert – siehe Task 3)
+├── scripts/
+│   └── deploy.sh                   (übernommen, ggf. Board-Flag angepasst)
+└── README.md                       (neu, verweist auf Referenzprojekt)
+```
+
+## 3. Vorgehen in Phasen
+
+### Phase 0 – Setup
+Neues Repo anlegen, Grundgerüst (PlatformIO-Projekt für `esp32-s3`) erstellen, LovyanGFX + LVGL9 als Dependencies einbinden, `.gitignore`/`secrets.h.example` aus Original übernehmen.
+
+### Phase 1 – Display & Touch zum Laufen bringen
+`board_pins.h` mit verifizierter Pinbelegung, `display_setup.cpp` mit LovyanGFX-Panel-Konfiguration (ST7796, 8-Bit-Parallel), Portrait-Rotation erzwingen (320×480), Touch-Treiber (FT6336U) initialisieren, LVGL-Tick/Loop einbinden. Erfolgskriterium: ein einfaches Testrechteck lässt sich per Touch anwählen.
+
+### Phase 2 – API-Schicht portieren
+`src/api/*` unverändert (oder mit minimalen Anpassungen an neue Ordnerstruktur/Includes) ins neue Repo kopieren, gegen die drei bestehenden Endpunkte (Wetter/Kalender/MVG) testen – unabhängig vom UI, z.B. über Serial-Log-Ausgabe verifizieren, dass JSON korrekt geparst wird.
+
+### Phase 3 – Wiederverwendbare UI-Bausteine
+`tile_button` (große antippbare Kachel mit Icon/Titel/Wert) und `back_button` (fixe Position unten links) als LVGL-Komponenten bauen, da beide auf mehreren Screens verwendet werden.
+
+### Phase 4 – Home-Screen
+Wetter-Kachel, Kalender-Kachel (mit 2 Terminen als Vorschau), kleine MVG-Kachel ohne Vorschau; Touch-Handler pro Kachel verlinken auf jeweilige Detailseite; Regen-Hinweis-Badge auf Wetter-Kachel.
+
+### Phase 5 – Detailseiten
+Wetter-Detail (scrollbare Stundenliste), Kalender-Detail (scrollbare 10-Termine-Liste), MVG-Seite (scrollbare Abfahrtsliste) – jeweils mit `back_button` unten links; Fachlogik (Datenaufbereitung/Formatierung) so weit möglich 1:1 aus den Original-Screens übernehmen.
+
+### Phase 6 – Icons & Feinschliff
+Icon-Set aus `icons.h` sichten, für größeres Display ggf. in höherer Auflösung neu exportieren (siehe Task unten), Refresh-Timer (10 Min/1 Min) und 5-Minuten-Inaktivitäts-Rücksprung einbauen, Fehlerzustände (Retry-Icon) auf allen Screens testen.
+
+### Phase 7 – Deploy & Doku
+`deploy.sh` an Board anpassen (ggf. anderer USB-Chip/Baudrate), README schreiben, finale Tests auf echter Hardware, Repo aufräumen.
+
+## 4. Risiken / Dinge, die beim Portieren zu prüfen sind
+
+- **M5GFX- vs. LovyanGFX-API-Unterschiede**: Falls die Original-Screens direkt M5GFX-Zeichenbefehle nutzen (statt nur Daten aufzubereiten), lässt sich die UI-Logik nicht 1:1 kopieren, sondern muss pro Screen als LVGL-Widget-Baum neu formuliert werden – die Datenaufbereitung (Strings, Werte, Icon-Auswahl) bleibt aber portierbar.
+- **Icon-Format**: RGB565-Arrays aus `icons.h` sind ggf. für 2.0"-Auflösung dimensioniert und müssen für die größere, höher aufgelöste Darstellung auf dem 3.5"-Display neu erzeugt werden (skalieren oder aus Original-Vektoren neu rendern).
+- **Speicher/PSRAM**: LVGL-Framebuffer für 320×480 (bzw. Teilbuffer) muss ins PSRAM des ESP32-S3-WROVER gelegt werden – Buffer-Größen in `display_setup.cpp` entsprechend konfigurieren.
+- **Pin-Variante**: WT32-SC01-Plus-Board-Revisionen unterscheiden sich leicht in der Pinbelegung – vor Phase 1 anhand des konkreten Boards verifizieren.
+
+## 5. Nicht-Ziele
+
+- Kein Rewrite der Backend-APIs (Wetter/Kalender/MVG) – bleiben unverändert.
+- Keine Rückwärtskompatibilität zum M5Stack-Repo (kein gemeinsamer Code, kein Git-Submodule/Fork).
+- Keine Sprachumschaltung/Mehrsprachigkeit, keine neuen Datenquellen – Funktionsumfang bleibt wie in `SPEC.md` beschrieben.
+
+## 6. Offene Punkte
+
+- Der genaue Inhalt von `main.cpp`, den Screen-`.cpp`-Dateien und `icons.h` im Original-Repo konnte technisch noch nicht vollständig ausgelesen werden (GitHub-Tool lieferte bislang nur Dateistruktur/Metadaten, keinen Volltext). Die konkreten Portier-Schritte in Phase 2–6 sollten beim Start der Umsetzung anhand des tatsächlichen Codes verifiziert/verfeinert werden.
+- Exakte Pinbelegung des WT32-SC01 Plus (siehe SPEC.md Abschnitt 11).
+- Name/Ort des neuen Repositories final bestätigen.
@@ -0,0 +1,239 @@
+# M5Stack Core – Wetter/Kalender/MVG Dashboard
+
+_Letztes Update: 2026-08-01 23:16 CEST_
+
+## 1. Ziel
+
+Ein M5Stack Core (ESP32, 2.0" IPS Display, 3 physische Buttons: A, B, C) zeigt Wetter, Kalendertermine und MVG-Abfahrten an. Die Navigation erfolgt ausschließlich über die drei Buttons, es gibt keine Touch-Bedienung. Besonderer Fokus liegt auf einer visuell ansprechenden, **farbigen** UI mit eigenen Bitmap-Icons und einem **dunklen Farbschema**, die trotz des kleinen 2.0" Displays hochwertig aussieht.
+
+## 2. Hardware
+
+- **Gerät**: M5Stack Core (Basic), ESP32-basiert
+- **Display**: 2.0" IPS, 320x240 px
+- **Eingabe**: 3 Buttons (A, B, C)
+- **Netzwerk**: WLAN (Heimnetz, Zugriff auf `*.fritz.box` Hosts)
+
+## 3. Toolchain
+
+- **Build-System**: PlatformIO (kein Arduino IDE)
+- **Deployment**: Eigenes Deploy-Skript, das ausschließlich **Build + Flash** durchführt (kein automatisches Öffnen des seriellen Monitors, kein zusätzlicher Schritt danach). USB-Port wird standardmäßig automatisch erkannt (PlatformIO-Standardverhalten), kann aber optional als Parameter/Umgebungsvariable an das Skript übergeben werden, um einen festen Port zu erzwingen (z.B. `./deploy.sh /dev/ttyUSB0`).
+- **WLAN-Zugangsdaten**: Fest im Code hinterlegt, aber ausgelagert in eine eigene Datei (z.B. `include/secrets.h` oder `src/secrets.cpp`), die per `.gitignore` vom Git-Repo ausgeschlossen wird. Ein `secrets.h.example` mit Platzhaltern wird stattdessen eingecheckt.
+- **Zeitsynchronisation**: Keine eigene NTP-Sync im Gerät. Alle Zeitangaben werden 1:1 so übernommen und dargestellt, wie sie von den APIs geliefert werden (keine relative Umrechnung wie "in 20 Minuten").
+- **Versionskontrolle**: Für den ersten Wurf wird noch kein Git-Repository angelegt bzw. initialisiert (kein `git init`, kein Remote). Die Projektstruktur inkl. `.gitignore` und `secrets.h.example` wird trotzdem von Anfang an sauber vorbereitet, damit später jederzeit unkompliziert `git init` + Remote-Verknüpfung nachgeholt werden kann.
+
+## 4. Datenquellen (APIs)
+
+Alle APIs liegen im lokalen Netz und liefern JSON per HTTP GET.
+
+### 4.1 Wetter-API
+
+- **Endpoint**: `http://docker-host-pve.fritz.box:3088/api/weather`
+- **Methode**: GET
+- **Beispiel-Response**:
+
+```json
+{
+  "current": {
+    "temperature": 20,
+    "symbol": "mo____",
+    "description": "Klar",
+    "emoji": "🌙"
+  },
+  "forecast": [
+    {
+      "time": "2026-08-01T23:00:00+02:00",
+      "temperature": 20,
+      "symbol": "mb____",
+      "description": "Bewölkt",
+      "emoji": "🌙",
+      "precipitation": { "probability": 0.2, "type": "rain" }
+    },
+    {
+      "time": "2026-08-02T00:00:00+02:00",
+      "temperature": 20,
+      "symbol": "mb____",
+      "description": "Bewölkt",
+      "emoji": "🌙",
+      "precipitation": { "probability": 0.2, "type": "rain" }
+    }
+  ]
+}
+```
+
+- `current`: aktuelles Wetter
+- `forecast`: stündliche Vorhersage (im Beispiel 8 Einträge), jeder Eintrag enthält u.a. `precipitation.probability` (0.0–1.0) und `precipitation.type` (z.B. `"rain"`)
+- `symbol`: interner Wettercode (z.B. `mo____` = klar/Mond, `mb____` = bewölkt/Mond, `wb____` = bewölkt/Tag). Wird als Grundlage für die Auswahl des passenden Bitmap-Icons verwendet (siehe Abschnitt 7)
+
+### 4.2 Kalender-API
+
+- **Endpoint**: `http://docker-host-pve.fritz.box:8077/api/events`
+- **Methode**: GET
+- **Liefert**: die nächsten 10 Termine (bereits chronologisch sortiert, serverseitig limitiert)
+- **Beispiel-Response**:
+
+```json
+{
+  "events": [
+    {
+      "id": 205,
+      "summary": "Sommerferien",
+      "description": "",
+      "location": "",
+      "start_at": "2026-08-03T00:00:00",
+      "end_at": "2026-09-15T00:00:00",
+      "all_day": true,
+      "status": "CONFIRMED"
+    },
+    {
+      "id": 113,
+      "summary": "Zahnarzt Nepomuk",
+      "description": "",
+      "location": "",
+      "start_at": "2026-08-03T08:00:00",
+      "end_at": "2026-08-03T09:00:00",
+      "all_day": false,
+      "status": "CONFIRMED"
+    }
+  ],
+  "count": 10,
+  "query_time": "2026-08-01T20:58:37.858934Z"
+}
+```
+
+- Für die Hauptseite werden die ersten 2 Einträge aus `events` verwendet (nächste 2 Termine)
+- `all_day` Termine werden anders dargestellt als Termine mit konkreter Uhrzeit (nur Datum statt Uhrzeit)
+- Zeiten (`start_at`, `end_at`) werden unverändert übernommen, keine Umrechnung/Lokalisierung
+
+### 4.3 MVG-Abfahrten-API
+
+- **Endpoint**: `http://docker-host-pve.fritz.box:8078/api/departures`
+- **Methode**: GET
+- **Beispiel-Response** (gekürzt):
+
+```json
+{
+  "departures": [
+    {
+      "station": "Josephsburg, München",
+      "type": "UBAHN",
+      "icon": "U",
+      "line": "U2",
+      "destination": "Feldmoching",
+      "time_epoch": 1785618120,
+      "time_str": "23:02",
+      "delay_min": -1,
+      "cancelled": false,
+      "messages": []
+    },
+    {
+      "station": "Berg am Laim, München",
+      "type": "SBAHN",
+      "icon": "S",
+      "line": "S2",
+      "destination": "Pasing",
+      "time_epoch": 1785618840,
+      "time_str": "23:14",
+      "delay_min": 4,
+      "cancelled": false,
+      "messages": []
+    }
+  ]
+}
+```
+
+- **Kein Filter**: Es werden alle zurückgelieferten Abfahrten (beide Stationen, U-Bahn und S-Bahn gemischt) angezeigt, in der Reihenfolge wie von der API geliefert
+- `delay_min`: Verspätung in Minuten (kann negativ sein = früher), `cancelled`: Ausfall-Flag
+- `time_str` wird direkt übernommen (keine eigene Zeitberechnung)
+
+## 5. Screens
+
+### 5.1 Hauptseite (Home)
+
+Wird nach Boot standardmäßig angezeigt und ist der "Ruhezustand" des Geräts.
+
+Inhalt:
+- Aktuelle Temperatur + Icon + Beschreibung (aus `current`)
+- Regen-Hinweis (weicher Schwellwert): Sobald irgendein Eintrag der nächsten 8 Vorhersage-Stunden `precipitation.type == "rain"` mit `probability > 0` enthält, wird ein Regen-Hinweis-Icon/Banner angezeigt. Es wird also lieber zu früh als zu spät gewarnt.
+- Nächste 2 Kalendertermine (Summary + Datum/Uhrzeit, `all_day` gesondert markiert)
+
+Refresh: alle 10 Minuten (Wetter + Kalender neu abrufen)
+
+### 5.2 Wetter-Detailseite
+
+Inhalt:
+- Aktuelles Wetter (ausführlicher als Home)
+- Stundenweise Vorhersage aus `forecast` (Zeit, Temperatur, Icon, Regenwahrscheinlichkeit) mit Icons statt Text wo sinnvoll
+
+### 5.3 Kalender-Detailseite
+
+Inhalt:
+- Liste aller 10 Termine aus `events` (nicht nur die ersten 2 wie auf der Hauptseite)
+
+### 5.4 MVG-Abfahrtsseite
+
+Inhalt:
+- Liste aller Abfahrten aus `departures`, ohne Filterung nach Station oder Linie (Linie, Ziel, Zeit, Verspätung, ggf. Ausfall-Hinweis)
+
+Refresh: jede Minute
+
+## 6. Navigation (Buttons)
+
+| Button | Funktion |
+|---|---|
+| A | Wechselt zwischen den Detailseiten Wetter und Kalender (Toggle) |
+| B | Springt zurück zur Hauptseite |
+| C | Öffnet die MVG-Abfahrtsseite |
+
+- Automatischer Rücksprung zur Hauptseite nach 5 Minuten Inaktivität (kein Button-Druck), unabhängig davon, auf welcher Seite man sich gerade befindet
+
+## 7. UI- und Icon-Konzept
+
+Ein zentraler Bestandteil des Projekts ist eine hochwertige, **farbige** und für das kleine Display optimierte Oberfläche, kein reiner Text-Dump.
+
+- **Farbschema "iPhone Dark Mode"-Look**: Primär reines/sehr dunkles Schwarz (`#000000` bzw. `#0B0B0D`-ähnlich) als Hintergrund mit weißem bzw. sehr hellem Text (`#FFFFFF` / `#F2F2F7`) als Basis, ganz im Stil von iOS Dark Mode. Farbe wird bewusst zurückhaltend und dezent als Akzent eingesetzt (z.B. gedämpfte Blau-/Grüntöne für Wetter, eigene dezente Akzentfarbe für Kalender, an echte MVV-Linienfarben angelehnte, aber nicht grelle Töne für U-Bahn/S-Bahn), nicht als große flächige Buntheit
+- **Eigene farbige Bitmap-Icons** statt Unicode-Emojis (M5Stack-Displays unterstützen keine nativen Emoji-Fonts). Icons werden als eingebettete Bitmaps (RGB565-Arrays) im Code hinterlegt, nicht als Dateien auf SD-Karte, um Ladezeiten zu vermeiden
+- **Icon-Set mindestens für**: Sonne/klar, bewölkt, Regen, Nacht-Varianten (basierend auf dem `symbol`-Feld, z.B. `mo____`, `mb____`, `wb____`), U-Bahn-Symbol, S-Bahn-Symbol, Kalender-Symbol, Warn-/Regen-Hinweis-Symbol, Retry-/Fehler-Symbol – alle farbig statt monochrom
+- **Layout-Prinzipien**: Klare visuelle Hierarchie (große Temperatur, kleinere Nebeninfos), hoher Kontrast durch schwarz/weiß als Basis, moderne, aufgeräumte, iOS-inspirierte Optik ohne überladene Screens, dezente Akzentfarben statt vieler bunter Flächen
+- **Typografie**: Angepasste, gut lesbare, weiße Schriftgrößen für das 320x240 Display vor schwarzem Hintergrund, wichtige Werte (Temperatur, Abfahrtszeit) deutlich größer und ggf. fett gegenüber Nebeninfos, ganz im Stil moderner iOS-Widgets
+
+## 8. Fehlerbehandlung
+
+- Bei nicht erreichbarer API: Einfache Fehleranzeige auf dem betroffenen Screen (z.B. Retry-Icon + kurzer Text wie "Keine Verbindung")
+- **Retry-Auslöser**: Automatisch beim nächsten regulären Refresh-Intervall der jeweiligen Seite (10 Minuten bzw. 1 Minute), zusätzlich manuell durch erneuten Tastendruck auf den Button, der die aktuelle Seite aufruft
+- Kein Vorhalten "letzter bekannter Werte" über den Fehlerzustand hinaus gefordert, es genügt die einfache Fehleranzeige bis zum nächsten erfolgreichen Refresh
+
+## 9. Refresh-Intervalle
+
+| Seite/Datenquelle | Intervall |
+|---|---|
+| Hauptseite (Wetter + Kalender) | 10 Minuten |
+| MVG-Abfahrtsseite | 1 Minute |
+| Wetter-Detailseite | folgt Hauptseiten-Intervall (10 Minuten), da gleiche Datenquelle |
+| Kalender-Detailseite | folgt Hauptseiten-Intervall (10 Minuten), da gleiche Datenquelle |
+
+## 10. Projektstruktur (PlatformIO)
+
+Git-Initialisierung und Remote-Verknüpfung erfolgen bewusst zu einem späteren Zeitpunkt, nicht in diesem ersten Schritt. Die Ordnerstruktur wird aber von Anfang an git-freundlich vorbereitet:
+
+```
+/
+├── .gitignore              (schließt u.a. include/secrets.h, .pio/ aus – bereits vorbereitet für späteres git init)
+├── platformio.ini
+├── include/
+│   ├── secrets.h.example   (Platzhalter für WLAN, später einzuchecken)
+│   └── secrets.h           (lokal, später nicht einzuchecken)
+├── src/
+│   ├── main.cpp
+│   ├── screens/            (Home, WeatherDetail, CalendarDetail, MVG)
+│   ├── api/                (HTTP-Clients für Weather, Calendar, MVG)
+│   └── icons/              (farbige Bitmap-Icon-Definitionen, RGB565)
+├── scripts/
+│   └── deploy.sh           (Build + Flash via PlatformIO CLI, USB-Port automatisch erkannt oder optional als Parameter übergeben, kein Monitor)
+└── README.md
+```
+
+- `deploy.sh` ruft im Kern `pio run --target upload` auf; ohne Parameter wird der Port automatisch erkannt, mit Parameter (z.B. `./deploy.sh /dev/ttyUSB0`) wird ein fester Port erzwungen. Kein automatisches Starten des seriellen Monitors oder weiterer Schritte danach.
+
+## 11. Offene Punkte / Rückfragen
+
+Aktuell keine offenen Punkte mehr, alle wesentlichen Entscheidungen (Toolchain, UI-Stil, Farbschema, Git-Timing, USB-Port-Handling) sind getroffen. Git-Initialisierung und Remote-Repo werden bewusst erst in einem späteren Schritt nachgeholt, sobald der Code lokal funktioniert.
@@ -0,0 +1,76 @@
+# TODO – WT32-SC01 Plus Dashboard
+
+_Letztes Update: 2026-08-02_ · Details/Begründungen siehe `PLAN.md`, Fachanforderungen siehe `SPEC.md`
+
+## Phase 0 – Setup
+
+- [ ] Neues GitHub-Repository anlegen (Vorschlag: `wt32sc01-dashboard`)
+- [ ] `git init` lokal, Remote verknüpfen, erster Commit (leeres PlatformIO-Grundgerüst)
+- [ ] `platformio.ini` neu anlegen: Board `esp32-s3`, Framework `arduino`, PSRAM aktivieren
+- [ ] LovyanGFX und LVGL (v9) als Lib-Dependencies eintragen
+- [ ] `.gitignore` aus `m5stack-dashboard` übernehmen (inkl. `include/secrets.h`, `.pio/`)
+- [ ] `include/secrets.h.example` aus Original übernehmen, `include/secrets.h` lokal anlegen (nicht committen)
+
+## Phase 1 – Display & Touch
+
+- [ ] Exakte Pinbelegung des konkret vorliegenden WT32-SC01-Plus-Boards verifizieren (Display-Datenbus, WR/RD/DC/CS/RST, Backlight, Touch-I2C SDA/SCL/INT)
+- [ ] `include/board_pins.h` mit verifizierten Pin-Defines anlegen
+- [ ] `src/display/display_setup.cpp/.h`: LovyanGFX-Panel-Konfiguration für ST7796 (8-Bit-Parallel/i80) erstellen
+- [ ] Display-Rotation auf Portrait (320×480) erzwingen
+- [ ] Touchcontroller FT6336U initialisieren (I2C) und in LVGL als Input-Device registrieren
+- [ ] LVGL-Tick-Timer (`lv_tick_inc`) und Haupt-Loop (`lv_timer_handler`) einbauen
+- [ ] Testscreen mit einem einzelnen antippbaren Button bauen, Touch-Koordinaten/Kalibrierung verifizieren
+
+## Phase 2 – API-Schicht portieren
+
+- [ ] `src/api/http_client.h/cpp` aus Original-Repo in neues Repo kopieren, Includes/Namespaces anpassen
+- [ ] `src/api/weather_api.h/cpp` kopieren, gegen Endpoint `http://docker-host-pve.fritz.box:3088/api/weather` testen
+- [ ] `src/api/calendar_api.h/cpp` kopieren, gegen Endpoint `http://docker-host-pve.fritz.box:8077/api/events` testen
+- [ ] `src/api/departures_api.h/cpp` kopieren, gegen Endpoint `http://docker-host-pve.fritz.box:8078/api/departures` testen
+- [ ] Alle drei API-Clients unabhängig vom UI verifizieren (Serial-Log: Parsing korrekt, Felder vollständig)
+- [ ] WLAN-Verbindungsaufbau (Setup-Routine) aus Original übernehmen/anpassen
+
+## Phase 3 – Wiederverwendbare UI-Bausteine
+
+- [ ] `src/ui/widgets/tile_button.h/cpp`: LVGL-Kachel-Komponente (Icon + Titel + optionaler Wert/Vorschau-Text), touch-tauglich groß dimensioniert
+- [ ] `src/ui/widgets/back_button.h/cpp`: fixer Zurück-Button unten links, auf allen Detailseiten wiederverwendbar
+- [ ] Gemeinsames Farbschema/Theme (Dark Mode, Akzentfarben pro Kategorie) als LVGL-Style-Konstanten definieren
+- [ ] `src/ui/screen_base.h`: gemeinsame Screen-Lifecycle-Abstraktion (create/show/hide/refresh) für LVGL
+
+## Phase 4 – Home-Screen
+
+- [ ] `src/ui/home_screen.h/cpp`: Layout mit Wetter-Kachel (groß, oben), Kalender-Kachel (groß, mit 2 Terminen), MVG-Kachel (klein, ohne Vorschau)
+- [ ] Fachlogik aus Original `home_screen.cpp` übernehmen: Temperatur/Icon/Beschreibung-Aufbereitung, Regen-Hinweis-Schwellwert-Logik, Termin-Formatierung (`all_day` vs. Uhrzeit)
+- [ ] Touch-Handler: Tap auf Wetter-Kachel → Wetter-Detail, Tap auf Kalender-Kachel → Kalender-Detail, Tap auf MVG-Kachel → MVG-Seite
+- [ ] Regen-Hinweis-Badge auf Wetter-Kachel einbauen
+- [ ] Refresh-Timer 10 Minuten (Wetter + Kalender) einbauen
+
+## Phase 5 – Detailseiten
+
+- [ ] `src/ui/weather_detail_screen.h/cpp`: scrollbare Stundenliste (Zeit, Temperatur, Icon, Regenwahrscheinlichkeit), Fachlogik aus Original übernehmen
+- [ ] `src/ui/calendar_detail_screen.h/cpp`: scrollbare Liste aller 10 Termine, Fachlogik aus Original übernehmen
+- [ ] `src/ui/mvg_screen.h/cpp`: scrollbare Liste aller Abfahrten (Linie, Ziel, Zeit, Verspätung, Ausfall-Hinweis), Fachlogik aus Original übernehmen
+- [ ] `back_button`-Widget auf allen drei Detailseiten unten links einbinden und verdrahten
+- [ ] Refresh-Timer 1 Minute für MVG-Seite einbauen
+
+## Phase 6 – Icons & Feinschliff
+
+- [ ] `icons.h` aus Original sichten: welche Icons sind direkt übernehmbar, welche müssen in höherer Auflösung neu exportiert werden
+- [ ] Fehlende/größere Icon-Varianten neu rendern (RGB565-Arrays), Icon-Set vervollständigen (inkl. Zurück-Pfeil-Icon, das es im Original nicht gab)
+- [ ] 5-Minuten-Inaktivitäts-Timer (automatischer Rücksprung zur Hauptseite) implementieren
+- [ ] Fehlerzustände (API nicht erreichbar) auf allen Screens mit Retry-Icon/Text umsetzen, manueller Retry per Tap
+- [ ] Visuelle Feinabstimmung: Schriftgrößen, Abstände, Kachel-Farben gegen Referenzbild/SPEC.md prüfen
+
+## Phase 7 – Deploy & Doku
+
+- [ ] `scripts/deploy.sh` aus Original übernehmen, Board-Flag/Baudrate für WT32-SC01 Plus anpassen
+- [ ] Testen: Build + Flash über `deploy.sh` ohne Parameter (Auto-Port) und mit explizitem Port
+- [ ] `README.md` schreiben (Setup-Anleitung, Verweis auf `m5stack-dashboard` als Referenzprojekt)
+- [ ] End-to-End-Test auf echter Hardware: alle 4 Screens, alle Touch-Interaktionen, beide Refresh-Intervalle, Inaktivitäts-Rücksprung, Fehlerfall (WLAN/API trennen)
+- [ ] Repo aufräumen (nicht benötigte PlatformIO-Boilerplate entfernen), finalen Commit/Tag setzen
+
+## Blocker / braucht Klärung
+
+- [ ] Original-Quelltext (`main.cpp`, Screen-`.cpp`-Dateien, `icons.h`) muss noch im Detail eingesehen werden (GitHub-Tool lieferte bisher nur Struktur, keinen Volltext) – vor Phase 2/4/5/6 nachholen, um exakte Portier-Aufwände zu bestätigen
+- [ ] Pinbelegung WT32-SC01 Plus am konkreten Board verifizieren (Blocker für Phase 1)
+- [ ] Name des neuen Repositories final bestätigen