homelab-brain/esp32/STORY-TEIL-2-PLAN.md

# ESP32 Heizungs-Monitoring — STORY TEIL 2 — Planung
> Schreib-Session: 2026-03-05

---

## 📖 Artikel-Struktur (Überblick)

### **TEIL 1** (Dein Intro) ✅
Wie alles begann — von drei Temperaturanzeigen zum Heizungsmonitoring
- Hauskauf 2005 → Heizungsanlage
- Drei Temperaturanzeigen
- DS18B20 Sensoren
- IP-Symcon Automatisierung
- Raspberry Pi + InfluxDB + Grafana
- ESP8266 Sensorknoten
- Proxmox + ioBroker heute
- Erkenntnis: Daten verstehen = optimieren
- ESP32 = nächster Schritt

---

## 🎯 TEIL 2 (HEUTE) — Geplante Kapitel

### **Kapitel 2.1: Der ESP32 — warum jetzt?**

**Kern:** Persönlich: Warum ich die alte Lösung aufgeben will. Technisch: Was der ESP32 ermöglicht.

**Story-Anfang:**
- Seit ~10 Jahren hängt ein ESP8266 in meiner Küche
- Zeigt mir 3-4 Werte auf einem winzigen Display
- Funktioniert zuverlässig, ich bin zufrieden damit
- **Aber:** Jeden Morgen muss ich warten, bis das Display aktualisiert — manchmal ~3 Sekunden Verzögerung
- Und wenn ich die Sensoren von 3 auf 5 erhöhe → lahmer
- Das nervt nicht wirklich, aber... es nervt

**Persönlicher Wendepunkt:**
- Im Januar 2026 überlege ich: Warum nicht einfach neu?
- Die alte Lösung war damals clever (2014: "ESP8266 mit WLAN!")
- Aber heute? Raspberry Pi ist günstiger. Arduino-Klone auch
- Der ESP32 ist die Brücke: "Altes Konzept, neue Hardware"
- Und: Ein 5-Zoll Display für ~30 EUR (!) — das gab es vor 10 Jahren nicht

**Technisch: Warum ESP32 konkret besser für mein System ist:**
- **Das Problem mit ESP8266:**
  - 160 MHz (Einkern) → wenn ich 6+ Sensoren gleichzeitig abfrage, wird es eng
  - 160 KB RAM → nicht viel für Pufferdaten
  - WiFi nur 802.11b/g → langsam bei Netzwerk-Last
  - Kleines Display möglich (max ~2,4 Zoll ohne zu hängen)
  
- **ESP32: Was sich ändert (für mich, nicht theoretisch):**
  - 240 MHz dual-core → 2 CPUs nebeneinander
    - Eine CPU: Sensoren auslesen + Berechnung
    - Andere CPU: WiFi & Display aktualisieren
    - = Keine Verzögerung mehr
  - 520 KB RAM → kann jetzt 24h Temperaturverlauf speichern
  - WiFi 802.11n → schneller, stabiler, auch mit mehreren Geräten
  
- **Was das konkret ermöglicht:**
  - Echtzeit-Anzeige (keine 3-Sekunden-Verzögerung mehr)
  - Historien-Daten (Grafiken, wie hat sich Puffer in letzten 24h verändert)
  - 5-Zoll-Display statt 2,4-Zoll (überhaupt lesbar ohne Brille!)
  - Farben + Symbole (nicht nur Zahlen)
  - Prognose-Daten + aktuelle Daten kombinieren
  
- **Die Hardware (praktisch):**
  - ESP32-8048S050 Board: alles integriert (Display + WiFi + Touch + GPIO)
  - Preis: 28-35 EUR auf AliExpress (vs. früher: einzelnes Display 80+ EUR + ESP Board + Kabel = 150+ EUR)
  - Direkt ab Werk: Arduino-kompatibel, kann sofort programmieren
  
- **Persönliche Erwartung:**
  - Schnelleres Display = mehr Nutzen
  - Größer = sehe es auch aus der Ferne
  - Einfach weil es da ist und günstig
  - Und weil ich lernen will: "Was kann moderner Hardware noch?"

**Länge:** 600-900 Worte

---

### **Kapitel 2.2: Die Hardware — was ich verwende**

**Kern:** Was habe ich gekauft? Wie passt es zusammen? Wieso gerade diese Teile?

**Story-Start:**
- Im Februar bestelle ich das Board auf AliExpress
- Ich bin nervös — wird es ankommen? Ist es funktionsfähig?
- Erfahrung: 80% der billigen Elektronik funktioniert, 20% ist Schrott
- Diesmal: Glückstreffer. Board kam an, alles lädt direkt

**Die Hardware im Detail:**

**1. Das ESP32-8048S050 Board (der Hauptdarsteller):**
- Was ist das? Ein "All-in-One" Mikrocontroller-Display-Combo
- Technisch:
  - Xtensa 32-Bit CPU (240 MHz, dual-core)
  - 520 KB RAM (vs. 160 KB beim ESP8266 — großer Unterschied!)
  - 4 MB Flash (zum Speichern von Code + Daten)
  - WiFi 802.11b/g/n 2,4 GHz
  - Bluetooth (optional, ich nutze es nicht)
  
- Das integrierte Display:
  - 5 Zoll (127 mm) diagonal
  - Auflösung: 800×480 Pixel (IPS, gute Farben)
  - Touchscreen (ich nutze ihn selten — Tasten reichen mir)
  - SD-Kartenslot (für Daten-Logging, falls nötig)
  
- Anschlüsse (wichtig für mich):
  - USB-C für Programmierung + Stromversorgung
  - GPIO-Pins (für zusätzliche Sensoren, Relais, etc.)
  - 3,3V & 5V Power Rail
  
- Preis: 28-35 EUR auf AliExpress (bestellt, gewartet, bezahlt)

**2. Die DS18B20 Sensoren (die Datensammler):**
- Was ist das? Digitale Temperatur-Sensoren
- Technisch:
  - ±0,5°C Genauigkeit (das ist gut genug für Heizung)
  - 1-Wire Bus (!) — jeder Sensor braucht nur 1 Kabel + Masse
    - Bedeutet: Alle Sensoren an einem GPIO-Pin angeschlossen
    - Maximal 127 Sensoren am gleichen Pin (theoretisch)
  - Messbereich: -55°C bis +125°C (für Heizung egal, aber nice)
  
- Kauft man mit:
  - Längere Varianten: einfaches Drahtsensor-Design
  - Wasserdichte Varianten: IN Edelstahl-Gehäuse (JDS18B20)
  - Ich nutze die wasserdichten, weil Heizungsanlage = nass

- Meine Sensoren (wo hängen sie?):**
  - **Puffer oben** (warmste Stelle): GPS-Koordinate in Tank
  - **Puffer mitte** (sagt mir, ob Puffer stratifiziert ist): Mit M24 Gewinde zum Schrauben
  - **Puffer unten** (Vorlauf zurück): Am Boden des Tanks
  - **Solar-Kollektor Vorlauf** (warmes Wasser von Dach): 1 Meter Kabel durch Decke
  - **Solar-Kollektor Rücklauf** (kaltes Wasser zurück): Direkt daneben
  - **Außentemperatur** (an der Nordseite des Hauses): Schattiert
  - **Reserve** (2x): Falls ich später was hinzufügen will
  
- **Verkabelung (praktisch):**
  - Alle 8 Sensoren → 1-Wire Bus am GPIO Pin (z.B. GPIO4 on ESP32)
  - Masse (GND): zu ESP32
  - Stromversorgung: 3,3V (intern am Sensor = parasitäre Stromversorgung)
  - Pullup-Widerstand: 4,7 kΩ zwischen Daten + 3,3V (wichtig!)
  - Resultat: Ein 3-adriges Kabel durchs ganze Haus
    - Rot: 3,3V
    - Schwarz: GND
    - Gelb: Daten (1-Wire Bus)

**3. Das Netzteil (die Energiequelle):**
- USB-C 5V / 2A Netzteil aus dem Elektronik-Geschäft
- Stromverbrauch ESP32 + Display: ~2-3W dauerhaft
- Display ist der Strombombe (nicht der CPU)
- Läuft 24/7 an der Steckdose in der Küche

**4. Entwicklungs-Werkzeuge (Software):**
- Arduino IDE (kostenlos, jeder kennt es)
- PlatformIO (auch kostenlos, besser für größere Projekte)
- Ich wähle PlatformIO: übersichtlicher, bessere Dependency-Verwaltung

**Wie alles zusammen funktioniert (Datenfluss):**
1. ESP32 startet, verbindet sich per WiFi zu ioBroker (Proxmox CT 999)
2. Fragt per REST-API oder MQTT ab: "Gib mir die aktuellen Daten"
3. ioBroker antwortet (innerhalb 100ms): JSON mit allen Sensoren
   ```json
   {
     "puffer_oben": 52.3,
     "puffer_mitte": 45.1,
     "puffer_unten": 32.0,
     "aussenemp": -3.2,
     "hv_abgas": 45.0,
     "sonne_heute_h": 5
   }
   ```
4. ESP32 verarbeitet die Logik:
   - "Sonne > 3h → Öl sperren"
   - "Außen > -5°C → WP erlaubt"
   - etc.
5. ESP32 zeichnet auf dem 5-Zoll Display:
   - Farbige Balken, Icons, Text, Prognose
6. Display aktualisiert sich alle ~2 Sekunden
7. Benutzer (ich) schaut drauf und sieht sofort: "Ok, Solar lädt gerade"

**Persönliches Fazit zu dieser Hardware:**
- Für ~40 EUR Gesamtkosten eine sehr solide Lösung
- Nicht "professionell" im Sinne von Industrie
- Aber: Robust genug für Heimautomation, einfach genug zum Verstehen
- Und: Falls das Board kaputt geht, kostet der Austausch 30 EUR, nicht 300 EUR

**Länge:** 900-1200 Worte

---

### **Kapitel 2.3: Die Logik — die 5 Regeln der Heizung**

**Kern:** Persönlich: Wie bin ich auf diese 5 Regeln gekommen? Technisch: Was sie bedeuten.

**Story-Start:**
- Im Jahr 2020, als ich ioBroker einführe, habe ich angefangen zu experimentieren
- Anfangs: Komplexe Logik mit vielen Bedingungen, Prognosen, Optimierungen
- Ergebnis: Das System machte seltsame Sachen. Manchmal startete Öl unerwartet. Manchmal HV + Öl gleichzeitig.
- Problem: Zu viele Regeln, zu viele Sonderfälle
- Lernmoment: "Je simpler die Logik, desto zuverlässiger das System"

**Wie ich zu den 5 Regeln kam:**
- Ich saß hin und fragte mich: "Wenn ich kein automatisches System hätte — wie würde ICH entscheiden?"
- Antwort war einfach: "Nach 5 Kriterien"
- Resultat: Die 5 Regeln entstanden nicht aus Theorie, sondern aus praktischer Erfahrung

**Die 5 Regeln (mit persönlichem Kontext):**

```
REGEL 1: HV läuft?        → Alles andere AUS
REGEL 2: Sonne erwartet?  → Morgens Öl SPERREN
REGEL 3: Außen > -5°C?    → WP erlaubt
REGEL 4: Außen < -5°C?    → Öl statt WP
REGEL 5: Puffer < 35°C?   → NOTSTART (egal was)
```

**REGEL 1: HV läuft? → Alles andere AUS**
- Was ist HV? Holzvergaser (Holzheizung)
- Warum die Priorität?
  - HV ist der Liebling: Billigster Brennstoff (sammle Holz selbst)
  - Gibt die meiste Leistung: ~40 kW wenn richtig aufgeheizt
  - Läuft lange: ~6-8 Stunden pro Laden
- Praktisch: Wenn HV läuft, ist der Puffer in 1-2 Stunden voll → Öl + WP brauchen nicht laufen
- Technisch: `if (hv_abgas > 120°C) then { wp.off, oel.off }`
- Persönlich: "Lass den HV in Ruhe, er macht seinen Job"

**REGEL 2: Sonne erwartet? → Morgens Öl SPERREN**
- Kontext: Solar-Thermie-Anlage auf dem Dach
  - Kann im Sommer bis 70% der Heizlast abdecken
  - Im Winter: 15-25% (wenn nicht bewölkt)
- Die Idee: Wenn Wetterdienst sagt "Morgen 5 Stunden Sonne"
  - Dann: Öl nicht starten (auch wenn Puffer 40°C ist)
  - Grund: In 2-3 Stunden kommt die Sonne → kostenlos laden
  - Ersparniss: ~2€ pro Tag wenn man das richtig macht
- Praktisch: Um 06:00 Uhr morgens liest ioBroker die OpenWeatherMap-API
  - Wenn sunshine_hours_today > 3 → `oel.gesperrt = true`
  - Wenn sunshine_hours_today < 1 → `oel.gesperrt = false`
- Persönlich: "Der beste Brennstoff ist kostenlos"

**REGEL 3+4: Außentemperatur & Wärmepumpe**
- Warum -5°C als Grenze?
  - Moderne WP (Luft-Wasser): Haben einen COP (Coefficient of Performance)
  - COP = Wärmeleistung / Stromverbrauch
  - Bei +10°C: COP ~4 (für 1 kWh Strom → 4 kWh Wärme)
  - Bei 0°C: COP ~2,5 (sinkt)
  - Bei -5°C: COP ~1,8 (wird unwirtschaftlich)
  - Bei -10°C: COP ~1,5 (teurer als Öl)
- Praktisch:
  - REGEL 3: `if (aussen_temp > -5) then wp.erlaubt = true` (kann laufen)
  - REGEL 4: `if (aussen_temp < -5) then wp.erlaubt = false` (sperren, lieber Öl)
- Persönlich: "Bei extremer Kälte ist die WP teuer — dann lieber Öl"
- Zusatz: WP regelt sich selbst (Modulation, Taktschutz) → System braucht nur "ja/nein" geben

**REGEL 5: Puffer < 35°C? → NOTSTART**
- Hintergrund: Pufferspeicher ist ein großer Behälter (1.500 Liter)
  - Oben: heiß (65-70°C wenn voll)
  - Unten: kalt (30-40°C für Frostschutz)
  - Wenn unten unter 35°C: Gefahr von Frostschäden (in kalten Gegenden)
- Praktisch: egal ob HV läuft, ob Sonne kommt
  - `if (puffer_unten < 35) then { oel.erlaubt = true, wp.erlaubt = true }`
  - Sicherheit vor Optimierung!
- Persönlich: "Eine kaputte Heizung ist teurer als die Energieeinsparung"

**Was das System BEWUSST NICHT TUT (und warum das richtig ist):**

```
❌ COP-Berechnung in Echtzeit
  → Warum nicht? Zu komplex, zu viele Unsicherheiten
  → Stattdessen: Feste Grenzen (-5°C) sind zuverlässiger
  
❌ Speicher-SOC Auswertung
  → Zu kompliziert, braucht man nicht für diese Anlage
  
❌ Stundenlohn für HV-Betrieb
  → "Holz kostet: Schneiden + Spalten + Lagern = ?€ pro kWh"
  → Ist sehr subjektiv, nicht wert die Logik kompliziert zu machen
  
❌ Vorhersage-Planung
  → "Wenn morgen sehr kalt wird, jetzt schon volladen"
  → Zu spekulativ. Puffer war ja gerade voll.
  
❌ PV-Überschuss-Erkennung
  → Haben wir keine PV, also egal
```

- Grund für diese Einfachheit:
  - Heizsysteme müssen zuverlässig sein
  - Einfache Logik = weniger Bugs
  - Weniger Bugs = 20 Jahre Betrieb ohne Probleme
  - Komplexe Logik spart vielleicht 50€/Jahr, kostet aber Kopfzerbrechen

**Prioritäten-Reihenfolge (wer gehört wann auf?):**

```
1. ☀️ Solar-Thermie    (gratis, kostet nur Installation)
2. 🪵 Holzvergaser     (billigst, ~10€/Stunde inklusive Arbeit)
3. 🌡️ Wärmepumpe       (mittel, ~20€/Stunde je nach COP)
4. 🛢️ Ölkessel         (teuerst, ~40€/Stunde)
```

- Persönlich: "Ich zahle am liebsten mit Muskelkraft (HV) oder nichts (Solar)"

**Technische Umsetzung (ioBroker Javascript):**
- Um 06:00 Uhr läuft ein Script
- Liest 5 Werte: HV-Abgas, Außentemp, Puffer-unten, Sonne-Prognose, aktuelle Uhrzeit
- Berechnet die 5 Regeln hintereinander
- Setzt dann: `heizung.wp.erlaubt`, `heizung.oel.erlaubt`, `heizung.status`
- Die einzelnen Kessel folgen diesen Flags (hardwareseitig: Relais, Ventile)

**Länge:** 1000-1300 Worte

---

### **Kapitel 2.4: Das Display — Was der Benutzer sieht**

**Kern:** 4 Szenarien, wie das Dashboard aussieht.

**Punkte:**
- **Szenario 1: Morgens, Sonne erwartet**
  - Top: "☀️ PROGNOSE HEUTE — 5 Stunden Sonne erwartet"
  - Puffer: 52°C, 67% voll (grün)
  - Status: 
    - ☀️ Solar: ⏸️ wartet auf Sonne
    - 🪵 Holz: ⏸️ aus
    - 🌡️ WP: ▶️ läuft
    - 🛢️ Öl: 🚫 gesperrt (Solar erwartet)
  - Fußzeile: "💰 Heute gespart: ~4.20€"

- **Szenario 2: Solar aktiv**
  - Top: "☀️ SOLAR AKTIV — Kollektor 68°C"
  - Leistung: ~4.2 kW
  - Heute: 8.4 kWh = 1.18€ gespart
  - Puffer: 62°C, 82% (dunkelgrün/rot-ish)
  - Status: Alles aus, nur Solar lädt

- **Szenario 3: Bewölkt, kalt**
  - Top: "☁️ PROGNOSE HEUTE — keine Sonne"
  - Puffer: 42°C (orange/gelb)
  - Status:
    - 🛢️ Öl: ▶️ LÄUFT
    - 🌡️ WP: 🚫 aus (zu kalt: -8°C)
  - Kosten: "Heute: Öl 2.1L = 2.52€"

- **Szenario 4: Holzvergaser aktiv**
  - Top: "🪵🔥 HOLZVERGASER AKTIV"
  - Abgas: 178°C
  - Läuft seit: 2:15h
  - Geliefert: ~35 kWh
  - Puffer: 68°C, 92% (rot = warnung, ok aber fast voll)
  - Alles andere: 🚫 gesperrt

- **Navigation:**
  - Swipe links/rechts für mehr Infos
  - Graph: Temperaturverlauf (letzte 24h)
  - Finanz-Seite: Monatliche Ersparnis

**Länge:** 500-700 Worte

---

### **Kapitel 2.5: Von der Idee zur Realität — Der Entwicklungsprozess**

**Kern:** Wie ist das entstanden? Welche Fehler gab es?

**Punkte:**
- **Die erste Skizze (was brauchst du wirklich?):**
  - Notizblock, Kugelschreiber
  - "Was will ich jeden Tag sehen?"
  - Antwort: Puffer-Temperatur, Status aller 4 Heizer, Prognose, Kosten
  
- **Die erste Version:**
  - Einfach nur Text auf dem Display
  - Zahlen, keine Farben
  - Probleme:
    - Schwer zu erfassen auf einen Blick
    - Zu viel Text
    - Nicht intuitiv
  
- **Iteration 2: Farben & Icons**
  - Rot/Gelb/Grün (universale Sprache)
  - Emoji für Systeme (☀️ Solar, 🪵 Holz, etc.)
  - Progress-Bar für Puffer
  - Deutlich besser lesbar
  
- **Iteration 3: Prognose einbauen**
  - Vorher: nur aktuelle Zustände
  - Nachher: "Öl gesperrt wegen Sonne morgen" (Aktion, nicht nur Zustand)
  - Macht große Unterschied bei Verständnis
  
- **Die Fehler unterwegs:**
  - ❌ Zu viele Seiten → Benutzer verliert sich
  - ❌ Zu viele Zahlen → Verwirrend, nicht aussagekräftig
  - ❌ Wetter-API ausfallen → System hängt
  - Lösung: Fallback auf "konservativ" (Öl freigeben)
  
- **Was gelernt:**
  - UI braucht Zeit
  - Testen mit echten Daten (nicht Mock-Daten)
  - Jeden Tag anschauen = schnelle Iteration

**Länge:** 400-600 Worte

---

## 📊 Geschätzte Gesamt-Länge TEIL 2

- 2.1: 700 Worte
- 2.2: 500 Worte  
- 2.3: 700 Worte
- 2.4: 600 Worte
- 2.5: 500 Worte
- **Summe: ~3.000 Worte**

---

## 🎬 Schreib-Strategie für heute

1. **Kapitel 2.1 & 2.2** — Hardware & Geschichte (45 Min)
2. **Kapitel 2.3** — Die 5 Regeln (30 Min)
3. **Kapitel 2.4** — Dashboard-Szenarien (45 Min)
4. **Kapitel 2.5** — Lessons Learned (30 Min)
5. **Review & Finalize** (30 Min)

**Total: ~3 Stunden**

---

## ✅ Nächste Schritte

- [ ] Mit 2.1 starten (Hardware-Geschichte)
- [ ] Screenshots von Dashboard-Layouts vorbereiten?
- [ ] Code-Snippets sammeln?
- [ ] Finale Versione in WordPress einspielen?