[Session 2026-06-18] ESP32 Heizraum-Knoten: Display live + Sensor-Scan + MQTT->ioBroker #118

New issue

Open

opened 2026-06-18 14:02:17 +00:00 by orbitalo · 1 comment

orbitalo commented

2026-06-18 14:02:17 +00:00

Owner

Folge-Session zu #117 (gestern: Umsetzungsplan + Blink). Heute: vom toten Display bis zur live in ioBroker einlaufenden Temperatur.

Was wurde gemacht

Setup geklaert: ESP32 (ESP32-D0WD-V3) haengt per USB am Windows-11-KI-Server (wutti@100.84.255.83), Flash-Port COM4 (CP210x). Cline flasht dort, Cursor/Pulse = Supervisor (Code + Doku + Verifikation). Anfaengliche Mac-Annahme war falsch.
Versionierung: /root/heizraum-knoten war kein Git-Repo -> neu als privates Forgejo-Repo orbitalo/heizraum-knoten angelegt, sauberer Flash-Workflow (push -> git pull -> pio run/upload COM4 -> monitor).
Display zum Laufen gebracht: ILI9341 2,8". TFT_eSPI-Config per build_flags erzwungen (statt nur include/User_Setup.h). Backlight-/Stromproblem geloest.
Phase 1a (Sensor-Scan-Modus) gebaut & live verifiziert: alle DS18B20 mit ROM-ID, Live-Temp, dT-Identify (Zeile wird gelb beim Anfassen), BOOT-Taste blaettert.
Phase 1d (WLAN + MQTT) gebaut & end-to-end verifiziert: PubSubClient, Topic heizraum/<ID> retain. ESP-IP 192.168.178.191, MQTT zu 192.168.178.36:1883. Auf CT143 unabhaengig geprueft: mqtt.0.heizraum.28BE941600000093 = 26.56, ack:true.
Secrets sauber: src/config.h (WLAN/MQTT) per .gitignore aus dem Repo ausgeschlossen und per scp direkt auf den Windows-Rechner gespielt; config.example.h als Vorlage committet.
Doku: in CT999 zugriff.md (Zugriffs-/Flash-Workflow) und fortschritt.md (Baufortschritt) angelegt.

Aenderungen an Infrastruktur

Neues privates Forgejo-Repo git.orbitalo.net/orbitalo/heizraum-knoten (3 Commits: Initial, build_flags, Scan-Modus, WLAN+MQTT).
ioBroker CT143 (mqtt.0, Broker auf 0.0.0.0:1883, keine Auth) empfaengt jetzt Objekte unter mqtt.0.heizraum.*.
CT999-Doku ergaenzt: /root/docs/projekte/esp32/{zugriff.md, fortschritt.md}.
Windows-KI-Server: Repo geklont nach C:\Users\wutti\heizraum-knoten inkl. src/config.h.

Erkannte Probleme

Toter GND-Pin am ESP-DevKit (kalte Loetstelle) - kostete Zeit bei der Sensorsuche; Sensor-GND musste an einen der 2 funktionierenden GND. Vor Festeinbau nachloeten.
Verkabelung ist Laboraufbau (Dupont verdrillt, WAGO-221 + Dupont gibt schlechten Kontakt ~1,5V) - nicht dauerbetriebstauglich.
Cline kann das Display nicht sehen (nur Serial) - meldete 2x faelschlich 'Display OK'. Display-Verifikation nur per User-Auge/Foto.
Weisses Display nach jedem Flash (haengender Reset) -> einmal EN/Reset druecken.
OneWire-Signalintegritaet bei 17-20 Sensoren ueber lange Strecken noch unbewiesen (Test bisher 1 Sensor).

Naechste Schritte

Phase 1b/1c: alle 17-20 DS18B20 an den Bus, per Identify ROM->Rolle zuordnen -> src/sensor_map.h -> Topics von heizraum/ auf Rollennamen (heizraum/P01_TOP ...), Betriebsanzeige mit Schichtung.
Phase 1e: InfluxDB-Logging auf mqtt.0.heizraum.* aktivieren + Grafana-Panel (auf CT143).
Dauerverkabelung: verdrillte Stellen + toten GND-Pin nachloeten, Backlight sauber.
Spaeter: Touch (XPT2046 vorhanden) optional fuers Blaettern; Phase 2 = 5"-Master (LVGL).

Betroffene Systeme

Windows-KI-Server (wutti@100.84.255.83, ESP/COM4), Pulse (Supervisor/Repo-Quelle), Forgejo git.orbitalo.net, ioBroker CT143 (pve-mu-3, MQTT/192.168.178.36), CT999 (Doku).

Folge-Session zu #117 (gestern: Umsetzungsplan + Blink). Heute: vom toten Display bis zur live in ioBroker einlaufenden Temperatur. ## Was wurde gemacht - **Setup geklaert:** ESP32 (ESP32-D0WD-V3) haengt per USB am **Windows-11-KI-Server** (wutti@100.84.255.83), Flash-Port **COM4** (CP210x). Cline flasht dort, Cursor/Pulse = Supervisor (Code + Doku + Verifikation). Anfaengliche Mac-Annahme war falsch. - **Versionierung:** /root/heizraum-knoten war kein Git-Repo -> neu als privates Forgejo-Repo `orbitalo/heizraum-knoten` angelegt, sauberer Flash-Workflow (push -> git pull -> pio run/upload COM4 -> monitor). - **Display zum Laufen gebracht:** ILI9341 2,8". TFT_eSPI-Config per `build_flags` erzwungen (statt nur include/User_Setup.h). Backlight-/Stromproblem geloest. - **Phase 1a (Sensor-Scan-Modus) gebaut & live verifiziert:** alle DS18B20 mit ROM-ID, Live-Temp, dT-Identify (Zeile wird gelb beim Anfassen), BOOT-Taste blaettert. - **Phase 1d (WLAN + MQTT) gebaut & end-to-end verifiziert:** PubSubClient, Topic `heizraum/<ID>` retain. ESP-IP 192.168.178.191, MQTT zu 192.168.178.36:1883. Auf CT143 unabhaengig geprueft: `mqtt.0.heizraum.28BE941600000093 = 26.56, ack:true`. - **Secrets sauber:** src/config.h (WLAN/MQTT) per .gitignore aus dem Repo ausgeschlossen und per scp direkt auf den Windows-Rechner gespielt; config.example.h als Vorlage committet. - **Doku:** in CT999 `zugriff.md` (Zugriffs-/Flash-Workflow) und `fortschritt.md` (Baufortschritt) angelegt. ## Aenderungen an Infrastruktur - Neues privates Forgejo-Repo `git.orbitalo.net/orbitalo/heizraum-knoten` (3 Commits: Initial, build_flags, Scan-Modus, WLAN+MQTT). - ioBroker CT143 (mqtt.0, Broker auf 0.0.0.0:1883, keine Auth) empfaengt jetzt Objekte unter `mqtt.0.heizraum.*`. - CT999-Doku ergaenzt: /root/docs/projekte/esp32/{zugriff.md, fortschritt.md}. - Windows-KI-Server: Repo geklont nach C:\Users\wutti\heizraum-knoten inkl. src/config.h. ## Erkannte Probleme - **Toter GND-Pin** am ESP-DevKit (kalte Loetstelle) - kostete Zeit bei der Sensorsuche; Sensor-GND musste an einen der 2 funktionierenden GND. Vor Festeinbau nachloeten. - **Verkabelung ist Laboraufbau** (Dupont verdrillt, WAGO-221 + Dupont gibt schlechten Kontakt ~1,5V) - nicht dauerbetriebstauglich. - **Cline kann das Display nicht sehen** (nur Serial) - meldete 2x faelschlich 'Display OK'. Display-Verifikation nur per User-Auge/Foto. - **Weisses Display nach jedem Flash** (haengender Reset) -> einmal EN/Reset druecken. - OneWire-Signalintegritaet bei 17-20 Sensoren ueber lange Strecken noch unbewiesen (Test bisher 1 Sensor). ## Naechste Schritte - **Phase 1b/1c:** alle 17-20 DS18B20 an den Bus, per Identify ROM->Rolle zuordnen -> src/sensor_map.h -> Topics von heizraum/<ROM> auf Rollennamen (heizraum/P01_TOP ...), Betriebsanzeige mit Schichtung. - **Phase 1e:** InfluxDB-Logging auf mqtt.0.heizraum.* aktivieren + Grafana-Panel (auf CT143). - **Dauerverkabelung:** verdrillte Stellen + toten GND-Pin nachloeten, Backlight sauber. - Spaeter: Touch (XPT2046 vorhanden) optional fuers Blaettern; Phase 2 = 5"-Master (LVGL). ## Betroffene Systeme Windows-KI-Server (wutti@100.84.255.83, ESP/COM4), Pulse (Supervisor/Repo-Quelle), Forgejo git.orbitalo.net, ioBroker CT143 (pve-mu-3, MQTT/192.168.178.36), CT999 (Doku).

orbitalo commented

2026-06-18 18:42:46 +00:00

Author

Owner

Nachtrag Abend (18.06.2026)

Verkabelungs-Entscheidung OneWire/DS18B20

12 Sensoren (nicht 17-20), kurze 3-m-Sensorkabel werden eingekuerzt, volle 3 m nur fuer entfernte Fuehler.
Stern-Topologie mit Klemmleisten-Sternpunkt am Pufferspeicher, von dort ein kurzes Kabel zum ESP.
3-Draht (VDD fest 3,3 V, kein Parasite-Mode), Pull-up zentral 2,2 k (statt 4,7 k).
Erst kuerzen + Sternpunkt + 2,2 k, dann alle 12 dran und Fehlerrate im Scan-Modus messen. Serienwiderstaende ~100 Ohm je Zweig bzw. DS2482-100-Master nur als Reserve, nicht auf Verdacht. Begruendung: Stern + ~20x3 m = ~60 m waere OneWire-Worst-Case; mit 12 Sensoren gemischter Laenge gut beherrschbar.

Cline-Haenger diagnostiziert + behoben (separates Thema)

Auftrag an Cline (Windows-KI-Server wutti@100.84.255.83): KI-generierte WordPress-Artikel bewerten -> Cline hing fest.
Ursache: VS-Code Node-Utility-Worker (PID 27272, Code.exe --type=utility ... node.mojom.NodeService) drehte mit ~96 % eines Kerns ueber Stunden durch (CPU-Delta 5,77 s in 6 s gemessen). Ollama war LEER -> kein LLM-Hang, sondern CPU-Endlosschleife in Clines eigener Verarbeitung. Kein haengender pio/esptool, COM4 frei.
Fix: taskkill /F /PID 27272 -> Worker beendet, VS Code/Cline laufen weiter, CPU-Last weg.
Praevention: Bewertung in kleinen Batches (3-5 Artikel), nur reiner Text statt komplettem WP-HTML, WP-REST-API mit ?_fields=title,content.

Beides in OpenMemory festgehalten. Naechste Schritte fuer den ESP32-Knoten unveraendert (Sensor-Zuordnung -> sensor_map.h, dann InfluxDB/Grafana).

## Nachtrag Abend (18.06.2026) ### Verkabelungs-Entscheidung OneWire/DS18B20 - **12 Sensoren** (nicht 17-20), kurze 3-m-Sensorkabel werden eingekuerzt, volle 3 m nur fuer entfernte Fuehler. - **Stern-Topologie** mit Klemmleisten-Sternpunkt am Pufferspeicher, von dort ein kurzes Kabel zum ESP. - **3-Draht** (VDD fest 3,3 V, kein Parasite-Mode), **Pull-up zentral 2,2 k** (statt 4,7 k). - Erst kuerzen + Sternpunkt + 2,2 k, dann alle 12 dran und Fehlerrate im Scan-Modus messen. Serienwiderstaende ~100 Ohm je Zweig bzw. DS2482-100-Master nur als Reserve, nicht auf Verdacht. Begruendung: Stern + ~20x3 m = ~60 m waere OneWire-Worst-Case; mit 12 Sensoren gemischter Laenge gut beherrschbar. ### Cline-Haenger diagnostiziert + behoben (separates Thema) - Auftrag an Cline (Windows-KI-Server wutti@100.84.255.83): KI-generierte WordPress-Artikel bewerten -> Cline hing fest. - **Ursache:** VS-Code Node-Utility-Worker (PID 27272, `Code.exe --type=utility ... node.mojom.NodeService`) drehte mit ~96 % eines Kerns ueber Stunden durch (CPU-Delta 5,77 s in 6 s gemessen). Ollama war LEER -> kein LLM-Hang, sondern CPU-Endlosschleife in Clines eigener Verarbeitung. Kein haengender pio/esptool, COM4 frei. - **Fix:** `taskkill /F /PID 27272` -> Worker beendet, VS Code/Cline laufen weiter, CPU-Last weg. - **Praevention:** Bewertung in kleinen Batches (3-5 Artikel), nur reiner Text statt komplettem WP-HTML, WP-REST-API mit `?_fields=title,content`. Beides in OpenMemory festgehalten. Naechste Schritte fuer den ESP32-Knoten unveraendert (Sensor-Zuordnung -> sensor_map.h, dann InfluxDB/Grafana).