- resetSession() umbenannt in resetSessionSum() (klarere Semantik)
- Bug fix: resetSessionSum() setzt laufende Session-Timer korrekt zurueck
(vorher: getAllSessionsSumMinutes() blieb > 0 nach Reset)
- consumeSessionReset() nach consumeSessionEnd()-Muster (consume-Semantik)
- Vor Reset: akkumulierte Netto-Sekunden sichern -> publishSession() wie Session-Ende
- MQTT: payload {reset_session:true} via lasercutter/reset loest resetSessionSum() aus
- MQTT: Session-Reset publiziert identisches JSON wie normales Session-Ende
- Web: Button-Layout ueberarbeitet (alle 3 Buttons blau, uebereinander, gleich breit)
- Docs: README.md + Implementation-Plan.md aktualisiert
1.4 KiB
1.4 KiB
ESP32 Webinterface-Bibliotheken – Überblick
Direkte Alternativen (ESP32-spezifisch)
ESPDash (empfehlenswert für diesen Use Case)
- Fertige Dashboard-Komponenten: Karten, Buttons, Slider, Charts
- Kommunikation über WebSocket → Live-Updates ohne Reload
- Sehr wenig Code nötig
- Basiert auf ESPAsyncWebServer (passt zum bestehenden Stack)
ArduinoJson + SPIFFS/LittleFS
- HTML-Dateien im Flash-Dateisystem ablegen, nicht als C-Strings
- Macht die HTML-Dateien bearbeitbar ohne Neukompilierung
- Kein Bibliothek-Overhead, aber saubere Trennung von Code und Markup
Minimalistische String-Builder
ESPStringTemplate / Templater
- Nur Platzhalter-Ersetzung, ähnlich der aktuellen manuellen
html.replace()-Lösung - Kaum Mehrwert gegenüber der aktuellen Implementierung
Schwergewichtig (eher nicht für ESP32)
ESP-IDF HTTP Server + React/Vue Build
- Zu groß, zu komplex für diesen Einsatzzweck
Fazit für dieses Projekt
Die aktuelle Lösung (rohe C-Strings + html.replace()) ist für ein so kleines Interface optimal:
- Kein Flash-Overhead
- Keine externe Abhängigkeit
- Volle Kontrolle
ESPDash wäre der einzige echte Gewinn, wenn Live-Werte (Laserzeit, Status) ohne Reload aktualisiert werden sollen — das funktioniert dort via WebSocket automatisch.
Für eine reine Statusseite mit 10-Sekunden-Auto-Reload wie aktuell lohnt sich der Wechsel jedoch kaum.