Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- hardware:batteries:marstek-b2500d [2025/09/18 21:10] – tge
+++ hardware:batteries:marstek-b2500d [2025/09/27 21:51] (aktuell) – gelöscht tge
@@ Zeile 1: / Zeile 1: @@
-Der Marstek B2500D ist ein beliebter PV Speicher, der insbesondere aus Volkszählersicht den großen Vorteil hat, per MQTT recht einfach abfragbar und steuerbar zu sein.
-Die im Folgenden beschriebene Installation läuft bei mir seit einigen Wochen problemlos und erzielt eine verbleibende Einspeisung von 20-30Wh pro Tag (unter der Annahme, der Akku ist noch nicht voll).
-Es findet nur ein B2500D Verwendung - es können auch mehrere Geräte gekoppelt werden, dies wurde aber hier nicht berücksichtigt, sollte aber auch lösbar sein.
-==== Umgebung ====
-Es wird Folgendes benötigt:
-  * ein B2500D, zwischen Solarmodule und Wechselrichter geschaltet
-  * ein permanent laufender Computer (ein Raspberry Pi reicht völlig aus), auf diesem
-    * ein MQTT Broker
-    * eine hame-relay Instanz (s.u.)
-    * ein vzlogger, der u.a. per MQTT die Metriken vom Speicher abfragt
-  * Sensoren, die den Gesamtenergiefluß im Haus messen und als VZ channel verfügbar machen (ggf auch als errechneter channel in der VZ middleware)
-==== Architektur ====
-Normalerweise erfolgt die Steuerung der B2500D mittels einer App indirekt über eine "in der Cloud" befindliche MQTT Instanz - das heisst, der Speicher agiert als MQTT subscriber (wartend auf Befehle) und publisher (Antworten, so auch komplette Statuswerte inkl aller interessanten Metriken). Diese Kommandos sendet die App und empfängt die Antworten zur Anzeige im GUI.
-Die Software hame-relay erlaubt es nun, einen lokalen MQTT Broker "dazwischen" zu schalten, entweder im
-  * Mode 1 - der Speicher wird umkonfiguriert, so dass es nur noch mit dem lokalen Broker spricht. Das hame-relay repliziert Pakete bei Bedarf zur Cloud-MQTT-Instanz. Diese Variante läuft erheblich stabiler (traffic lokal)
-  * Mode 2 - das hame-relay agiert parallel zur App als Publisher und Subscriber bei der Cloud-MQTT-Instanz und empfängt dann ebenfalls alle Antwortpakete und kann Kommandos einspeisen. Funktioniert grundsätzlich auch - gut, um das Ganze erstmal auszuprobieren, ohne am Speicher was ändern zu müssen.
-Der große Vorteil: Die App funktioniert immer noch.
-Das Ganze wird nun in VZ integriert, indem der vzlogger ein Meter periodisch ausführt, was per "exec" ein Script mit mosquitto_sub und pub ausführt, damit ein Kommando "status" absetzt und die dazu passende Antwort auswertet. Diese wiederum enthält alle verfügbaren Metriken, die dann wie üblich als VZ channel zur middleware gesendet werden. Damit bekommen wir schon mal eine schöne graphische Darstellung.
-Dazu kommt ein weiteres Script, welches als OS Service läuft, sich ebenfalls beim lokalen MQTT Broker als subscriber anmeldet und ebenfalls die vom vzlogger erbetenen status Antworten empfängt. Nach Empfang werden diese analysiert und die VZ middleware abgefragt, um den aktuellen Gesamtenergiefluß zu erhalten.
-Der Gesamtenergiefluß entspricht dem aktuellen Bedarf (bzw bei negativen Werten Einspeisung), was zusammen mit der aktuellen Energieausgabeleistung des Speichers (oder des Wechselrichters) ein Delta ergibt, was wir dann nutzen, um die Ausgabeleistung des Speichers nach oben oder unten zu regeln (oder ggf ganz abzuschalten).
-==== MQTT ====
-Als lokale MQTT Instanz kann mosquitto genutzt werden oder was auch immer sonst. Ein user/password wird benötigt, zumindestens in hame-relay mode 1 wird dies benötigt um den Speicher umzukonfigurieren.
-==== hame-relay ====
-Diese Komponente ist sehr gut dokumentiert [[https://github.com/tomquist/hame-relay|hier]]. In meiner Umgebung läuft hame-relay innerhalb einer Docker-Instanz - überraschend leichtgewichtig, ein Raspi kommt damit locker zurecht. In einem Config-File müssen ein paar wenige Parameter eingetragen werden, dann die docker Instanz einfach starten und als OS service konfigurieren (muss in mode 2 immer laufen - in mode 1 eigentlich entbehrlich solange die App nicht genutzt werden soll).
-Um mode 1 zu verwenden, muss der B2500D umkonfiguriert werden (um den lokalen MQTT Broker zu nutzen). Auf der o.g. hame-relay Seite ist ein Config-Tool verlinkt, welches diese Aufgabe erfüllt. Dies war in meinem Fall etwas hakelig, aber nur weil:
-  * die Kommunikation mit dem Speicher läuft über BLE websockets, was nicht alle browser unterstützen
-  * die Hardware (ältere Modelle können dies u.U. nicht, evtl auch das OS) muss dies unterstützen, kann auch ein Tablet oder Mobiltel sein - es wird nur ein Browser benötigt
-Mit einem aktuellen OS/Browser lief das dann völlig problemlos.
-==== vzlogger ====
-Keine besonderen Herausforderungen. Meine Beispiel-Config:
-''{
-  "enabled": true,
-  "skip": false,
-  "interval": 30,
-  "protocol": "exec",
-  "command": "/opt/vzlogger/bin/b2500d_mqtt.pl",
-  "format": "$i : $v",
-  "channels":
-  [
-    {
-     "uuid": "...",
-     "api": "volkszaehler",
-     "middleware": "http://.../middleware.php",
-     "identifier": "w1"
-    },
-...
-''
-Die Metrik w1 beispielsweise entspricht der am PV Eingang 1 anliegenden Leistung der Solarmodule.
-Das MQTT Protokoll des B2500D und die Metriken sind [[https://eu.hamedata.com/ems/mqtt/index.html|hier]] beschrieben.
-Das o.g. Script ist [[https://github.com/tge12/b2500-ctrl|hier]] (zusammen mit dem u.g. Steuerscript).
-==== Steuerscript ====
-Wie oben beschrieben sorgt nun ein weiteres Script für das Regeln der Ausgabeleistung des Speichers je nach Bedarf. Dieses Script ist ebenfalls [[https://github.com/tge12/b2500-ctrl|hier]] zu finden.
-Die nötigen Config-Parameter befinden sich direkt im Script:
-  * Zugang lokaler MQTT Broker mit MAC des Speichers (für MQTT Topic)
-  * Zugang VZ Middleware
-  * welcher VZ Channel
-  * Steuerparameter wie Ein/Ausschaltgrenzwerte, Hysterese, min/max Leistung des Speichers
-Dieses Script muss kontinuierlich laufen und arbeitet wie oben beschrieben. Es wird versucht, die Ausgangsleistung des PV Speichers so zu regeln, dass ein Gesamtenergiefluß im Haus von Null erreicht wird. Da der B2500D mit der derzeitigen Firmware nicht erlaubt, Output < 40W einzustellen, wird unter einem Grenzwert der Output ganz abgeschaltet (und bei Bedarf wieder ein).
-All dies wird über genau ein Zeitinterval 00:00-23:59 geregelt, welches kontinuierlich verändert wird (bzw dessen Ausgangsleistung).
-Versuche, den Auto-Modus zu verwenden, waren einigermaßen erfolgreich, aber recht instabil. Die derzeitige Lösung hat den Vorteil, die Leistungsberechnung selbst unter Kontrolle zu haben und funktioniert wie gesagt sehr gut und stabil.
-==== Praxis ====
-Bei mir sieht das nun (Beispiel heute, 18.Sept, vormittags sehr bewölkt, ab mittags sonnig) so aus:
-{{:hardware:batteries:screenshot_2025-09-18_20-53-57.png?800|}}
-Am Vortag auch bewölkt, daher morgens Speicher leer (10%). Hellblau der Gesamtenergiefluss, gelb die Leistung des Wechselrichters, hellgelb die beiden PV Eingänge.
-==== Tips und Tricks ====
-Ich habe eigentlich einen Hoymiles Wechselrichter - wenn man beim Speicher diesen korrekt konfiguriert, erlaubt der Speicher merkwürdigerweise nur eine Min-Ausgangleistung von 80W (sowohl im Auto-Modus als auch zeitgesteuert).
-Wenn man statt dessen einen Marstek WR mit gleicher Max-Leistung einstellt, ist eine Minimalleistung von 40W möglich.
-Da z.B. nachts (nur Kühlschrank periodisch) meist nur in etwa 10-15W benötigt werden, schaltet in diesem Fall das Steuerscript die Leistungsabgabe komplett ab.