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
This commit is contained in:
root 2026-03-09 09:33:01 +07:00
parent 6f5eddb153
commit 1047bd0aca
5 changed files with 1502 additions and 38 deletions

110
esp32/ARTIKEL-KONTEXT.md Normal file
View file

@ -0,0 +1,110 @@
# ESP32 Heizungs-Monitoring — Artikel-Kontext
> Für Arakava-News Blog-Publikation
## Artikel-Titel (Arbeitstitel)
**Wie alles begann von drei Temperaturanzeigen zum Heizungsmonitoring**
---
## Intro-Text (Deine Geschichte)
Wie alles begann von drei Temperaturanzeigen zum Heizungsmonitoring
Die Idee, meine Heizung zu überwachen, ist nicht neu. Sie begleitet mich eigentlich seit dem Hauskauf im Jahr 2005. Damals habe ich die Heizungsanlage bereits nach meinen Vorstellungen aufgebaut: mehrere Wärmeerzeuger, ein großer Pufferspeicher, Solarthermie, Holzvergaser und Öl.
Das Problem war allerdings schnell klar:
Die Anlage konnte viel aber ich konnte kaum sehen, was tatsächlich passiert.
Die erste Lösung war sehr einfach. Drei digitale Temperaturanzeigen, in ein kleines Kunststoffgehäuse eingebaut, mit Heißkleber fixiert. Vorlauf, Rücklauf, Puffertemperatur. Mehr brauchte es am Anfang nicht. Hauptsache, ich konnte sehen, was die Anlage gerade macht.
Mit der Zeit wurde das System interessanter. Digitale Temperatursensoren vom Typ DS18B20 machten es möglich, mehrere Messpunkte über einen sogenannten 1-Wire-Bus auszulesen. Damit konnte ich erstmals Temperaturen systematisch erfassen.
Die Daten liefen damals über die Automatisierungssoftware IP-Symcon auf einen Rechner. Das war mein erster Schritt in Richtung Heimautomation. Noch nichts Spektakuläres aber plötzlich konnte ich mehr sehen als nur drei Zahlen auf einem Display.
Der nächste große Schritt kam mit der Visualisierung der Daten. Ein Raspberry Pi übernahm das Sammeln der Messwerte. Die Daten wurden in InfluxDB gespeichert und mit Grafana sichtbar gemacht.
Zum ersten Mal konnte ich den Verlauf meiner Heizung über Stunden und Tage beobachten.
In dieser Phase entstanden auch kleine Sensorknoten auf Basis des ESP8266. Diese Geräte konnten Temperaturen direkt auslesen und über WLAN ins Netzwerk schicken. Einer dieser Knoten hängt bis heute in meiner Küche und zeigt die wichtigsten Heizungsdaten auf einem kleinen Display an.
Mit der Zeit wuchs die Infrastruktur weiter. Der Raspberry Pi wurde schließlich durch eine Serverinstallation ersetzt. Heute läuft das System zentral auf meinem Proxmox VE-Server. Darauf läuft wieder ioBroker, allerdings in einer deutlich moderneren Version.
Die eigentliche Erkenntnis kam jedoch erst mit den Daten selbst.
Als die Temperaturen, Brennerstarts und Laufzeiten sichtbar wurden, konnte ich das Heizsystem erstmals wirklich verstehen und optimieren.
Der aktuelle Schritt geht noch weiter. Moderne Mikrocontroller wie der ESP32 ermöglichen neue Anzeigen, bessere Auswertungen und deutlich mehr Möglichkeiten als noch vor einigen Jahren.
Die Reise ist also noch nicht zu Ende.
---
## Artikel-Struktur (Geplant)
### 1. Intro (Deine Geschichte oben)
### 2. Der ESP32 — warum jetzt?
- Leistung vs. Preis
- Eingebaute Displays möglich
- WLAN-Konnektivität
- Energieeffizienz
### 3. Hardware-Setup
- ESP32-8048S050 (5" Display) für Heizungs-Dashboard
- DS18B20 Sensoren (8 Stück)
- Pin-Belegung
- Verkabelung
### 4. Software-Architektur
- Datenquellen: ioBroker (Proxmox CT)
- API-Integration
- Display-Updates
- Fehlerbehandlung
### 5. Das Live-Dashboard
- Pufferspeicher-Temperatur
- Solarthermie-Status
- Holzvergaser-Leistung
- Wärmepumpe-Daten
- Ölheizung-Status
- Prognose/Automatik
### 6. Erkenntnisse aus den Daten
- Was die Metriken lehren
- Optimierungsmöglichkeiten
- Vergleiche (alt vs. neu)
### 7. Nächste Schritte & Community
- Weitere ESP32-Projekte
- Open-Source Teilen?
- Fragen/Feedback
---
## Publikations-Infos
| Feld | Wert |
|------|------|
| **Ziel-Blog** | Arakava News (arakava-news-2.orbitalo.net) |
| **WordPress CT** | 101 (100.91.212.19) |
| **Admin** | admin / eJIyhW0p5PFacjvvKGufKeXS |
| **Kategorie** | Smart Home / Heimautomation |
| **Tags** | esp32, heizung, iot, datenvisualisierung, ioBroker |
| **Status** | Draft (in Arbeit) |
---
## Zusätzliche Ressourcen
- **PLAN.md** → Hardware-Details & Pin-Belegung
- **CT 999 (pve1)**`/root/ESP32-Heizung-Projekt.md` (detaillierter Plan)
- **ioBroker** → Datenquellen auf Proxmox
- **Smart Home STATE.md** → Aktuelle Infrastruktur
---
## Notizen für dich
- [ ] Code-Beispiele sammeln (Arduino/PlatformIO)
- [ ] Screenshots vom aktuellen Display machen
- [ ] Grafana-Dashboards dokumentieren
- [ ] Lessons Learned aufschreiben
- [ ] Schreib-Status aktualisieren

921
esp32/ARTIKEL-TEIL-2.md Normal file
View file

@ -0,0 +1,921 @@
# ESP32 Heizungs-Monitoring — Der nächste Schritt
> Artikel Teil 2 — Live-Schreib-Session 2026-03-05
---
## Kapitel 2.1: Der ESP32 — warum jetzt?
Die Idee, meine Heizung zu überwachen, ist nicht neu. Sie begleitet mich eigentlich seit dem Hauskauf im Jahr 2005. Damals habe ich die Heizungsanlage bereits nach meinen Vorstellungen aufgebaut: mehrere Wärmeerzeuger, ein großer Pufferspeicher, Solarthermie, Holzvergaser und Öl.
Und ich habe sofort angefangen, das Ganze zu überwachen.
**Die erste Lösung war sehr einfach.** Drei digitale Temperaturanzeigen, in ein kleines Kunststoffgehäuse eingebaut, mit Heißkleber fixiert. Vorlauf, Rücklauf, Puffertemperatur. Mehr brauchte es am Anfang nicht. Hauptsache, ich konnte sehen, was die Anlage gerade macht.
Mit der Zeit wurde das System interessanter. Digitale Temperatursensoren vom Typ DS18B20 machten es möglich, mehrere Messpunkte über einen sogenannten 1-Wire-Bus auszulesen. Damit konnte ich erstmals Temperaturen systematisch erfassen.
Die Daten liefen damals über die Automatisierungssoftware IP-Symcon auf einen Rechner. Das war mein erster Schritt in Richtung Heimautomation. Noch nichts Spektakuläres aber plötzlich konnte ich mehr sehen als nur drei Zahlen auf einem Display.
Der nächste große Schritt kam mit der Visualisierung der Daten. Ein Raspberry Pi übernahm das Sammeln der Messwerte. Die Daten wurden in InfluxDB gespeichert und mit Grafana sichtbar gemacht.
Zum ersten Mal konnte ich den Verlauf meiner Heizung über Stunden und Tage beobachten.
In dieser Phase entstanden auch kleine Sensorknoten auf Basis des ESP8266. Diese Geräte konnten Temperaturen direkt auslesen und über WLAN ins Netzwerk schicken. Einer dieser Knoten hängt bis heute in meiner Küche und zeigt die wichtigsten Heizungsdaten auf einem kleinen Display an.
Mit der Zeit wuchs die Infrastruktur weiter. Der Raspberry Pi wurde schließlich durch eine Serverinstallation ersetzt. Heute läuft das System zentral auf meinem Proxmox VE-Server. Darauf läuft ioBroker, allerdings in einer deutlich moderneren Version.
**Und dann, im Herbst 2025, ist das Siemens Logo kaputt gegangen.**
Nach 20 Jahren zuverlässiger Arbeit. Zwei Jahrzehnte. Das Ding hatte alles erlebt: Hitze, Feuchte, Stromschwankungen, hundertfache Schaltzyklen. Und dann: Eines Tages war es einfach weg. Elektronik tot. Nicht reparierbar. Einfach... vorbei.
Das war der Moment, wo ich dachte: "Gut. Zeit für was Neues."
Nicht aus Langeweile. Nicht aus Lust auf einen Upgrade. Sondern weil die alte Hardware gestorben ist und ich **jetzt** eine Lösung brauchte.
**Und jetzt, im Januar 2026, überlege ich: Was kommt danach?**
---
### Warum der ESP32 jetzt der richtige nächste Schritt ist
Das Siemens Logo ist weg. Nach 20 Jahren war es einfach Schluss — elektronisch kaputt, nicht reparierbar. Das ist einerseits ein Trauer-Moment (so ein zuverlässiges Gerät!), andererseits eine **Chance**: Jetzt kann ich neu denken.
Seit etwa zehn Jahren hängt der ESP8266 in meiner Küche. Er funktioniert zuverlässig, ich bin zufrieden damit. **Aber:** Jeden Morgen muss ich warten, bis das Display aktualisiert — manchmal etwa drei Sekunden Verzögerung. Und wenn ich die Sensoren von drei auf fünf erhöhe, wird es merklich langsamer. Das nervt nicht wirklich, aber... es nervt.
Jetzt, mit dem kaputten Logo, stelle ich mir die Frage: Sollte ich noch eine alte Lösung wie das Logo kaufen? Reparieren? Nein. Das macht keinen Sinn. Klar, eine neue Siemens Logo gibt es noch zu kaufen. Aber warum? Warum nochmal die gleiche alte Technik, wenn es heute für weniger Geld etwas gibt, das zehnmal mehr kann?
Also: **Vorwärts, nicht rückwärts.**
Die alte Lösung war damals clever. 2014, als der ESP8266 gerade rauskam: „WiFi-fähig, billig, stromsparig — das ist revolutionär!" Und das war es auch. Aber heute? Ein Raspberry Pi ist mittlerweile teuer geworden — 80 EUR und mehr für ein Board. Aber ein ESP32 mit Display? 30 EUR. Der Markt hat sich bewegt.
Der **ESP32 ist die Brücke:** Das gleiche Konzept, aber mit moderner Hardware. Und das ist wichtig: Heute bekommst du ein 5-Zoll Display mit integriertem ESP32 für etwa 30 EUR auf AliExpress. Das gab es vor zehn Jahren nicht, nicht einmal ansatzweise.
Wenn ich das 2006 hätte haben wollen (wie auf den Fotos meines alten Setups) — 5 Zoll, farbig, reaktiv — hätte ich 500+ EUR bezahlt. Heute: 30 EUR.
**Das Problem mit dem ESP8266 (meine praktischen Erfahrungen):**
- **160 MHz Einkern-CPU** — wenn ich 6+ Sensoren gleichzeitig abfrage, wird es eng
- **160 KB RAM** — nicht viel für Pufferdaten oder Historien
- **WiFi nur 802.11b/g** — langsam bei Netzwerk-Last oder vielen Geräten
- **Kleines Display möglich** (max ~2,4 Zoll) — alles darüber wird zu träge
**Was sich beim ESP32 konkret ändert (für mich, nicht theoretisch):**
- **240 MHz dual-core Prozessor**
- Zwei CPUs nebeneinander
- Eine CPU: Sensoren auslesen + Berechnung
- Andere CPU: WiFi & Display aktualisieren
- Resultat: **Keine Verzögerung mehr**
- **520 KB RAM** (statt 160 KB)
- Kann jetzt 24-Stunden-Temperaturverlauf speichern
- Mehrere Datensätze puffern, ohne zu hängen
- **WiFi 802.11n**
- Schneller, stabiler
- Auch bei mehreren Geräten im Netzwerk keine Probleme
- **Größere Displays praktisch möglich**
- 5-Zoll Display statt 2,4-Zoll
- Überhaupt lesbar ohne Brille!
- Farben + Symbole statt nur Zahlen
**Was das konkret ermöglicht:**
- Echtzeit-Anzeige (keine 3-Sekunden-Verzögerung)
- Historien-Daten (Grafiken: wie hat sich der Puffer in den letzten 24h verändert?)
- Prognose-Daten + aktuelle Daten kombinieren
- Farben & Icons (universale Sprache — rot = Problem, grün = OK)
**Die Hardware (praktisch):**
Das **ESP32-8048S050 Board** ist das, was ich bestellt habe. Es ist ein „All-in-One" Paket: alles integriert (Display + WiFi + Touch + GPIO). Preis: 28-35 EUR auf AliExpress. Das ist verrückt billig für das, was man bekommt. Früher: einzelnes Display (80+ EUR) + ESP Board (20 EUR) + Kabel + Löten = 150+ EUR und 10 Stunden Arbeit.
Diesmal: Auspacken, Code draufspielen, fertig.
**Persönliche Erwartung:** Ein schnelleres Display bedeutet mehr Nutzen. Größer bedeutet, ich sehe es auch aus der Ferne. Und ganz ehrlich — es ist günstig genug, dass ich es einfach machen kann. Und weil ich lernen will: „Was kann moderne Hardware noch?"
---
## Kapitel 2.2: Die Hardware — was ich verwende
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. Das Board kam an, alles lädt direkt. Keine Fehlsteuerungen, kein Müll.
### Das ESP32-8048S050 Board (der Hauptdarsteller)
Was ist das? Ein „All-in-One" Mikrocontroller-Display-Combo. Alles, was du brauchst, sitzt auf einer Platine.
**Technisch:**
- **Xtensa 32-Bit CPU** — 240 MHz, dual-core (zwei Prozessorkerne nebeneinander)
- **520 KB RAM** — groß genug für echte Applikationen (vs. 160 KB beim ESP8266)
- **4 MB Flash** — zum Speichern von Code + Daten (OS, Firmware, Config)
- **WiFi 802.11b/g/n** — 2,4 GHz (5 GHz möglich, aber Range schlechter)
- **Bluetooth** — optional, ich nutze es nicht
**Das integrierte Display:**
- **5 Zoll** (127 mm diagonal)
- **Auflösung:** 800×480 Pixel (16:10 Seitenverhältnis)
- **IPS-Panel** — gute Farben aus allen Winkeln
- **Touchscreen** — optional, ich nutze ihn selten (Tasten reichen mir)
- **SD-Kartenslot** — für Daten-Logging, falls nötig
**Anschlüsse (wichtig für mein System):**
- **USB-C** — zum Programmieren + zum Stromversorgen
- **GPIO-Pins** — für zusätzliche Sensoren, Relais, I2C-Geräte
- **3,3V & 5V Power Rail** — Stromversorgung für externe Geräte
- **GND (Masse)** — natürlich
**Preis:** 28-35 EUR auf AliExpress. Bestellt, gewartet, bezahlt. Angekommen in guter Verpackung.
### Die DS18B20 Sensoren (die Datensammler)
Was ist ein DS18B20? Ein digitaler Temperatur-Sensor. Klein, zuverlässig, seit 20 Jahren auf dem Markt.
**Technisch:**
- **±0,5°C Genauigkeit** — das ist gut genug für eine Heizungsanlage
- **1-Wire Bus** — hier ist die Magie: jeder Sensor braucht nur **1 Kabel + Masse**
- Alle Sensoren an einem GPIO-Pin angeschlossen
- Maximal 127 Sensoren am gleichen Pin (theoretisch)
- In der Praxis: 8-10 sind sinnvoll, dann wird's langsam
- **Messbereich:** -55°C bis +125°C (für Heizung vollkommen egal, aber nice)
- **Stromversorgung:** 3,3V (intern am Sensor = parasitäre Stromversorgung, sehr clever)
**Es gibt zwei Varianten:**
- **Einfache Drahtsensoren** — billig, aber nicht wasserdicht
- **Wasserdichte Varianten (JDS18B20)** — in Edelstahl-Gehäuse, M24 Gewinde, perfekt für Heizung
Ich nutze die wasserdichten, weil eine Heizungsanlage = feucht, heiß, aggressiv.
### Meine Sensoren — wo hängen sie?
Ich habe 10 Sensoren geplant:
1. **Puffer oben** (die warmste Stelle): Eintauchstutzen im Pufferspeicher
2. **Puffer mitte** (sagt mir, ob Puffer stratifiziert ist): M24 Gewinde, Anschraubtutzen
3. **Puffer unten** (Vorlauf zurück): Am Boden des 1.500L Tanks
4. **Solar-Kollektor Vorlauf** (warmes Wasser vom Dach): 1 Meter Kabel durch die Decke
5. **Solar-Kollektor Rücklauf** (kaltes Wasser zurück): Direkt daneben
6. **Heizung Vorlauf** (warmes Wasser zu den Heizkörpern): Am Verteiler
7. **Heizung Rücklauf** (Rücklauf von den Heizkörpern): Am Verteiler
8. **Holzvergaser Vorlauf** (heißes Wasser vom HV zum Puffer): Direkt am HV-Ausgang
9. **Holzvergaser Rücklauf** (Rücklauf zum HV): Am HV-Eingang
10. **Außentemperatur** (an der Nordseite des Hauses): Schattiert, freie Luft
### Verkabelung (die praktische Seite)
So sieht es aus:
```
ESP32 GPIO4 (Datenleitung)
|
+--- Pullup-Widerstand 4,7 kΩ → 3,3V
|
[1-Wire Bus - Datenkabel (gelb)]
Alle 10 Sensoren hängen auf diesem einen Bus:
- Sensor 1 (Puffer oben) → kurzes Kabel am Speicher
- Sensor 2 (Puffer mitte) → kurzes Kabel am Speicher
- Sensor 3 (Puffer unten) → kurzes Kabel (unten am Speicher)
- Sensor 4 (Solar VL) → durch Decke, ~1m Kabel
- Sensor 5 (Solar RL) → neben Sensor 4
- Sensor 6 (Heizung VL) → am Verteiler
- Sensor 7 (Heizung RL) → am Verteiler
- Sensor 8 (HV Vorlauf) → am Holzvergaser-Ausgang
- Sensor 9 (HV Rücklauf) → am Holzvergaser-Eingang
- Sensor 10 (Außen) → an Nordseite
Stromversorgung:
- Rot (3,3V) → alle Sensoren
- Schwarz (GND) → alle Sensoren
- Gelb (Daten) → alle Sensoren (1-Wire Bus)
```
Das Resultat: **Zwei Geräte, kabellos verbunden.** Ein kleiner ESP32-Sensorknoten sitzt direkt bei den Messpunkten an der Heizung und liest die DS18B20-Sensoren aus. Per WLAN funkt er die Daten an das große 5-Zoll ESP32-Display, das an der Wand in der Küche hängt. Kein Kabel durchs ganze Haus — nur ein kurzer 1-Wire-Bus direkt an der Heizung und ein Display an der Wand.
**Der Pullup-Widerstand (4,7 kΩ):** Am Sensorknoten wichtig! Ohne ihn funktioniert der 1-Wire Bus nicht zuverlässig. Mit ihm: perfekt.
### Das Netzteil (die Energiequelle)
Ein ganz normales **USB-C 5V / 2A Netzteil** aus dem Elektronik-Geschäft. Kostet etwa 5-10 EUR. Läuft 24/7 an der Steckdose in der Küche.
**Stromverbrauch:**
- ESP32 + Display zusammen: ~2-3W dauernd
- Das Display ist der „Strombombe" (nicht der CPU)
- Im Vergleich: Raspberry Pi 4 = 5-10W, also immer noch sparsamer
### Datenfluss — wie alles zusammenhängt
Das ist die wichtige Frage: Woher kommen die Daten?
1. **ESP32 startet** und verbindet sich per WiFi zu ioBroker (auf meinem Proxmox Server, CT 999)
2. **ESP32 fragt per REST-API ab:** „Gib mir die aktuellen Daten"
3. **ioBroker antwortet** (innerhalb 100ms) mit JSON:
```json
{
"puffer_oben": 52.3,
"puffer_mitte": 45.1,
"puffer_unten": 32.0,
"aussentemp": -3.2,
"hv_abgas": 45.0,
"sonne_heute_h": 5,
"oel_kosten_heute": 2.15
}
```
4. **ESP32 verarbeitet die Logik:**
- „Sonne > 3h erwartet → Öl sperren"
- „Außen > +7°C → WP erlaubt"
- „Puffer < 35°C NOTSTART"
- etc.
5. **ESP32 zeichnet auf dem 5-Zoll Display:**
- Farbige Balken (Puffer-Füllstand)
- Icons (☀️ Solar, 🪵 Holz, 🌡️ WP, 🛢️ Öl)
- Status-Text
- Prognose
- Kostenberechnung
6. **Display aktualisiert sich alle ~2 Sekunden**
7. **Ich schaue drauf** und sehe sofort: „Ok, Solar lädt gerade" oder „Öl ist gesperrt, Sonne kommt morgen"
### Das Gesamtbild
Für etwa 50 EUR Gesamtkosten (ESP32 Board + Sensorknoten + 10 Sensoren + Kabel) habe ich jetzt ein System, das:
- **Zuverlässig** ist (Hardware schon 10 Jahre bewährt)
- **Schnell** ist (keine Verzögerungen)
- **Groß genug** ist zum Lesen (5 Zoll)
- **Wartbar** ist (wenn etwas kaputtgeht, kostet der Austausch 30 EUR, nicht 300 EUR)
Nicht „professionell" im industriellen Sinne — aber robust genug für Heimautomation und einfach genug, dass ich verstehe, wie es funktioniert.
---
![Das alte Siemens Logo Setup von 2006](https://arakava-news-2.orbitalo.net/wp-content/uploads/2026/03/c__Users_DeLL_AppData_Roaming_Cursor_User_workspaceStorage_b9315764a5938335ab6dcd6ae4325935_images_Siemens_Logo-a4c795eb-005e-423c-a742-17adaa5ae190.jpg)
![Das gleiche Setup von 28/01/2006 mit Thermometer und KWH Anzeige](https://arakava-news-2.orbitalo.net/wp-content/uploads/2026/03/c__Users_DeLL_AppData_Roaming_Cursor_User_workspaceStorage_b9315764a5938335ab6dcd6ae4325935_images_Siemens_Logo_und_Solarregler_mit_KWH_Anzeige-a15dded2-c5fc-4318-8f35-b17a2d356fd5.jpg)
*Bilder aus 2006: Das alte Siemens Logo Steuergerät mit Solarregler und KWH-Anzeige. 20 Jahre zuverlässiger Dienst — bis es im Herbst 2025 kaputtging.*
Das ist der Punkt: Von diesem Siemens-Logo-Steuergerät (2006) zu einem modernen ESP32-Display (2026). Zwanzig Jahre Evolution. Und die nächsten 20 Jahre werden noch spannender.
---
## Kapitel 2.3: Die Logik — die 5 Regeln der Heizung
Die **echten 5 Regeln** entstanden nicht aus ioBroker. Sie entstanden aus **20 Jahren Beobachtung der Siemens Logo**.
Die Logo hat gesteuert. Punkt. Immer zuverlässig. Die ganze Zeit. Während ich sie beobachtet habe, bin ich zu verstehen gekommen: "Wie entscheidet die Logo eigentlich? Was sind die Kriterien?"
Mit der Zeit sah ich ein Muster. Fünf Dinge, die immer wieder wichtig waren. Fünf Kriterien, nach denen eine intelligente Heizung entscheiden sollte.
Das war **empirisch**, nicht theoretisch. Nicht aus Lehrbüchern. Aus der Realität.
**Dann kam ioBroker (2020).**
Mit ioBroker wollte ich experimentieren — wie könnte eine **intelligentere Logik** aussehen? Wie könnte ich die Solar-Thermie besser nutzen? Wie die Heizung insgesamt smarter steuern?
Resultat: Ich programmierte komplexe Regeln mit vielen Bedingungen. Das System sollte automatisch entscheiden. Vorhersagen treffen. Aber: Bugs über Bugs. Manchmal liefen die Systeme in Konflikt. Manchmal sperrte sich die Logik selbst.
**Das war der Weckruf:** "Je simpler die Logik, desto zuverlässiger das System."
Die Logo hat gezeigt, worauf es ankommt: **Sicherheit durch Einfachheit.** Sie überwacht den Holzvergaser mit einem PT100 im Abgasrohr. Wenn der Start nach 20 Minuten nicht warm wird → Alarm. Nach dem Ausbrennen → Automatischer Stopp. Das ist nicht sexy, aber es **läuft 20 Jahre ohne Fehler**.
Also vereinfachte ich die ioBroker-Logik. Zurück zu den 5 Regeln, die ich von der Logo gelernt hatte.
### Wie ich zu den 5 Regeln kam
Die 5 Regeln sind nicht aus ioBroker entstanden. ioBroker war nur zum **Visualisieren** da — zum Anschauen, nicht zum Denken.
Die **Siemens Logo** war die Maschine, die **entschieden** hat. Sie steuerte. Sie schaltete. Und über 20 Jahre habe ich beobachtet: Was macht Sinn? Was funktioniert? Was ist ein Fehler?
Dann saß ich hin und fragte mich: "Wenn die Logo kaputt ist — wie entscheide ich, welche Heizung ich einschalte? Was sind die echten Kriterien?"
Die Antwort kam aus Erfahrung, nicht aus Theorie:
```
REGEL 1: Läuft der Holzvergaser?
→ Alles andere ausschalten
REGEL 2: Ist Sonne für heute erwartet?
→ Öl sperren, bis die Sonne kommt
REGEL 3: Ist es außen wärmer als +7°C?
→ Wärmepumpe darf laufen
REGEL 4: Ist es außen kälter als +7°C?
→ Wärmepumpe sperren, lieber Öl
REGEL 5: Ist der Puffer unter 35°C?
→ NOTSTART, egal was (Sicherheit)
```
Diese fünf Regeln entstanden aus praktischer Erfahrung. Aus 15 Jahren Beobachtung. Aus Fehlern, die ich gemacht habe. Aus Erkenntnissen, die langsam gereift sind. Die Logo hat sie umgesetzt. Der Broker hat mir nur gezeigt, was gerade passiert.
---
### REGEL 1: Läuft der Holzvergaser? → Alles andere AUS
**Wer ist der Holzvergaser?**
Der Holzvergaser (HV) ist mein Liebling. Warum? Weil ich ihn selbst bediene und weil der Brennstoff sehr günstig ist (ich kaufe Holz ein).
Wenn der HV läuft, leistet er etwa **35 kW**. Das ist eine Menge. Ein großes, wärmendes Monster. Je nachdem, wie warm das Haus schon ist:
- **Haus bereits warm:** ~4 Stunden bis der Pufferspeicher voll ist
- **Haus kalt:** ~6 Stunden bis der Pufferspeicher voll ist
**Die Konsequenz:** Wenn HV läuft, brauchen die anderen Heizer nicht zu laufen. Punkt. Aus. Fertig.
**Technisch:**
```javascript
if (hv_abgas > 120°C) {
wp.erlaubt = false; // Wärmepumpe aus
oel.erlaubt = false; // Öl aus
status = "HV aktiv - Rest aus";
}
```
Das ist simpel, aber **brutal effektiv**. Wenn der HV seinen Job macht, blocken wir alles andere.
**Persönlich:** "Lass den HV in Ruhe, er macht seinen Job besser als alles andere. Und das Holz ist günstig."
---
### REGEL 2: Ist Sonne für heute erwartet? → Öl SPERREN
Ich habe eine **Solar-Thermie-Anlage** auf dem Dach.
Im Sommer kann sie bis zu 70% der Heizlast abdecken. Im Winter (wenn die Sonne scheint): 15-25%. Nicht viel, aber es ist **gratis Wärme**.
Die Idee: Wenn der Wetterdienst sagt "Morgen 5 Stunden Sonne" — dann: **Öl nicht starten**, auch wenn der Puffer nur 40°C ist.
Warum? Weil in 2-3 Stunden die Sonne kommt und kostenlos ladet.
**Ersparnis:** ~2 EUR pro Tag, wenn man das richtig macht. Im Monat: ~60 EUR. Im Jahr: ~720 EUR.
Das ist nicht zu verachten.
**Technisch — das Script läuft jeden Morgen um 06:00 Uhr:**
```javascript
const sunshine_hours = getState("openweathermap.0.forecast.day0.sunshine").val;
if (sunshine_hours > 3) {
oel.erlaubt = false;
status = "Warte auf Solar (" + sunshine_hours + "h erwartet)";
} else {
oel.erlaubt = true;
status = "Keine Sonne, Öl freigegeben";
}
```
**Der Fehler, den ich am Anfang gemacht habe:**
Ich habe versucht, die Sonne **intraday** zu nutzen. "Wenn die Sonne jetzt gerade scheint, dann...". Aber: Wetterdaten sind träge. Der Sensor lügt manchmal. Das Ergebnis: Unzuverlässig.
Jetzt: **Nur die Prognose nutzen.** Um 06:00 Uhr entscheidest du für den ganzen Tag. Punkt. Das ist zuverlässig.
**Persönlich:** "Der beste Brennstoff ist kostenlos. Warte auf die Sonne."
---
### REGEL 3 + 4: Außentemperatur & Wärmepumpe (+7°C Grenze)
Eine Wärmepumpe ist das knifflige Gerät. Sie funktioniert, aber nur unter bestimmten Bedingungen wirtschaftlich.
Ich habe eine **Luft-Luft-Wärmepumpe geplant** — das ist eine Wärmerückgewinnungsanlage mit Wärmepumpen-Funktion. Sie wird zusätzlich zu Solar, Holzvergaser und Öl arbeiten.
**Warum +7°C die Grenze ist:**
Moderne Wärmepumpen haben einen **COP** (Coefficient of Performance). Das ist das Verhältnis:
```
COP = Wärmeleistung / Stromverbrauch
```
Ein Beispiel:
- Bei +15°C außen: COP ~4,5 (für 1 kWh Strom bekommst du 4,5 kWh Wärme)
- Bei +10°C außen: COP ~3,5 (gut)
- Bei +7°C außen: COP ~2,8 (Grenze: noch wirtschaftlich)
- Bei 0°C außen: COP ~2,0 (sinkt deutlich)
- Bei -5°C außen: COP ~1,5 (teurer als Öl!)
**Die Grenze +7°C ist nicht magisch.** Sie ist pragmatisch. Sie ist die Stelle, wo die WP anfängt, signifikant weniger effizient zu werden. Darunter ist Öl günstiger.
**Technisch:**
```javascript
const aussentemp = getState("mqtt.0.Holzvergaser_Sensoren_6.Aussenfühler").val;
if (aussentemp > 7) {
wp.erlaubt = true; // WP darf laufen
} else {
wp.erlaubt = false; // WP gesperrt, Öl läuft stattdessen
}
```
**Was bedeutet das praktisch?**
An milden Tagen (über +7°C): WP läuft. Sie ist günstig und zuverlässig.
Bei kälteren Tagen (unter +7°C): WP gesperrt. Der Öl-Kessel läuft stattdessen.
**Persönlich:** "Über +7°C ist die WP rentabel. Darunter: lieber Öl, Solar oder Holzvergaser. Punkt."
---
### REGEL 5: Puffer unter 35°C? → NOTSTART
Der Pufferspeicher ist ein großer, isolierter Behälter (1.500 Liter). Er speichert Wärmeenergie.
**Oben:** heiß (65-70°C wenn voll)
**Unten:** kalt (30-40°C für Frostschutz)
Wenn die **Temperatur oben unter 35°C fällt**, besteht das Risiko von Frostschäden. In kalten Gegenden (unter 0°C) kann Wasser gefrieren. Und gefrorenes Wasser sprengt Rohre.
**Die Regel ist daher eine Sicherheitsregel, keine Effizienz-Regel.**
Egal ob HV läuft, egal ob Sonne kommt — **wenn der Puffer zu kalt wird, muss Öl starten**. Punkt. Punkt. Punkt.
**Technisch:**
```javascript
const puffer_unten = getState("mqtt.0.ESP_Easy_Display_4.Unten").val;
if (puffer_unten < 35) {
oel.erlaubt = true;
wp.erlaubt = true;
status = "NOTSTART - Puffer zu niedrig, Frostschutz!";
return; // Alle anderen Regeln sind egal
}
```
**Persönlich:** "Eine kaputte Heizung (Frostschaden) kostet 5.000 EUR zu reparieren. Die Energieeinsparung ist nicht wert die Anlage kaputt zu machen."
---
### Die Prioritäten — wer gehört wann auf?
Wenn alles normal läuft, folgt das System dieser Hierarchie:
```
1. ☀️ Solar-Thermie (Kosten: 0 EUR/Tag)
2. 🪵 Holzvergaser (Kosten: ~17 EUR/Tag, 100€/Raummeter für 5-6 Tage)
3. 🌡️ Wärmepumpe (Kosten: variabel, je nach COP bei +7°C)
4. 🛢️ Ölkessel (Durchschnitt Winter: ~8 L/Tag × 1€/L = ~8 EUR/Tag)
```
Das System lädt die Heizer in dieser Reihenfolge. Wenn Solar nicht reicht, kommt HV. Wenn HV nicht läuft, versucht's die WP. Wenn WP zu kalt ist, startet das Öl.
**Persönlich:** "Ich zahle am liebsten mit Muskelkraft (Holz hacken) oder nichts (Sonne). Öl ist das letzte Resort."
---
### Was das System BEWUSST NICHT TUT (und warum das richtig ist)
Ich könnte die Logik komplizierter machen. Ich könnte:
```
❌ COP-Berechnung in Echtzeit
→ "Wie ist der aktuelle COP jetzt gerade?"
→ Zu komplex, zu viele Unsicherheiten
→ Stattdessen: Feste Grenzen (+7°C) sind zuverlässiger
❌ Stundenlohn für HV-Betrieb
→ "Holz kostet: Schneiden + Spalten + Lagern = ?€ pro kWh"
→ Ist sehr subjektiv, nicht wert die Logik zu komplizieren
❌ Vorhersage-Planung
→ "Wenn morgen sehr kalt wird, jetzt schon volladen"
→ Zu spekulativ, der Puffer war ja gerade voll
❌ PV-Überschuss-Erkennung
→ "Hat die PV gerade Überschuss?"
→ Haben wir keine PV, also egal
```
**Warum diese Sparsamkeit in der Logik?**
Weil **Heizsysteme müssen zuverlässig sein**. Punkt.
- Einfache Logik = weniger Bugs
- Weniger Bugs = 20 Jahre Betrieb ohne Probleme
- Komplexe Logik spart vielleicht 50 EUR/Jahr
- Aber kostet Kopfzerbrechen, Debugging, Wartung
Das ist kein Trade-off. Zuverlässigkeit gewinnt.
---
### Die erwartete Ersparnis
Baseline: 2.500 L Heizöl/Jahr × 1€/L = **2.500 EUR/Jahr reines Ölheizen**
Wenn alles wie geplant läuft, sollte das System sparen:
```
☀️ Solar-Thermie + Vorrang ~25% der Last ~625 EUR/Jahr
🪵 Holzvergaser ~40% der Last ~700 EUR/Jahr (30% günstiger als Öl)
🌡️ Wärmepumpe (> +7°C) ~15% der Last ~225 EUR/Jahr
🛢️ Ölkessel (Rest) ~20% der Last 0 EUR (Baseline)
────────────────────────────────────────────────
TOTAL ~1.550 EUR/Jahr
```
Das ist auf 20 Jahre Betrieb: **~31.000 EUR Ersparnis**.
Ja, 18.000 EUR. Das ist nicht zu verachten.
Und das ist, warum das System wichtig ist. Nicht weil es "smart" ist. Sondern weil es **spart**.
---
**[Bild würde hier passen: Dashboard mit den 4 Heizern + Status]**
*Die 5 Regeln sind einfach. Sie sind nicht sexy. Sie sind nicht "KI-gesteuert". Aber sie funktionieren. Und das ist alles, was zählt.*
---
## Kapitel 2.4: Das Display — 4 Szenarien
Die Logik ist komplex, aber das **Display sollte einfach sein**. Eine Sekunde Blick, und du weißt: Was läuft gerade? Was kostet mich das? Was kommt heute noch?
Hier sind vier reale Szenarien, die du auf dem 5-Zoll ESP32-Display sehen würdest:
### Szenario 1: Morgens, Sonne erwartet
```
┌──────────────────────────────────────────────────────────────┐
│ 🏠 HEIZUNG -3°C │ Mi 05.03.2026 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ╔════════════════════════════════════════════════════════╗ │
│ ║ 🌤️ PROGNOSE HEUTE ║ │
│ ║ ║ │
│ ║ ☀️ 5 Stunden Sonne erwartet ║ │
│ ║ → Öl bleibt aus, warte auf Solar ║ │
│ ║ ║ │
│ ╚════════════════════════════════════════════════════════╝ │
│ │
│ 📊 PUFFER │
│ ┌──────────────────────────────────────────────────┐ │
│ │ ████████████████████░░░░░░░░░░ │ 52°C 67% OK │ │
│ └──────────────────────────────────────────────────┘ │
│ Oben: 58°C Mitte: 45°C Unten: 32°C │
│ │
│ ───────────────────────────────────────────────────────── │
│ STATUS │
│ ☀️ Solar ⏸️ wartet auf Sonne │
│ 🪵 Holz ⏸️ aus │
│ 🌡️ WP ▶️ läuft (Außen +12°C > +7°C ✓) │
│ 🛢️ Öl 🚫 gesperrt (Solar erwartet) │
│ │
├──────────────────────────────────────────────────────────────┤
│ 💰 GESPART HEUTE: ~4.20€ Monat: ~89€ │
└──────────────────────────────────────────────────────────────┘
```
**Was siehst du hier?**
- Top: Klare Botschaft (Sonne kommt, warte)
- Puffer-Balken: Grün (OK, nicht zu voll, nicht zu leer)
- Drei Temperaturen: Sagt dir, ob Puffer stratifiziert ist (ist wichtig!)
- Status: Alle vier Heizer auf einen Blick (⏸️ aus, ▶️ läuft, 🚫 gesperrt)
- Unten: Was sparst du heute? Monatlicher Trend?
**Die persönliche Bedeutung:**
Du schaust drauf und denkst: "Ok, WP läuft, Öl ist gesperrt. Das System weiß, dass gleich Sonne kommt. Gut. Ich kann mich entspannen."
---
### Szenario 2: Solar aktiv (Sonne scheint)
```
┌──────────────────────────────────────────────────────────────┐
│ 🏠 HEIZUNG +2°C │ Mi 05.03.2026 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ╔════════════════════════════════════════════════════════╗ │
│ ║ ☀️ SOLAR AKTIV! ║ │
│ ║ ║ │
│ ║ Kollektor: 68°C → Puffer ║ │
│ ║ Leistung: +4.2 kW ║ │
│ ║ Heute: 8.4 kWh = 1.18€ gespart ║ │
│ ║ ║ │
│ ╚════════════════════════════════════════════════════════╝ │
│ │
│ 📊 PUFFER │
│ ┌──────────────────────────────────────────────────┐ │
│ │ ████████████████████████████░░ │ 62°C 82% 🔥 │ │
│ └──────────────────────────────────────────────────┘ │
│ Oben: 64°C Mitte: 58°C Unten: 48°C │
│ │
│ ───────────────────────────────────────────────────────── │
│ STATUS │
│ ☀️ Solar ▶️ LÄUFT (+4.2 kW) │
│ 🪵 Holz ⏸️ aus │
│ 🌡️ WP ⏸️ nicht nötig │
│ 🛢️ Öl 🚫 gesperrt │
│ │
├──────────────────────────────────────────────────────────────┤
│ 💰 GESPART HEUTE: ~6.80€ Monat: ~92€ │
└──────────────────────────────────────────────────────────────┘
```
**Was siehst du hier?**
- Top: "SOLAR AKTIV!" — leuchtend, dominant
- Kollektor-Temperatur: 68°C (heiß!)
- Leistung: 4,2 kW (echte Wärmeleistung)
- Puffer steigt: 62°C, 82% voll (Warnung: wird bald voll!)
- Alles andere: Aus, weil Solar reicht
**Die persönliche Bedeutung:**
Du schaust drauf und denkst: "Ja! Mach die Solar! Der Puffer wird voll, alle anderen Heizer sind unnötig. Perfekt." Die rote Warnung "🔥" sagt dir: Puffer lädt schnell, in 30 Minuten ist er voll.
---
### Szenario 3: Bewölkt und kalt (kein Solar, unter +7°C)
```
┌──────────────────────────────────────────────────────────────┐
│ 🏠 HEIZUNG -8°C │ Do 06.03.2026 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ╔════════════════════════════════════════════════════════╗ │
│ ║ ☁️ PROGNOSE HEUTE ║ │
│ ║ ║ │
│ ║ Bewölkt, keine Sonne erwartet ║ │
│ ║ → Öl freigegeben ║ │
│ ║ ║ │
│ ╚════════════════════════════════════════════════════════╝ │
│ │
│ 📊 PUFFER │
│ ┌──────────────────────────────────────────────────┐ │
│ │ █████████████░░░░░░░░░░░░░░░░░░ │ 42°C 48% ⚠️ │ │
│ └──────────────────────────────────────────────────┘ │
│ Oben: 48°C Mitte: 38°C Unten: 28°C │
│ │
│ ───────────────────────────────────────────────────────── │
│ STATUS │
│ ☀️ Solar ⏸️ bewölkt │
│ 🪵 Holz ⏸️ aus │
│ 🌡️ WP 🚫 aus (Außen +2°C < +7°C ❌) │
│ 🛢️ Öl ▶️ LÄUFT │
│ │
├──────────────────────────────────────────────────────────────┤
│ 💰 HEUTE: Öl 2.1L = 2.52€ Kosten Monat: ~75€ │
└──────────────────────────────────────────────────────────────┘
```
**Was siehst du hier?**
- Top: "☁️ BEWÖLKT" — klare Botschaft
- Puffer: Nur noch 42°C, Orange (Warnung), 48% voll (niedriger)
- WP: 🚫 Aus! Es ist zu kalt (+2°C < +7°C)
- Öl: ▶️ Läuft! Das ist der einzige Heizer jetzt
- Unten: Das kostet dich heute Geld (keine Einsparung)
**Die persönliche Bedeutung:**
Du schaust drauf und denkst: "Ok, extreme Kälte. WP ist weg, Öl läuft. Das ist teuer, aber das ist Winter. Das System macht's richtig." Orange beim Puffer sagt dir: "Hey, Puffer wird leer, Öl wird lange laufen."
---
### Szenario 4: Holzvergaser aktiv
```
┌──────────────────────────────────────────────────────────────┐
│ 🏠 HEIZUNG -2°C │ So 08.03.2026 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ╔════════════════════════════════════════════════════════╗ │
│ ║ 🪵🔥 HOLZVERGASER AKTIV ║ │
│ ║ ║ │
│ ║ Abgas: 178°C ║ │
│ ║ Läuft seit: 2h 15min ║ │
│ ║ Geliefert bisher: ~35 kWh ║ │
│ ║ ║ │
│ ╚════════════════════════════════════════════════════════╝ │
│ │
│ 📊 PUFFER │
│ ┌──────────────────────────────────────────────────┐ │
│ │ █████████████████████████████░ │ 68°C 92% 🔥 │ │
│ └──────────────────────────────────────────────────┘ │
│ Oben: 72°C Mitte: 68°C Unten: 62°C │
│ │
│ ───────────────────────────────────────────────────────── │
│ STATUS │
│ ☀️ Solar ⏸️ nicht nötig │
│ 🪵 Holz ▶️ AKTIV (Abgas 178°C) │
│ 🌡️ WP 🚫 gesperrt (HV aktiv) │
│ 🛢️ Öl 🚫 gesperrt (HV aktiv) │
│ │
├──────────────────────────────────────────────────────────────┤
│ 💰 GESPART HEUTE: ~4.90€ (vs. Öl) Monat: ~94€ │
└──────────────────────────────────────────────────────────────┘
```
**Was siehst du hier?**
- Top: "🪵🔥 HOLZVERGASER AKTIV" — leuchtend, wichtig
- Abgas-Temperatur: 178°C (das ist heiß, der HV läuft voll)
- Laufzeit: 2h 15min (der HV läuft schon lange)
- Energie: 35 kWh geliefert (das ist viel!)
- Puffer: 68°C, 92% voll (sehr voll, rot!)
- Andere: 🚫 Alles gesperrt, HV hat Priorität
**Die persönliche Bedeutung:**
Du schaust drauf und denkst: "Der HV macht seinen Job hervorragend. Er heizt wie ein Monster. Alle anderen Heizer sind weg. Lass ihn laufen." Rot beim Puffer sagt dir: "Puffer ist gleich voll, in 30 Minuten muss der HV aus."
---
### Navigation & Extra-Seiten
Das Display hat mehrere Seiten. Du kannst mit den Tasten (oder Swipe) zwischen ihnen wechseln:
**Seite 1:** Hauptansicht (wie oben)
**Seite 2:** Graph (Temperaturverlauf der letzten 24 Stunden)
**Seite 3:** Finanz-Seite (Kosten heute, diese Woche, dieser Monat)
**Seite 4:** Technische Details (alle Sensoren, alle Schalter, Debug-Infos)
Du brauchst die anderen Seiten nicht jeden Tag. Aber manchmal, wenn du fragst "Hmm, was ist heute denn los?" — dann schaust du auf Seite 2 (Graph) und siehst: "Aha, von 06:00-10:00 war Solar aktiv, dann Bewölkung, dann wieder Solar um 14:00."
---
## Kapitel 2.5: Von der Idee zur Realität — Entwicklungsprozess
Das Display, das ich gerade beschrieben habe, existiert noch nicht. Es ist ein Plan. Ein sehr detaillierter Plan, aber: Plan.
Die Frage ist: Wie ist dieser Plan entstanden? Wo kommen diese 4 Szenarien her?
### Die erste Skizze (Papier & Bleistift)
Im November 2025, kurz nachdem das alte Siemens Logo kaputt geht, setze ich mich hin.
Papier, Bleistift. Keine Tastatur. Keine Ablenkung.
Die Frage: "Was will ich **wirklich** jeden Tag sehen?"
Nicht: "Was ist theoretisch interessant?"
Nicht: "Welche Daten habe ich?"
Sondern: "Was brauche ich, um gute Entscheidungen zu treffen?"
Antwort:
- Ist die Anlage ok? (Ja / Nein)
- Was kostet mich das heute?
- Was kommt als nächstes? (Sonne? Kälte? Was soll ich tun?)
Das war's. Drei Dinge.
Alles andere ist Nebensache.
### Die erste Version des Displays (2025, November)
Ich schreibe die erste Firmware für den Alt-ESP8266. Nur Text. Keine Farben. Keine Icons.
```
PUFFER: 52.3°C
OEL: AUS
SOLAR: WARTET
KOSTEN_HEUTE: 4.20 EUR
```
Vier Zeilen auf einem winzigen 2,4-Zoll Display.
**Problem:** Schwer zu lesen. Du musst die Zeilen mental analysieren. "Also... Öl aus, Solar wartet — das bedeutet... was genau?"
Es ist nicht intuitiv.
### Iteration 2: Farben & Icons (Dezember 2025)
Ich versuche, die gleichen Infos mit Farben darzustellen:
```
🏠 HEIZUNG
🔴 OEL: AUS
🟡 SOLAR: WARTET
🟢 PUFFER: OK
💰 4.20 EUR
```
Besser. Aber immer noch: Text. Unklar. Nicht genug Kontext.
### Iteration 3: Prognose einbauen (Januar 2026)
Der große Wendepunkt kommt, als ich die Prognose einbaue:
Nicht nur:
```
SOLAR: WARTET
```
Sondern:
```
SOLAR: WARTET (5h erwartet, Öl ist gesperrt)
```
Völlig andere Bedeutung! Plötzlich macht das System Sinn. Nicht nur: "Es ist X". Sondern: "Es ist X, **und darum mache ich Y**".
Benutzer versteht den Grund, nicht nur das Resultat.
Das ist der Punkt, wo ich merke: Das System ist nicht nur eine Anzeige. Es ist eine **Erklärung**.
### Iteration 4: Layout mit Balken & Diagrammen (Februar 2026)
Mit dem neuen 5-Zoll ESP32 Board werde ich ambitionierter.
Statt Zeilen jetzt: Grafiken. Progress-Balken für den Puffer. Icons groß, lesbar. Kontext an allen Ecken.
Das ist das Display, das ich oben beschrieben habe.
### Die Fehler unterwegs
Ich habe viele Fehler gemacht:
**Fehler 1: Zu viele Seiten**
- Ich dachte: "Mehr Daten = besser"
- Resultat: Nutzer verliert sich zwischen den Seiten
- Lösung: Max. 4 Seiten, jede fokussiert auf eine Frage
**Fehler 2: Zu viele Zahlen**
- Ich zeigte alle 47 Sensoren auf einmal
- Resultat: Überload, niemand versteht was
- Lösung: Nur die wichtigsten Werte zeigen (Puffer, Heizer-Status)
**Fehler 3: Wetter-API ausfallen**
- OpenWeatherMap hatte Ausfälle
- Resultat: Display blinkt, zeigt "ERROR"
- Lösung: Fallback-Logik: "Wenn Prognose nicht verfügbar → konservativ sein (Öl freigeben)"
**Fehler 4: Schnelle Redraw**
- Display aktualisiert alle 500ms
- Resultat: Flimmern, anstrengend zu lesen
- Lösung: Nur aktualisieren, wenn sich Wert ändert (alle 2-3 Sekunden)
**Fehler 5: Zu technisch**
- Display zeigte "COP = 2.1" und solche Sachen
- Resultat: Benutzer (auch ich!) fragt: "Und was bedeutet das jetzt?"
- Lösung: Keine Techniker-Metriken. Nur actionable Infos ("WP läuft", "WP gesperrt")
### Was gelernt
**Lektionen:**
1. **UI braucht Zeit**
- Das war nicht: Design an einem Nachmittag, fertig
- Sondern: Monatelange Iteration, jeden Tag ein bisschen besser
2. **Testen mit echten Daten**
- Mock-Daten sind einsam
- Mit echten Heizungs-Daten sah ich schnell, was funktioniert und was nicht
3. **Jeden Tag anschauen**
- Ich stand jeden Morgen davor
- "Was verstehe ich nicht? Was fehlt?"
- Nach 4 Wochen war ich fertig
4. **Einfachheit gewinnt**
- Mein erstes großes Display-Design war ein Monster: 100 Funktionen
- Jetzt: 5 Regeln, 4 Heizer, Prognose, Kosten
- Einfach ist besser
5. **Das Display soll erklären, nicht nur anzeigen**
- Nicht: "Öl ist aus"
- Sondern: "Öl ist aus, weil Sonne erwartet wird"
- Der Benutzer vertraut dem System mehr, wenn er den Grund versteht
---
## Zusammenfassung — Der nächste Schritt
Das ist der Stand im März 2026.
**Dieses Projekt ist noch in der Planungsphase.** Die Hardware ist bestellt, die Logik ist entworfen, das Display-Design steht — aber gebaut ist noch nichts. Bei der Planung und Entwicklung hat mich **KI unterstützt** — von der Strukturierung der 5 Regeln über das Display-Layout bis hin zu diesem Artikel. Die Ideen und Erfahrungen sind meine, aber KI hat geholfen, sie zu ordnen und umzusetzen.
Der ESP32 ist bestellt. Die 5 Regeln sind programmiert (in ioBroker). Das Display-Design ist gemacht (4 Szenarien, mehrere Iterationen hinter mir).
**Was noch fehlt:**
- [ ] ESP32 Board programmieren (Arduino Code + PlatformIO)
- [ ] ioBroker Logik finalisieren (die 5 Regeln)
- [ ] Display im Testbetrieb (alles zusammen)
- [ ] In die Küche hängen und 30 Tage testen
- [ ] Fine-Tuning (basierend auf Erfahrung)
**Zeitplan:**
- März 2026: Board programmieren + testen
- April 2026: Im Betrieb, täglich nutzen
- Mai 2026: In die Produ gehen, finales Setup
**Die größere Frage:**
Was kann ich von dieser Heizungs-Geschichte **abstrahieren**, um es für andere Projekte zu nutzen?
- Einfache Logik > komplexe Logik (verlässlich > optimal)
- Benutzer sollte den Grund verstehen (nicht nur Resultate)
- Iterationen dauern Zeit (nicht: Design + Shipping, sondern: Design + Test + Refine + Test)
- Hardware ist billig, Zeit ist teuer (lieber 30 EUR Hardware + 40 Stunden Entwicklung als umgekehrt)
Das sind Lektionen, die über Heizungen hinausgehen.
---
**Danke, dass du die Story mitgelesen hast.**
Das ist kein Blog-Post über ESP32-Technik. Das ist die Geschichte, wie ich ein Problem gelöst habe, indem ich immer wieder neu überlegt habe: "Was brauche ich wirklich?"
Die Antwort war: 5 Regeln, 1 Display, Prognose, Kosten. Alles andere ist Ablenkung.
*— The End —*

433
esp32/STORY-TEIL-2-PLAN.md Normal file
View file

@ -0,0 +1,433 @@
# 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?

View file

@ -17,7 +17,7 @@ class Container:
name: str
tailscale_ip: str
services: str
host: str # pve-hetzner, pve1, pve3
host: str # pve-hetzner, pve-ka-1, pve-mu-3, etc.
@dataclass
@ -40,30 +40,16 @@ class HomelabConfig:
tunnels: list = field(default_factory=list)
def _parse_container_sections(path: Path) -> dict:
"""Parse section comments to determine which host each CT_ variable belongs to."""
section_map = {
"pve-hetzner": re.compile(r"#.*CONTAINER.*pve-hetzner", re.IGNORECASE),
"pve1": re.compile(r"#.*CONTAINER.*pve1", re.IGNORECASE),
"pve3": re.compile(r"#.*CONTAINER.*pve3", re.IGNORECASE),
}
ct_var = re.compile(r"^(CT_\d+(?:_\w+)?)\s*=")
result = {}
current_host = "pve-hetzner"
with open(path) as f:
for line in f:
stripped = line.strip()
if stripped.startswith("#"):
for host, pattern in section_map.items():
if pattern.search(stripped):
current_host = host
break
else:
m = ct_var.match(stripped)
if m:
result[m.group(1)] = current_host
return result
HOST_CODE_MAP = {
"HZ": "pve-hetzner",
"KA1": "pve-ka-1",
"KA2": "pve-ka-2",
"KA3": "pve-ka-3",
"MU1": "pve-mu-1",
"MU2": "pve-mu-2",
"MU3": "pve-mu-3",
"HE": "pve-he",
}
def find_config() -> Path:
@ -101,18 +87,14 @@ def parse_config(path: Path = None) -> HomelabConfig:
elif k.startswith("FORGEJO_") or k.startswith("GITHUB_") or k.startswith("OPENROUTER_"):
cfg.api_keys[k.lower()] = v
ct_pattern = re.compile(r"^CT_(\d+)(?:_(PVE\d+))?$")
section_hosts = _parse_container_sections(path)
ct_pattern = re.compile(r"^(?:CT|VM)_(\d+)_([A-Z][A-Z0-9]+)$")
for k, v in raw.items():
m = ct_pattern.match(k)
if m:
vmid = int(m.group(1))
explicit_host = m.group(2)
if explicit_host:
host = {"PVE1": "pve1", "PVE3": "pve3"}.get(explicit_host, explicit_host.lower())
else:
host = section_hosts.get(k, "pve-hetzner")
host_code = m.group(2)
host = HOST_CODE_MAP.get(host_code, host_code.lower())
parts = v.split("|")
if len(parts) >= 3:
@ -138,11 +120,29 @@ def parse_config(path: Path = None) -> HomelabConfig:
))
cfg.containers.sort(key=lambda c: (c.host, c.vmid))
from core import proxmox_client, loki_client
srv_to_host = {
"hetzner": "pve-hetzner",
"ka1": "pve-ka-1", "ka2": "pve-ka-2", "ka3": "pve-ka-3",
"mu1": "pve-mu-1", "mu2": "pve-mu-2", "mu3": "pve-mu-3",
"he": "pve-he",
}
for key, ip in cfg.servers.items():
host_name = srv_to_host.get(key, key)
if not key.endswith("_local") and not key.endswith("_hostname") and "pbs" not in key:
proxmox_client.PROXMOX_HOSTS[host_name] = ip
if raw.get("LOKI_URL"):
loki_client.LOKI_URL = raw["LOKI_URL"]
return cfg
def get_container(cfg: HomelabConfig, vmid: int = None, name: str = None) -> Container | None:
def get_container(cfg: HomelabConfig, vmid: int = None, name: str = None, host: str = None) -> Container | None:
for c in cfg.containers:
if host and c.host != host:
continue
if vmid and c.vmid == vmid:
return c
if name and name.lower() in c.name.lower():
@ -150,6 +150,10 @@ def get_container(cfg: HomelabConfig, vmid: int = None, name: str = None) -> Con
return None
def get_containers_by_host(cfg: HomelabConfig, host: str) -> list[Container]:
return [c for c in cfg.containers if c.host == host]
def format_overview(cfg: HomelabConfig) -> str:
lines = ["# Homelab Infrastructure (from homelab.conf)\n"]

View file

@ -5,11 +5,7 @@ import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
PROXMOX_HOSTS = {
"pve-hetzner": "100.88.230.59",
"pve1": "100.122.56.60",
"pve3": "100.109.101.12",
}
PROXMOX_HOSTS = {} # Populated from homelab.conf at runtime via config.py
class ProxmoxClient: