Dual-PID/CLAUDE.md

Projekt-Orientierung

Dieses Repository ist die Steuerung einer Espresso-/Siebträgermaschine (Dual-PID, Wasser- und Dampfkessel getrennt geregelt). Sie besteht aus zwei getrennten Firmwares für zwei Mikrocontroller, die per UART (230400 8N1, JSON-Zeilen) verbunden sind:

• ESP32-S3 – Hauptsteuerung in der Maschine (Source of Truth). Datei: Dual_PID_FastHeatUp.ino (im Projekt-Root). Regelt PID/Heizungen/SSRs, Pumpe/Ventile, Waage (HX711/Brew-by-Weight), Standby/Eco, Profile, Nutzungsstatistik und stellt die Web-UI + WLAN + OTA bereit. Änderungshistorie: Changelog.txt (Root), Version steht in String version = "…".

• ESP32-P4 – UART-Touch-Display (spiegelt den S3-Zustand). Ordner: JC_Display_Firmware/ (Hauptsketch JC_Display_Firmware.ino, UI in ui.cpp/ui.h, UART-Protokoll in protocol_client.*, LVGL 9.x). Hat kein eigenes WLAN (der ESP32-C6-Co-Prozessor ist ungenutzt); alle Daten kommen über UART vom S3. Eigene Version DISPLAY_FW_VERSION + JC_Display_Firmware/Changelog.txt.

Wenn ich „S3/Controller/Maschine" sage, ist Dual_PID_FastHeatUp.ino gemeint; „P4/Display" ist der Ordner JC_Display_Firmware/.

Nicht anfassen: Der Ordner Sicherungen/ enthält nur datierte Versions-Backups (.ino) — niemals dort editieren. Unter JC_Display_Firmware/JC4880P443C_I_W/ liegen reine Hersteller-Demos/Beispiele (Board-Support), ebenfalls nicht als Projektcode behandeln.

Agent Instructions

• UI-Texte muessen immer in allen verfuegbaren Anwendungssprachen hinterlegt oder geaendert werden. Wenn neue UI-Strings entstehen, sind die entsprechenden Sprachdateien vollstaendig zu ergaenzen.
• Dateien duerfen generell nur ohne BOM geschrieben werden. Textdateien sind als UTF-8 ohne BOM anzulegen oder zu aktualisieren.
• Sprachstrings/Texte sind immer mit Umlauten zu schreiben

Git-Workflow

• Host: Gitea git.mueller.black, Repo thomas/Dual-PID, User thomas, CLI tea.
• Aenderungen immer ueber Feature-Branch + Merge-Request (tea pr create), nie direkt auf main committen oder pushen.
• Pull/Merge-Requests dürfen immer selbstständig gemergt werden (Auto-Merge, kein grünes CI erforderlich, via tea pr merge oder Gitea-API); danach den Merge kurz melden.
• Kein Force-Push, kein History-Rewrite auf geteilten Branches.
• Commit-Identitaet bleibt raw-designs / Thomas@raw-designs.de (globale Git-Config, nicht aendern).
• Commit-Messages im Conventional-Commits-Format (feat/fix/docs/refactor/...).
• Auch Branch-Namen, Commit-Messages sowie PR-Titel und -Beschreibungen sind mit echten Umlauten zu schreiben (sofern technisch möglich).