[[Uebersicht|← Zurück zur Homepage]] # Node-RED Energiemanagement – Konzept ## Ziel Intelligente Ladesteuerung der Marstek Venus 3 Speicher unter Berücksichtigung von PV-Ertrag, Solcast-Forecast und Tibber-Preisen. Das CT002 übernimmt die Echtzeit-Regelung (Nulleinspeisung). Node-RED berechnet dynamisches Ladeziel und Ladeleistung und setzt diese über die HA-API. --- ## Hardware | Komponente | Details | |---|---| | Wechselrichter | Hoymiles (BKW ~2400 Wp) | | DTU | OpenDTU | | Speicher | 3x Marstek Venus 3 (je 13 kWh = 39 kWh gesamt) | | Speicherregler | Marstek CT002 | | Stromzähler | Inexogy (Smart Meter) | | Stromtarif | Tibber (dynamisch) | | Node-RED | LXC 101 auf Proxmox pve, IP 192.168.2.172, Port 1880 | | Home Assistant | VM haproxmox, IP 192.168.x.x, Port 8123 | | SQLite DB | /data/energiemanagement.db (im LXC 101) | --- ## Systemparameter | Parameter | Wert | |---|---| | Speicherkapazität gesamt | 39 kWh (3 x 13 kWh) | | Max. Ladeleistung je Speicher | 2.000 W | | Ziel-SOC (Tag) | 100 % | | Ziel-SOC (Nacht) | 80 % | | Mindest-SOC | 12 % | | Nacht-Definition | 21:00–06:00 Uhr | | Laden bei Tibber-Level | CHEAP + VERY_CHEAP | | PV aktiv Schwelle | > 50 W (HA-Sensor, kein MQTT) | --- ## Aufgabenteilung | Komponente | Aufgabe | |---|---| | **CT002** | Echtzeit-Regelung: Nulleinspeisung, Laden/Entladen nach Tibber | | **Node-RED** | Berechnet Ladeziel + Ladeleistung → setzt per HA-API alle 5 Minuten | | **SQLite** | Logging aller Messwerte und Entscheidungen | Node-RED greift **nicht** in die Echtzeit-Regelung ein. Kein direkter Modbus-Zugriff — Port 502 wird von der HA Marstek-Integration belegt. --- ## Entscheidungslogik Der Flow läuft alle 5 Minuten. Je nach Situation wird eine von fünf Entscheidungen getroffen: | Priorität | Entscheidung | Bedingung | |---|---|---| | 1 | **LADEN_NOTFALL** | SOC-Durchschnitt ≤ 12 %: sofort mit voller Leistung laden | | 2 | **PV_LADEN** | PV liefert > 50 W: Ladeziel = 100 %, Leistung = PV/3 je Batterie | | 3 | **LADEN** | Tibber CHEAP/VERY_CHEAP und SOC < Ladeziel: mit 2000 W je Batterie laden | | 4 | **LADEN_VORSORGLICH** | Tibber wird in 1–4 Stunden günstig: schon vorladen | | 5 | **NICHTS** | Alles gut, CT002 regelt weiter | --- ## Programmablauf (vereinfacht) 1. **PV-Leistung lesen** — Node-RED liest `sensor.opendtu_d71ef0_ac_power` direkt aus HA (kein MQTT) 2. **Daten von Home Assistant holen** — Tibber-Preise, Solcast-Forecast, SOC aller 3 Batterien 3. **Restverbrauch berechnen** — Lastprofil (stündliche Durchschnittswerte) bis 21:00 bzw. 06:00 Uhr 4. **PV-Netto berechnen** — Erwartete PV minus Restverbrauch = was die PV noch in die Batterien laden kann 5. **Ladeziel berechnen** — Batterien nur so weit laden, dass PV-Anteil noch reinpasst. Nachts max. 80 % 6. **Entscheidung treffen** — Nach Prioritätenliste (siehe oben) 7. **Steuerung ausführen** — Per HA-API Ladeziel und Ladeleistung für alle 3 Batterien setzen 8. **Logging** — Alle Messwerte und Entscheidung in SQLite speichern --- ## Forecast-Logik je Tageszeit | Uhrzeit | Forecast "heute" | Grund | |---|---|---| | 06:00–23:59 | `prognose_verbleibende_leistung_heute` | laufender Tag | | 00:00–05:59 | `prognose_heute` (Tagesgesamt) | Tag noch nicht begonnen | --- ## Lastprofil (Hausverbrauch, geglättet) ```javascript const lastprofil = [ 185, 182, 180, 178, 280, 380, 420, 480, // 00-07 Uhr 520, 580, 630, 690, 710, 700, 580, 500, // 08-15 Uhr 510, 730, 720, 650, 500, 380, 280, 200 // 16-23 Uhr ]; ``` Tagesverbrauch ca. 8–9 kWh. Basiert auf Inexogy-Lastprofil (geglättet). Später mit echten Daten feinjustieren. --- ## Versionshistorie | Version | Datum | Änderung | |---|---|---| | v11 | 11.06.2026 | max_soc_ist_b1/2/3 entfernt (Entity liefert immer 0), SOC B1 Entity korrigiert | | v10 | 10.06.2026 | version + max_soc_ist im Log (via Claude Code) | | v9 | 07.06.2026 | toLowerCase() für Tibber-Level, Notify korrigiert, Lokalzeit | | v5 | – | Dynamische Ladeleistung: PV_LADEN = pv_aktuell/3, Netzladen = 2000 W | | v4 | – | PV_LADEN Entscheidung + pv_timestamp für Nacht-Erkennung | | v3 | – | Hausverbrauch und ENTLADEN-Logik entfernt (CT002 regelt selbst) | | v2 | – | Modbus durch HA-API ersetzt (Port 502 belegt) | | v1 | – | Erster Entwurf mit Modbus TCP direkt | Aktuelle Version: **v11** --- ## Offene Punkte - [ ] TESTMODUS deaktivieren (auf `false` setzen) — Flow läuft stabil seit mehreren Tagen - [x] Tibber-Level Mapping geklärt — HA liefert lowercase (cheap/very_cheap) ✓ - [x] Logging auswertbar — Entscheidungen plausibel ✓ - [ ] Lastprofil mit echten Inexogy-Daten feinjustieren --- [[Hinweise/Impressum|Impressum]] | [[Hinweise/Datenschutzerklärung|Datenschutz]]