flyradar/CLAUDE.md

Eiswolfs Flightradar (CYD) — Projektkontext für Claude Code

Lies diese Datei ZUERST, bevor du irgendwas am Code änderst. Sie enthält die Dinge, die man wissen muss, um nicht dieselben Fehler nochmal zu machen, die in der Entwicklung schon mal aufgetreten und behoben wurden.

Was ist das Projekt?

Ein Live-ADS-B-Flugradar auf einem ESP32 "Cheap Yellow Display" (CYD, ESP32-2432S028), 240x320 Touch-TFT. Zeigt Flugzeuge in der Nähe auf einem rotierenden Radarschirm, mit Detail-Panel (Modell, Höhe, Speed, Route, Squawk), Näherungs-LED-Alarm, WLAN-Verwaltung (bis zu 3 Netzwerke), Standort-Presets (auch für fremde Orte weltweit), Airline-Filter, Flugbuch mit Statistik, und Menüs/Splash-Screen mit einer dezenten twinkelnden Sterne-Animation.

Aktueller Stand: v2.3.2. Öffentliches Repo: https://github.com/Eiswolf-BG/eiswolfs-flightradar-CYD

Wer nutzt das?

Alex — kompletter Anfänger bei Arduino/Embedded-Entwicklung, arbeitet mit VS Code + PlatformIO auf einem Mac. Bitte auf Deutsch antworten. Erklärungen gerne etwas ausführlicher, nicht von Fachbegriffen ausgehen, die als bekannt vorausgesetzt werden.

Tech-Stack

• PlatformIO, platform = espressif32, board = esp32dev, framework = arduino
• TFT_eSPI (Display), XPT2046_Touchscreen (Touch), ArduinoJson, TinyGPSPlus
• Dual-Core-Design: Netzwerk (WLAN, ADS-B-Polling) auf Core 0, Display/Touch auf Core 1 — die UI blockiert nie durch Netzwerk-Requests.
• Daten: adsb.fi (Flugzeugpositionen), hexdb.io (Modell-Lookups), ip-api.com (IP-Geolocation)

⚠️ WICHTIGSTE FALLE: Der eigene Font ist grundlinien-verankert

Die eingebauten TFT_eSPI-Fonts (GLCD, Font2 etc.) sind reines ASCII. Für Umlaute/Akzente (Deutsch, Türkisch, Französisch, Spanisch, Italienisch) gibt's einen selbst generierten Font (src/ui_font.h, via tft.setFreeFont(&UiFont11pt) global in main.cpp::setup() aktiviert, gilt danach für JEDEN print()/drawString()-Aufruf in der ganzen App).

Der entscheidende Unterschied zu den eingebauten Fonts: Bei setCursor(x, y); print(...) ist y bei unserem Font die Grundlinie (Baseline), NICHT die obere Kante wie beim alten GLCD-Font. Der Text wächst von y aus nach OBEN (um den Ascent, ca. 9px bei Size 1, ca. 16-18px bei Size 2), nicht nach unten.

Das hat in der Vergangenheit zu folgenden Bugs geführt (alle behoben, aber Vorsicht bei neuem Code!):

• Zu kleine y-Werte (z.B. setCursor(10, 2)) → Text ragt oben aus dem Bildschirm/Container heraus oder wird abgeschnitten. Faustregel: y sollte bei Size 1 nie kleiner als ~14 sein, bei Size 2 nie kleiner als ~24-26 (abhängig vom Container).
• Eingabefelder/Boxen: Baseline muss nahe der UNTERKANTE der Box liegen, nicht in der Mitte wie man's vom alten Font gewohnt wäre.
• Zwei Textgrößen kurz hintereinander in einem eng bemessenen Layout (Label Size 1 direkt über Wert Size 2) sind fehleranfällig — im Statistik-Screen deshalb bewusst auf EINHEITLICHE Größe (nur Farbe unterscheidet Label/Wert) umgestellt, das ist robuster.
• drawString() mit setTextDatum(MC_DATUM) (zentriert) ist NICHT betroffen — TFT_eSPI rechnet die Zentrierung selbst korrekt aus, egal ob Baseline- oder Top-verankert. Nur rohes setCursor()+print() ist die Gefahrenzone.
• Langer, mehrzeiliger Text (z.B. Erklärtexte) NIE mit TFT_eSPI's eingebautem Auto-Wrap verlassen — das bricht mitten im Wort ab. Stattdessen den layoutWrapped()-Helper verwenden (in location_presets_screen.cpp und wifi_manage_screen.cpp je einmal implementiert, macht wortweisen Umbruch anhand echter Pixel-Breite plus optionales Scrollen).

Falls neue Screens/Textstellen dazukommen: lieber einmal mehr testen (idealerweise mit Foto vom echten Display), bevor der Code als fertig gilt.

i18n (6 Sprachen)

• src/i18n.h: enum class StringId — jeder feste UI-Text hat eine ID.
• src/i18n_en.h, i18n_de.h, i18n_fr.h, i18n_tr.h, i18n_es.h, i18n_it.h: je ein static const char* const[]-Array, in exakt derselben Reihenfolge wie das Enum.
• Jede Datei hat am Ende einen static_assert, der die Array-Größe gegen StringId::COUNT prüft — wenn der Build wegen eines fehlschlagenden static_assert bricht, fehlt in mindestens einer Sprachdatei ein Eintrag oder es ist einer zu viel. Neue StringId → in ALLEN 6 Dateien an derselben Position ergänzen, sonst verschiebt sich die Zuordnung.
• Eigennamen der Sprachen (I18n::languageName()) sind separat in i18n.cpp hinterlegt, mit korrekten landessprachlichen Sonderzeichen (z.B. "Français", "Türkçe", "Español").

UI-Konventionen (bitte einhalten für neue Screens)

• Farbschema: Schwarzer Hintergrund, grüner Rahmen/Text (TFT_BLACK/TFT_GREEN), aktive/ausgewählte Einträge invertiert (grün gefüllt, schwarzer Text). Destruktive Aktionen (Abbrechen/Löschen) in Rot (TFT_RED).
• Jeder Screen hat i.d.R. eine lokale struct Rect mit contains(x,y) und eine drawButton()-Hilfsfunktion (Copy-Paste-Muster aus den bestehenden Screens, kein gemeinsames Rect/Button-Modul — das ist bewusst so, um jeden Screen unabhängig lauffähig zu halten).
• Sterne-Animation (src/menu_stars.h/.cpp): Läuft im Hintergrund auf JEDEM schwarzen Menü-/Splash-Screen. Neue Screens sollten MenuStars::reset() einmal beim Betreten aufrufen und MenuStars::update(tft) in jeder Warte-/Idle-Schleife (Loop läuft sonst ungenutzt, da die Funktion sich intern selbst auf ~60ms drosselt).
• Warteschleifen-Pattern für Touch-Eingabe:

  TouchInput::Point tap;
  while (true) {
      if (TouchInput::wasTapped(tap)) break;
      MenuStars::update(tft);
      delay(20);
  }
  

• Menüstruktur: Hauptmenü → 4 Kategorien (Land/Region, WLAN/Netzwerk, System, Flugoptionen) → jeweils Unterseiten. WLAN/Netzwerk hat aktuell KEIN eigenes Untermenü mehr, springt direkt in die Netzwerk-Verwaltung.
• Viele Screens mit Text-Eingabe (Airline-Code, Koordinaten, WLAN-Passwort) haben einen "?"-Info-Button oben rechts, der einen scrollbaren Erklär-Screen öffnet (Muster: location_presets_screen.cpp und wifi_manage_screen.cpp, jeweils eigene layoutWrapped()-Kopie).

Sonstige feste Werte (Config::…)

• Näherungsalarm-Radius: 3 km
• Notfall-Squawks: 7500 (Entführung), 7600 (Funkausfall), 7700 (Notfall)
• Radar-Reichweiten: 10/25/50/100 km
• ADS-B-Abruf-Intervall: alle 8 Sekunden
• Höhen-Farbcodierung: Grün <10.000ft, Gelb 10-30.000ft, Rot >30.000ft
• Max. 3 WLAN-Netzwerke, max. 3 Standort-Presets, max. 10 gefilterte Airlines

Code-Stil

• Kommentare durchgehend auf Deutsch, ohne Umlaute in Kommentaren selbst unüblich (ae/oe/ue sind hier ok, das ist nur ein Stil-Ding für Kommentare, NICHT für die UI-Texte in den i18n-Dateien — dort echte Umlaute verwenden, siehe oben).
• Build-Check nach JEDER Änderung: pio run im Projektverzeichnis, auf Warnungen UND Errors prüfen (nicht nur "compiles").
• Immer least-invasive Änderungen bevorzugen — bestehende Funktionen/Namen nicht ohne Grund umbenennen.

Sprache: Projekt-Außendarstellung immer Englisch

Alle nach außen sichtbaren Texte sind IMMER auf Englisch zu verfassen — unabhängig davon, in welcher Sprache die Unterhaltung mit Alex geführt wird. Das betrifft insbesondere:

• README.md
• index.html (Webseite/Flasher-Seite)
• GitHub-Release-Notes / -Beschreibungen
• Commit-Messages
• Jeglicher sonstiger Beschreibungs- oder Bugfix-Text, der öffentlich sichtbar ist (z.B. auf GitHub)

Ausnahme: Die Firmware-UI selbst bleibt mehrsprachig wie gehabt (i18n_de/en/fr/tr/es/it.h) — diese Regel betrifft NUR die Projekt-Außendarstellung (Repo, Release Notes, Webseite), nicht die App-Oberfläche auf dem Gerät. Interne Code-Kommentare bleiben ebenfalls wie gehabt auf Deutsch (siehe „Code-Stil" oben) — diese Regel gilt nur für nach außen sichtbare Texte.

Bekannte offene Punkte / mögliche nächste Schritte

Keine akuten offenen Bugs bekannt (Stand v2.3.2). Mögliche Ideen für später, falls der Nutzer danach fragt: weitere Menüs mit Info-Buttons versehen, ggf. weitere Sprachen, ggf. Export/Teilen der Logbuch-Daten.

Standard-Workflow: Push & Release

WICHTIG - wann dieser Workflow startet: Der komplette Release-Workflow (README-Update, Commit, Tag, Push) darf NUR gestartet werden, wenn Alex EXPLIZIT danach fragt (z.B. "lass pushen", "können wir releasen", "mach den Release-Workflow"). Ein einfaches "ja" auf eine Rückfrage (z.B. zu einer CLAUDE.md-Änderung oder einem anderen Detail) ist KEINE Aufforderung, den Release-Workflow zu starten. Bei kleineren Fixes/Änderungen bitte NUR bauen und flashen (siehe Abschnitt "Nach jedem erfolgreichen Build automatisch flashen" unten), aber NICHT committen/taggen/pushen, bis ausdrücklich danach gefragt wird.

Sobald der Workflow explizit angefordert wurde, automatisch folgende Schritte in dieser Reihenfolge:

0. Versionsnummer festlegen: Die neue Versionsnummer kommt IMMER exakt von Alex - er nennt sie im Push-Wunsch (z.B. über Claude/den Sandbox- Assistenten: "Alex will auf Version X.Y.Z pushen"). Karl trägt GENAU diese Nummer in Config::APP_VERSION (src/config.h) ein - niemals selbst hochzählen, erraten oder von der letzten Version ableiten (auch nicht bei kleinen Patches). Das gilt auch für größere Sprünge (z.B. 2.6 -> 3.0), die Alex bewusst und absichtlich machen kann - Karl übernimmt in jedem Fall die genannte Nummer 1:1, ohne eigene Annahmen. Falls im Push-Wunsch keine explizite Versionsnummer genannt wurde, bei Alex nachfragen statt zu raten. Erst NACH dem Eintragen der korrekten Nummer: einmal sauber pio run bauen, DANACH erst der Rest des bekannten Workflows (README, Tag, index.html, Bin-Dateien, Commit/Push). (Hier bewusst NUR bauen, NICHT flashen - Ausnahme von der sonst geltenden Auto-Flash-Regel, siehe Abschnitt "Nach jedem erfolgreichen Build automatisch flashen" weiter unten. Das Testgerät soll auf der bisherigen Version bleiben, damit das neue Release per OTA getestet werden kann.)

1. Prüfen, ob seit dem letzten Commit neue/geänderte Features hinzugekommen sind, die für Endnutzer sichtbar sind (neue Menüpunkte, geändertes Verhalten, neue Screens) - falls ja, README.md entsprechend ergänzen (gleicher Stil: Emoji-Überschriften, Ankerlinks zwischen "Features"-Liste und den Deep-Dive-Sektionen, kurze Beispiele wo sinnvoll). Reine interne Bugfixes/Refactorings ohne sichtbare Nutzerauswirkung brauchen keinen README-Eintrag.

2. Code committen (aussagekräftige Commit-Message).

3. Falls es sich um einen Versionssprung handelt: Git-Tag mit Versionsnummer + Beschreibung der Änderungen erstellen.

4. Prüfen, ob index.html (Web-Flasher) noch die alte Versionsnummer zeigt - falls ja, aktualisieren. NICHT OPTIONAL, darf bei KEINEM Release-Push übersprungen werden - auch nicht bei kleinen Patch-Versionen. Immer als fester Doppel-Schritt zusammen mit Schritt 1 (README) behandeln: wann immer die README (oder auch nur die Versionsnummer) auf eine neue Version aktualisiert wird, IMMER im selben Zug auch index.html prüfen und synchron mitziehen. 4b. Web-Flasher-Versionsauswahl aktuell halten: Bevor die Wurzel-.bin-Dateien mit dem neuen Build überschrieben werden, die BISHERIGEN (noch alten) bootloader.bin/partitions.bin/firmware.bin in einen neuen Ordner versions/vALT/ archivieren (vALT = die Versionsnummer, die index.html vor diesem Update zeigte) - dort auch eine manifest.json ablegen (identischer Inhalt wie die Wurzel-manifest.json, siehe versions/v3.6.2/manifest.json als Vorlage). Danach im Ordner versions/ nur die 2 neuesten Versionsordner (nach Versionsnummer sortiert, nicht nach Datei-Datum) behalten - ältere Ordner löschen. Anschließend in index.html den Versions-Dropdown (<select id="versionSelect">) aktualisieren: 3 Optionen - die neue aktuelle Version (value="manifest.json", data-version="vNEU", Text "vNEU (latest)") plus die beiden jetzt in versions/ verbliebenen Versionen (value="versions/vX.Y.Z/manifest.json", neueste zuerst).

5. Prüfen, ob bootloader.bin, firmware.bin, partitions.bin im Hauptverzeichnis dem aktuellen Build in .pio/build/esp32dev/ entsprechen - falls nicht, von dort kopieren.

6. Alle diese Änderungen (Code + README + Web-Flasher-Dateien) zusammen committen und pushen (git push, plus git push origin vX.Y.Z falls ein Tag erstellt wurde).

7. GitHub Release erstellen UND die .bin-Datei in einem Schritt hochladen (per gh CLI, seit v2.7.5 eingerichtet und authentifiziert - siehe gh auth status). Das Release-Asset heißt einfach firmware.bin, keine Umbenennung nötig - die meisten Nutzer laden ohnehin über den Web-Flasher, das Asset ist nur noch für die wenigen Leute relevant, die über eine CYD-Launcher-App direkt eine .bin-Datei brauchen (dafür ist der Dateiname egal):

   gh release create vX.Y.Z .pio/build/esp32dev/firmware.bin \
       --repo Eiswolf-BG/eiswolfs-flightradar-CYD \
       --title "vX.Y.Z" \
       --notes "<Release-Notes-Text>"
   

   Der Release-Notes-Text kommt aus dem jeweiligen Push-Wunsch (derselbe Text, der auch für die Tag-Message verwendet wird) - falls im Push-Wunsch kein Text mitgegeben wurde, aus dem git log seit dem letzten Tag ableiten, wie bisher auch für die Tag-Message.

8. Kurze Zusammenfassung am Ende: was committet/getaggt/gepusht wurde, ob die README aktualisiert wurde (und falls ja, welche Abschnitte), sowie die URL des erstellten GitHub Release. Der GitHub-Release-Schritt ist damit vollautomatisch - kein manuelles Nacharbeiten von Alex mehr nötig, außer gh sollte einmal die Authentifizierung verlieren (dann erneut gh auth login, siehe oben).

Nach jedem erfolgreichen Build automatisch flashen

Sobald pio run (Build) erfolgreich ohne Fehler durchgelaufen ist, IMMER direkt im Anschluss auch flashen (pio run --target upload), ohne extra danach zu fragen - außer der Nutzer sagt ausdrücklich "nur bauen, nicht flashen" o.ä. Kurz danach bestätigen, dass der Upload ebenfalls erfolgreich war (inkl. "[SUCCESS]"-Zeile am Ende).

AUSNAHME: Innerhalb der Push & Release-Routine (siehe Abschnitt "Standard-Workflow: Push & Release") NICHT automatisch flashen, selbst nach erfolgreichem Build - dort wird bewusst nur gebaut. Grund: Alex möchte das Testgerät auf der bisherigen Version belassen, um das neue Release anschließend über die OTA-Update-Funktion zu testen, statt es direkt per Kabel zu flashen. Für alle anderen Anlässe (normales Entwickeln/Testen, einzelne Fixes) gilt die automatische Flash-Regel unverändert weiter.

Bitte diese Regel jetzt in die CLAUDE.md-Datei einpflegen.