root 1047bd0aca fix: config.py Parser für neues CT_VMID_SERVER Format angepasst

- CT/VM Pattern: CT_101_HZ, CT_600_KA3, VM_144_MU3
- HOST_CODE_MAP: HZ, KA1-3, MU1-3, HE
- PROXMOX_HOSTS wird aus SRV_* Einträgen befüllt
- get_container() mit optionalem host-Filter
- get_containers_by_host() Hilfsfunktion
- proxmox_client.py: PROXMOX_HOSTS leer, wird dynamisch befüllt

Made-with: Cursor

2026-03-09 09:33:01 +07:00

16 KiB

Raw Blame History

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):

ESP32 startet, verbindet sich per WiFi zu ioBroker (Proxmox CT 999)
Fragt per REST-API oder MQTT ab: "Gib mir die aktuellen Daten"

ioBroker antwortet (innerhalb 100ms): JSON mit allen Sensoren

{
  "puffer_oben": 52.3,
  "puffer_mitte": 45.1,
  "puffer_unten": 32.0,
  "aussenemp": -3.2,
  "hv_abgas": 45.0,
  "sonne_heute_h": 5
}

ESP32 verarbeitet die Logik:
- "Sonne > 3h → Öl sperren"
- "Außen > -5°C → WP erlaubt"
- etc.
ESP32 zeichnet auf dem 5-Zoll Display:
- Farbige Balken, Icons, Text, Prognose
Display aktualisiert sich alle ~2 Sekunden
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?