# 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?