Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- hardware:batteries:marstek-b2500d [2025/09/18 20:18] – angelegt 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
-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).