[Session 2026-06-23] Pruefstand Web-Dashboard + ESP8266 Flash #126

Open
opened 2026-06-23 15:26:12 +00:00 by orbitalo · 1 comment
Owner

Was wurde gemacht

  • ESP8266 Testknecht geflasht (firmware via esptool.py auf pve-mu-3 /dev/ttyUSB0)
  • Hardware-Problem diagnostiziert: DS18B20 war verkehrt gepolt (VDD/GND vertauscht) an GPIO0, führte zu USB-Brownouts und Flashfehlern
  • Nach Sensortausch: Flash erfolgreich, MQTT-Publishing verifiziert (pruefstand/# Topics)
  • Flask Web-Dashboard auf pve-mu-3 gebaut (/opt/pruefstand_web.py)
    • Seite / → ESP8266 Testknecht: Temperaturen, ROM-IDs, CRC, Eingänge, Relais
    • Seite /heizraum → ESP32 Messknoten: 17-20x DS18B20, Pumpen, Brenner, Kessel-Status
    • Auto-Refresh 4s, Online-Indikator für Messknoten (90s-Schwelle)
    • Navigation zwischen den Seiten (prominent)
  • systemd-Service pruefstand-web eingerichtet für persistenten Betrieb
  • Hermes (CT151) um Cron-Job-Toolset erweitert (cronjob in platform_toolsets.telegram)
  • Doku in CT999 erstellt: /root/docs/container/pruefstand-web.md

Änderungen an Infrastruktur

  • pve-mu-3 (Host): /opt/pruefstand_web.py erstellt, systemd-Service pruefstand-web aktiv
  • CT151 (Hermes): /root/.hermes/config.yaml um cronjob Toolset ergänzt
  • Repo orbitalo/pruefstand: ESP8266 Testknecht Firmware committed und verifiziert
  • CT999 (Doku): /root/docs/container/pruefstand-web.md neu erstellt

Erkannte Probleme

  • Waveshare ESP32-S3-Touch-LCD-7 HMI bleibt unfertig: Text-Rendering konnte nicht wiederhergestellt werden. Symptom: Nur Farbwechsel/"Diskolicht" ohne Schrift. Root-Cause unklar (vermutlich LVGL-Build-Inkompatibilität mit OPI PSRAM bei espressif32@6.13.0). Braucht frischen Ansatz in neuer Session.
  • ESP8266 GPIO0 (D3): War durch verkehrt gepolten Sensor beschädigt – nur GPIO0 betroffen, restliche Hardware OK nach Sensortausch

Nächste Schritte

  • Waveshare HMI: Frischer Ansatz, ggf. mit anderem LVGL-Beispiel als Ausgangsbasis statt from scratch
  • Prüfstand physisch aufbauen und testen mit dem Web-Dashboard
  • Bei Messknoten (Heizraum-ESP32): Verifikation aller Eingänge und DS18B20-Sensoren via Dashboard

Betroffene Systeme

  • pve-mu-3 (Host direkt)
  • CT143 (Mosquitto MQTT-Broker)
  • CT151 (Hermes)
  • CT999 (Doku)
  • ESP8266 Testknecht (USB an pve-mu-3)
  • Repo: orbitalo/pruefstand
## Was wurde gemacht - ESP8266 Testknecht geflasht (firmware via esptool.py auf pve-mu-3 /dev/ttyUSB0) - Hardware-Problem diagnostiziert: DS18B20 war verkehrt gepolt (VDD/GND vertauscht) an GPIO0, führte zu USB-Brownouts und Flashfehlern - Nach Sensortausch: Flash erfolgreich, MQTT-Publishing verifiziert (pruefstand/# Topics) - Flask Web-Dashboard auf pve-mu-3 gebaut (`/opt/pruefstand_web.py`) - Seite `/` → ESP8266 Testknecht: Temperaturen, ROM-IDs, CRC, Eingänge, Relais - Seite `/heizraum` → ESP32 Messknoten: 17-20x DS18B20, Pumpen, Brenner, Kessel-Status - Auto-Refresh 4s, Online-Indikator für Messknoten (90s-Schwelle) - Navigation zwischen den Seiten (prominent) - systemd-Service `pruefstand-web` eingerichtet für persistenten Betrieb - Hermes (CT151) um Cron-Job-Toolset erweitert (cronjob in platform_toolsets.telegram) - Doku in CT999 erstellt: `/root/docs/container/pruefstand-web.md` ## Änderungen an Infrastruktur - **pve-mu-3 (Host)**: `/opt/pruefstand_web.py` erstellt, systemd-Service `pruefstand-web` aktiv - **CT151 (Hermes)**: `/root/.hermes/config.yaml` um `cronjob` Toolset ergänzt - **Repo `orbitalo/pruefstand`**: ESP8266 Testknecht Firmware committed und verifiziert - **CT999 (Doku)**: `/root/docs/container/pruefstand-web.md` neu erstellt ## Erkannte Probleme - **Waveshare ESP32-S3-Touch-LCD-7 HMI bleibt unfertig**: Text-Rendering konnte nicht wiederhergestellt werden. Symptom: Nur Farbwechsel/"Diskolicht" ohne Schrift. Root-Cause unklar (vermutlich LVGL-Build-Inkompatibilität mit OPI PSRAM bei espressif32@6.13.0). Braucht frischen Ansatz in neuer Session. - ESP8266 GPIO0 (D3): War durch verkehrt gepolten Sensor beschädigt – nur GPIO0 betroffen, restliche Hardware OK nach Sensortausch ## Nächste Schritte - Waveshare HMI: Frischer Ansatz, ggf. mit anderem LVGL-Beispiel als Ausgangsbasis statt from scratch - Prüfstand physisch aufbauen und testen mit dem Web-Dashboard - Bei Messknoten (Heizraum-ESP32): Verifikation aller Eingänge und DS18B20-Sensoren via Dashboard ## Betroffene Systeme - pve-mu-3 (Host direkt) - CT143 (Mosquitto MQTT-Broker) - CT151 (Hermes) - CT999 (Doku) - ESP8266 Testknecht (USB an pve-mu-3) - Repo: orbitalo/pruefstand
Author
Owner

Nachtrag Session 2026-06-23 (Abend) - Hermes Heizungs-Auswerter + Datenrettungs-Befund

Hermes (CT151) als KI-Heizungsauswerter angebunden

  • REST-API v2 auf pve-mu-3 (/opt/pruefstand_web.py, systemd pruefstand-web, Port 8765) komplett ausgebaut:
    • /api/hilfe (Discovery), /api/status, /api/heizung/now, /api/heizung/history, /api/heizung/brenner?days=N (Takt-Analyse), /api/heizung/kessel?hours=N, /api/pv/now, /api/pv/history?days=N, /api/measurements
    • /api/query?q=<InfluxQL> = generischer read-only Passthrough (nur SELECT/SHOW, DROP/DELETE/INSERT -> 403). Damit kann Hermes beliebige Analysen selbst fahren.
  • Hermes-Config (/root/.hermes/config.yaml auf CT151):
    • platform_toolsets.telegram: perplexity, web, cronjob, hermes-cli (Terminal/curl)
    • browser.allow_private_urls: true + security.allow_private_urls: true
    • command_allowlist: curl auf API/InfluxDB + tirith:raw_ip_url + tirith:plain_http_to_sink
    • channel_prompt verweist auf /api/hilfe
  • Kritisches Learning: command_allowlist mit curl-Regex hilft NICHT gegen Tirith-Block (HTTP+rohe-IP). Loesung = Tirith-Regel-Keys direkt in allowlist. Verifiziert per check_all_command_guards().
  • End-to-End bewiesen: Hermes per Einmal-Prompt (hermes -z) -> ruft curl selbst auf, analysiert. Brenner-Takt-Analyse Winter: 2.226 Starts in 52 Tagen, Rekordtag 15.02. mit 76 Starts, Ø 9 min/Start = massives Kurztakten. Hermes-Diagnose: ueberdimensionierter Brenner, WP wuerde modulierend besser laufen.

Datenrettungs-Befund (WICHTIG)

  • Historische InfluxDB-Daten reichen nur bis 08.01.2026 zurueck (nicht die erwarteten Jahre).
  • Ursache: Alter ioBroker-Raspi seit Dez 2025 offline; KI-Migration verbockt (Daten ins 'Datennirvana').
  • Jahrelange Original-Historie liegt auf der Raspi-SD-Karte (read-only auslesen, NICHT booten) -> Issue #128 (korrigiert #127).
  • Aussenfuehler existiert (Grafana-Panel 'Heizung & Puffer' fragt mqtt.0.Holzvergaser_Sensoren_6.Aussenfuehler.temperature ab), aber Daten NUR auf SD-Karte, Panel seit Migration leer.

Doku/Memory aktualisiert

  • CT999: /root/docs/container/pruefstand-web.md auf API v2 erweitert
  • OpenMemory: API v2, Tirith-Fix, Aussenfuehler-Lage, Datenrettungs-Strategie

Offen / naechste Schritte

  • Issue #128: SD-Karte auslesen, historische Daten als iobroker_historie importieren, 2. Grafana-Datasource
  • Bei Aussenfuehler-Neubau: gleiches Topic + Telegraf-Ingestion pruefen
  • Hermes Telegram-Session: kennt neue Endpoints erst nach /api/hilfe-Refresh oder neuer Session
## Nachtrag Session 2026-06-23 (Abend) - Hermes Heizungs-Auswerter + Datenrettungs-Befund ### Hermes (CT151) als KI-Heizungsauswerter angebunden - **REST-API v2** auf pve-mu-3 (`/opt/pruefstand_web.py`, systemd `pruefstand-web`, Port 8765) komplett ausgebaut: - `/api/hilfe` (Discovery), `/api/status`, `/api/heizung/now`, `/api/heizung/history`, `/api/heizung/brenner?days=N` (Takt-Analyse), `/api/heizung/kessel?hours=N`, `/api/pv/now`, `/api/pv/history?days=N`, `/api/measurements` - **`/api/query?q=<InfluxQL>`** = generischer read-only Passthrough (nur SELECT/SHOW, DROP/DELETE/INSERT -> 403). Damit kann Hermes beliebige Analysen selbst fahren. - **Hermes-Config** (`/root/.hermes/config.yaml` auf CT151): - `platform_toolsets.telegram`: perplexity, web, cronjob, **hermes-cli** (Terminal/curl) - `browser.allow_private_urls: true` + `security.allow_private_urls: true` - `command_allowlist`: curl auf API/InfluxDB + **`tirith:raw_ip_url`** + **`tirith:plain_http_to_sink`** - channel_prompt verweist auf `/api/hilfe` - **Kritisches Learning**: command_allowlist mit curl-Regex hilft NICHT gegen Tirith-Block (HTTP+rohe-IP). Loesung = Tirith-Regel-Keys direkt in allowlist. Verifiziert per `check_all_command_guards()`. - **End-to-End bewiesen**: Hermes per Einmal-Prompt (`hermes -z`) -> ruft curl selbst auf, analysiert. Brenner-Takt-Analyse Winter: 2.226 Starts in 52 Tagen, Rekordtag 15.02. mit 76 Starts, Ø 9 min/Start = massives Kurztakten. Hermes-Diagnose: ueberdimensionierter Brenner, WP wuerde modulierend besser laufen. ### Datenrettungs-Befund (WICHTIG) - Historische InfluxDB-Daten reichen nur bis **08.01.2026** zurueck (nicht die erwarteten Jahre). - **Ursache**: Alter ioBroker-Raspi seit Dez 2025 offline; KI-Migration verbockt (Daten ins 'Datennirvana'). - Jahrelange Original-Historie liegt **auf der Raspi-SD-Karte** (read-only auslesen, NICHT booten) -> **Issue #128** (korrigiert #127). - **Aussenfuehler** existiert (Grafana-Panel 'Heizung & Puffer' fragt `mqtt.0.Holzvergaser_Sensoren_6.Aussenfuehler.temperature` ab), aber Daten NUR auf SD-Karte, Panel seit Migration leer. ### Doku/Memory aktualisiert - CT999: `/root/docs/container/pruefstand-web.md` auf API v2 erweitert - OpenMemory: API v2, Tirith-Fix, Aussenfuehler-Lage, Datenrettungs-Strategie ### Offen / naechste Schritte - **Issue #128**: SD-Karte auslesen, historische Daten als `iobroker_historie` importieren, 2. Grafana-Datasource - Bei Aussenfuehler-Neubau: gleiches Topic + Telegraf-Ingestion pruefen - Hermes Telegram-Session: kennt neue Endpoints erst nach `/api/hilfe`-Refresh oder neuer Session
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: orbitalo/homelab-brain#126
No description provided.