Lokales Energiemanagement: Integration von PV-Wechselrichtern und Batteriespeichern über Modbus TCP
Teil 5 von 5 der Reihe Home Assistant ohne Cloud
Inhalt
- Lokales Energiemanagement: Integration von PV-Wechselrichtern und Batteriespeichern über Modbus TCP
- 1. Hochfrequente Telemetrie über Modbus TCP und SunSpec-Registerkarten
- 2. Automatisierung der Überschussverwertung: Dynamische Lastregelung
- 3. Stabilität der Regelkreise sicherstellen
- Zusammenfassung
- Quellen
Lokales Energiemanagement: Integration von PV-Wechselrichtern und Batteriespeichern über Modbus TCP
Moderne Haus- und Unternehmens-Mikronetze erfordern eine verzögerungsfreie Energieverteilung, um den Eigenverbrauch zu maximieren und Einspeiseverluste zu minimieren. Der Rückgriff auf cloudbasierte Hersteller-APIs für Photovoltaik-Wechselrichter und Batteriespeichersysteme verursacht unerwünschte Latenzen, API-Limitierungen und eine externe Netzwerkabhängigkeit. Ein robustes lokales Energiemanagementsystem (LEMS) erfordert die direkte Abfrage von Telemetriedaten im lokalen Netzwerk über Modbus TCP oder SunSpec. Reaktionszeiten unter einer Sekunde ermöglichen die präzise Lenkung von PV-Überschüssen in die Warmwasserbereitung oder in Ladeinfrastrukturen für Elektrofahrzeuge.
1. Hochfrequente Telemetrie über Modbus TCP und SunSpec-Registerkarten
Das direkte lokale Polling von Hardware-Wechselrichtern (wie Fronius Symo oder Hybrid-Geräten von Deye) und bidirektionalen Smart Metern eliminiert Einschränkungen durch Cloud-Abfragen. Durch das Auslesen standardisierter Holding Register über Port 502 kann eine Automatisierungszentrale die aktuelle Erzeugungsleistung, den Batterieladestand (SoC) und den Netzaustausch in Intervallen von unter einer Sekunde erfassen.
- Deterministische Abfragezyklen: Das Auslesen von Leistungsregistern über Modbus TCP liefert rohe 16-Bit- oder 32-Bit-Ganzzahlwerte ohne JSON-Parsing-Aufwand oder TLS-Handshake-Verzögerungen.
- SunSpec-Kompatibilität: Standardisierte SunSpec-Registerblöcke (wie Model 101 oder Model 103) ermöglichen eine einheitliche Integrationslogik über verschiedene Wechselrichterhersteller hinweg, ohne Low-Level-Registeradressen neu schreiben zu müssen.
2. Automatisierung der Überschussverwertung: Dynamische Lastregelung
Sobald die Netzeinspeisung lokal berechnet wurde, kann überschüssige Energie dynamisch in thermische oder chemische Speicher geleitet werden, bevor Einspeisebegrenzer greifen.
- Proportionale Warmwasserbereitung: Die Steuerung von Heizstäben über Thyristor-Leistungsregler oder intelligente Relais erlaubt eine stufenlose Anpassung der Heizleistung an den exakt verfügbaren PV-Überschuss.
- Dynamische E-Auto-Ladesteuerung: Die Anbindung von OCPP-kompatiblen oder Modbus-gesteuerten Wallboxen ermöglicht eine dynamische Anpassung des Ladestroms zwischen 6 A und 16 A pro Phase, um Produktionsspitzen ohne Netzbezug vollständig aufzunehmen.
# Beispiel: Home Assistant Modbus TCP Sensor-Konfiguration für Wechselrichter
modbus:
- name: "pv_inverter_local"
type: tcp
host: 192.168.10.150
port: 502
sensors:
- name: "Inverter Active Power"
slave: 1
address: 40083
input_type: holding
data_type: int16
unit_of_measurement: "W"
device_class: power
state_class: measurement
scale: 103. Stabilität der Regelkreise sicherstellen
Die Implementierung schneller Überschussregelungen verlangt eine sorgfältige Hysterese-Planung. Der Einsatz von gleitenden Mittelwerten und Totzonen (Deadbands) verhindert ein ständiges Takten mechanischer Relais oder Wallbox-Schaltschütze bei wechselnder Bewölkung.
Zusammenfassung
Lokales Energiemanagement auf Basis von Modbus TCP garantiert eine vollständige Cloud-Unabhängigkeit, Telemetriedaten in Sekundenschnelle und maximalen PV-Eigenverbrauch. Die Kombination aus direkter Registerabfrage und intelligenter Lastmodulation für Warmwasser und E-Mobilität verwandelt eine klassische Photovoltaikanlage in ein autonomes, hochgradig effizientes Mikronetz.
Home Assistant ohne Cloud
- Zigbee2MQTT vs. ZHA: Aufbau eines ausfallsicheren Mesh-Netzwerks in Home Assistant
- ESPHome und ESP32 in der Praxis: Eigene Cloud-freie Umweltsensoren entwickeln
- Präsenzerkennung 2.0: mmWave-Radare (LD2410/LD2450) in der Lichtautomatisierung
- WireGuard & Tailscale DMZ: Sicherer externer Zugriff auf Home Assistant und eigene Server
- Lokales Energiemanagement: Integration von PV-Wechselrichtern und Batteriespeichern über Modbus TCP
Passend dazu
2 Kommentare
Der Hinweis auf SunSpec statt herstellereigener Registerkarten ist der Grund, warum sich so ein Aufbau später überhaupt auf ein zweites Gerät übertragen lässt.
Hält das in der Praxis über Hersteller hinweg? Bei uns stehen ein Fronius und ein hybrider Deye nebeneinander, und die Adressen aus dem einen Beispiel passen beim anderen nicht.
Es hält für die Modelle, die ein Gerät tatsächlich ausweist — die Falle liegt eine Stufe davor.
SunSpec-Geräte tragen eine Kette von Modellblöcken, und deren Startadresse ist nicht fest, sondern wird über einen Suchlauf ab einer Basisadresse (typisch 40000) ermittelt: Kennung lesen, Modell-ID und Länge auswerten, weiterspringen. Wer stattdessen die Adresse aus dem Beispiel eines anderen Herstellers übernimmt, liest verlässlich die falsche Zelle — und bekommt trotzdem eine Zahl zurück, was den Fehler so langlebig macht.
Der zweite Teil ist der Skalierungsfaktor. Leistung steht als Ganzzahl, der zugehörige Exponent in einem eigenen Register; im Beispiel des Artikels erledigt das
scale: 10. Ein vergessener Faktor verschiebt das Ergebnis um Zehnerpotenzen, und weil Photovoltaik-Leistungen ohnehin über mehrere Grössenordnungen laufen, fällt das nicht sofort auf. Beide Punkte zusammen — Modellsuche statt fester Adresse, Faktor aus dem Register statt aus dem Beispiel — sind das, was aus SunSpec die versprochene Einheitlichkeit macht.