AC/DC Speicherlösung mit Victron MPPT, Pylontech, Hoymiles, Huawei und openDTU-OnBattery

@CaCu15 Wo ich dir recht geben muss, ist dass der Dauerverbrauch im Idle den Wehselrichter und vor allem das Netzteil aus dem Akku ziehen, wenn man sie nicht komplett trennt, nicht zu unterschätzen ist. Als ich heute morgen aufgestanden bin und nach dem Speicher gesehen habe, war die die rote LED vom BMS für over discharge protection an, obwohl ich nichts über die Nacht eingespeist hatte. Die Batterie war also abends schon leer genug, so dass der Idle Verbrauch allein bis zur BMS Grenze entladen hat in nur einer Nacht.

Das sollte eigentlich nicht passieren, ich werde wohl doch eine Art Erhaltungsladungs Logik einbauen müssen, die wenn es mehrere Tage schlecht Wetter mit kaum Überschuss gibt, trotzdem Abends auf eine Mindestspannung/SOC geladen wird. Ist nicht elegant aber habe keine bessere Idee.

@cacu15 Hallo cacu15, ich möchte einen Ansatz ähnlich dem von Dir beschriebenen bauen. Magst du mir bitte deinen Flow übermitteln. Danke.

Veröffentlicht von: @erwano

↑

@cacu15 Hallo cacu15, ich möchte einen Ansatz ähnlich dem von Dir beschriebenen bauen. Magst du mir bitte deinen Flow übermitteln. Danke.

Hi  @erwano,

kein Problem. Anbei ein Export meiner Flows:

1) akku_flow.json ist die eigentliche Steuerung des Ladevorgangs und die Zustandsverwaltung. Dazu folgende Erklärung:

• Ich entwickle da aktuell nicht mehr weiter, weil ich die Logik gerne in ESPHome haben will. Dort kann ich sie unabhängig von anderen Server-Prozessen (MQTT, Node Red) etc. bauen und so eine größere Robustheit erreichen. Außerdem hat Malte ja jetzt eine Ladelogik in OpenDTU onBattery integriert...
• Ich schalte mein Huwei AC seitig über ein Shelly an und aus. Slot Detect nutze ich NICHT. Siehe dazu die config der MQTT Topics unter config.mqtt. - alle die Topics, die mit huawei_ac_switch_ beginnen sind dafür relevant. Über das Shelly laufen sowohl das Netzteil als auch der Inverter, den ich so ggf. auch AC seitig ferngesteuert trennen kann.
• Der ganze FLow ist konfigurierbar über einen config-node. Darin ist im Attribut "flow.config" eine größere JSON Struktur enthalten, in dem man viele Parameter konfigurieren kann, z.B. MQTT Topics, Schwellwerte für Import/Export etc.
• Der FLow kennt verschiedene Modi:
  • DISABLED - Damit kann der Flow deaktiviert werden. Aus diesem Modus kommt man nur über eine manuelle Umschaltung heraus.
  • INACTIVE - Keiner der Modi ist aktiv, Automatische Umschaltung nach CHARGING oder DISCHARGING erfolgt je nach Einspeisung/Bezug und SoC des Akkus
  • CHARGING - Ladung des Akkus - Ladeleistung wird abhängig von PV-Überschuss gesteuert. Ladespannung entsprechend Konfig config.charge.absorbtion_voltage. Beim Start des Modus wird das Huawei eingeschaltet. Man kann die minimale und maximale Ladeleistung vorgeben über config.charge.max_current bzw.  config.charge.min_current. Wenn eine Lade-Stromstärke UNTER config.charge.min_current errechnet wird, dann wird die Ladeleistung auf 0 reduziert. Außerdem wird die Ladeleistung nach oben begrenzt durch die vom Akku gemeldete max. Ladeleistung (korrigiert um einen konfigurierbaren Faktor, um da einen Sicherheitspuffer einbauen zu können). Bei der Berechnung der Ladeleistung wird ein "Puffer" von config.charge.export_buffer Watt gelassen, um bei Schwankungen des Überschusses nicht so leicht in den Netzbezug zu kommen.
  • ABSORBING / ABSORBING_WAIT - Absorptionsphase nach Abschluss des Ladens. Wenn im Modus CHARGING die Ladespannung erreict wird UND config.charge.absorbtion_repeat_count >0 ist, dann wird eine Absorptionsphase gestartet, die config.charge.absorbtion_duration Minuten andauert. Danach eine Pause von config.charge.absorbtion_repeat_after Minuten. Danach wiederholt sich das ganze entsprechend des Counters. Wenn man keine Absorption will, dann einfach den Counter auf 0 setzen.
  • DISCHARGING - Einspeisung aus dem Akku - Hier wird nur der Inverter eingeschaltet und der Dynamic Power Limiter aktiviert sowie das Huawei ausgeschaltet. Den Rest macht ja OpenDTU onBattery.
  • Umschaltung zwischen den Modi "CHARGING" und "DISCHARGING" erfolgt, wenn Einspeisung/Bezug für eine Dauer von config.state_control.import_stop_duration bzw. config.state_control.export_stop_duration Sekunden über den in  config.state_control.import_threshold bzw. config.state_control.export_threshold Grenzwerten liegt. Damit soll ein wildes Herumspringen zwischen den Modi verhindert werden.
  • Modus "FLoating" ist aktuell nicht umgesetzt
• Die aktuellen Werte vom Stromzaehler erhält der Flow aus dem 2. hier angehängten Flow. Das kann man aber auch einfach gegen ein anderes MQTT Topic o.ä. austauschen Wichtig ist nur, dass in der Payload der Wert von Einspeisung/Bezug in Watt enthalten ist ( <0 für Bezug, >0 für Einspeisung)
• Was noch fehlt:
  • aktuell KEINE Auswertung der ALARM Meldungen von OpenDTU, z.B.
    • keine "Zwangsladung" bei Undervoltage (wäre wohl ein spezieller CHARGE Modus)
    • kein Abbruch bei zu hoher / niedriger Temperatur  (das wäre aber eine ziemlich einfache Erweiterung)
    • kein FLOATING implementiert
• Am Schluss des Flows wird per MQTT Discovery ein MQTT Select Element in Home Assistant registiert, um dort den Modus manuell umschalten zu können.

2) stromzaehler.json ist die Abfrage meines IR-Lesekopfes auf dem Stromzaehler. Dieser Flow hat eine Schnittstelle zur Akkusteuerung, über die die Akkusteuerung den aktuellen Wert von Stromexport/-import (Einspeisung/Bezug) bekommt, um darüber die Ladeleistung zu steuern.
Mein IR-Lesekopf wird über ESPHome ausgelesen.  Damit habe ich die Möglichkeit, jede Änderung ohne Polling über eine EventSource Schnittstelle zu bekommen. Das will ich aber nur an einer Schnittstelle haben, um den ESPHome nicht zu stark zu belasten.
Außerdem ist da das Schreiben von einigen Daten in meine InfluxDB enthalten - das kannst Du aber für Deinen Fall ignorieren, denke ich.

P.S. das Credential im Authorization Header der EventSource ist nicht das korrekte 😉

Frage an die Huawei Netzteil User. Ich habe mal wieder ein Problem bzw. vielleicht sogar mehrere. Seit heute morgen blinkt die orange warning LED an meinem Netzteil. Laut Anleitung signalisiert das Unterbrechung der CAN Kommunikation. Gleichzeitig leuchtet aber auch noch die untere rote LED durchgehend, das Manual sagt das steht entweder für Output Overvoltage Protection, was Blödsinn ist, ich habe das Netzteil komplette vom System getrennt, und das Multimeter zeigt mir nie mehr als 52,5V Volt an, oder es steht für internen Fehler sprich Hardware Defekt. 

Bei mir verhält sich die untere rote LED aber so, das sie immer angeht sobald Slot Detect nicht verbunden ist und der Lüfter ausgeht. Wenn ich SD kurschließe geht sie sofort aus und bleibt das auch bis SD wieder offen ist. Deshalb wollte ich mich erkundigen wie sich die Status LEDs bei euch so verhalten, vor allem die rote LED. Ist die bei euch auch an oder aus abhängig vom SD, war sie jemals an bei euch?

Ich meine nämlich dass die rote LED bei mir auch schon öfter geleuchtet hat, während das System aber sauber gearbeitet hat, wie gesagt bei mir war bis heute morgen alles noch funktionstüchtig und ich frage mich jetzt vor allem ob mein Netzteil ein Defekt hat oder nicht, es ist eben gebraucht von Kleinanzeigen da kann so was ja leider schon mal passieren.

Dass die Orangene Warning LED blinkt hatte ich glaub noch nicht bis jetzt, das ist dann wohl mein zweites Problem, die OpenDTU Konsole sagt mir "Error sending message", heißt es ist nicht nur das Firmware bedingte abfragen aktueller Werte außer Funktion was ich ja schon kenne sondern es ist auch nicht mehr möglich Befehle für neue Soll Ausgangsspannungen und Ströme per CAN ans Netzteil zu senden.

@cacu15 Hallo cacu15, erst einmal herzlichen Dank für die tolle und ausführliche Dokumentation. Die Länge und der Detailgrad deiner Nachricht haben mich erst mal überfordert. Ich habs nun mehrfach überflogen und muss ehrlich gestehen, dass ich nur ungefähr die Hälfte verstanden habe. Ich werde die im Archiv enthaltenen Daten mal importieren und peu à peu konsumieren.

Insbesondere die Fragestellung, was an Funktionalität weiterhin von OpenDtu-Onbattery genutzt wird und was quasi angeflanscht wird, erschließt sich mir noch nicht.

Ich strauchle aktuell erst mal an dem Thema, dass die Kommunikation mit dem Huawei, wie von vielen beklagt, nur lückenhaft funktioniert. Dies führt dann dazu, dass der Regelungskreislauf gestört wird und Soll-Werte nicht nachgeführt werden. Ich hoffe, dass es da bald Abhilfe gibt. So weit erst mal aus Bonn. Weiter gehts, wenn ich mich entsprechend eingefuchst habe.

Veröffentlicht von: @erwano

↑

Ich strauchle aktuell erst mal an dem Thema, dass die Kommunikation mit dem Huawei, wie von vielen beklagt, nur lückenhaft funktioniert.

Wenn du magst kannst du den Branch hier bauen: https://github.com/MalteSchm/OpenDTU-OnBattery/tree/huawei_interval_fix

Oder die FW von hier installieren: https://github.com/helgeerbe/OpenDTU-OnBattery/issues/387

Wäre gut dazu mal Feedback zu bekommen.

Im Moment blockiert mich noch dieses Problem https://github.com/helgeerbe/OpenDTU-OnBattery/issues/381 da es Langzeittests braucht. Das muss erst mal erledigt sein bevor das Netzteil dran kommt

Veröffentlicht von: @maltes

↑

Wäre gut dazu mal Feedback zu bekommen.

Hi malte, eigentlich schulde ich dir hier ja noch Feedback .. . Bei mir gibt's aber grad ganz andere Probleme und ich bin froh, dass es aktuell überhaupt läuft, daher möchte ich das Setup grad ungern modifizieren... Ich melde mich beizeiten, kann aber noch nicht versprechen, wann genau. Sorry...  

Zum Thema Huawei Netzteil,

Ich habe beschlossen ein Ansatz zu verfolgen, der mir zuletzt in den Sinn kam und da dachte ich, ich teile meine Idee, vielleicht gibt es interessierte. Aufgrund mehreren Rückschlägen beim versuch dynamisch PV Überschuss zuverlässig übers Netzteil in den Akku zu laden habe ich eine Alternative zu dem Regler aus OpenDTU on Battery auf Linux Basis entwickelt. Mir ist gelungen das JoyIt MCP2515 CAN Modul mit einem Raspberry Pi GPIO zu verbinden und damit über die C Software von craigpeacock ( https://github.com/craigpeacock/Huawei_R4850G2_CAN), die vielleicht manche kennen, das Netzteil manuell zuverlässig anzusteuern. Es sollten prinzipiell aber alle Linux Computer mit CAN Schnittstelle Kompatibel sein. 

Ich habe mit Hilfe von diesem Code eine C++ Anwendung für den Raspi oder vergleichbare Systeme entwickelt, die per UDP Socket periodisch die aktuelle Last von einem Tasmota Volkszähler (ESP32 + IR Lesekopf am Stromzähler) empfängt und die Ausgangsleistung des Huawei Netzteils entsprechend nachregelt um den Stromzähler so gut es geht zum stehen zu bringen ohne dabei PV Überschuss zu Verschenken.

Ich bin gerade dabei das ganze in einem neuen Github Repository zu veröffentlichen. Es ist work in progress keine Frage, aber ich habe das System jetzt seit c.a. 5 Tagen recht erfolgreich am laufen. Ich verfolge die Regelabweichung intensiv und die Messdaten aus meinem Grafana Dashboard ergeben über 98% PV Eigennutzen über die letzten 4 sonnigen Tage, heißt ich bin guter Dinge und werde den Ansatz mit Sicherheit weiter verfolgen und optimieren. 

Würde mich natürlich auch freuen, wenn es Interessenten gibt oder gar Tester. Der Link auf Github ist folgender:

https://github.com/ele-dev/Huawei-PSU-Regulator

Ist wie gesagt noch ganz neu also, also bitte nicht über Bugs oder fehlende Doku wundern, ich beantworte gerne Fragen. 

Moin. Hat hier jemand Interesse an einer PCB für die Kommunikation mit dem Victron und dem Pylontech?

@maltes Hallo MalteS, anbei mein Feedback.  Mit der von Dir zur Verfügung gestellten neuen Version (b4cb988) klappt jetzt die Kommunikation an der ESP-Huawei-Schnittstelle nun einwandfrei. Der Huawei wird permanentt als verfügbar/erreichbar im Dashboard angezeigt und die Logs sehen auch prima aus. Lieben Dank dafür.

Die Funktion des Regelmechanismus konnte ich leider nicht testen, da am Nachmittag zunehmend Wolken über das Rheinland zogen ;-( 

@lukasvfl99 Sieht toll aus. Ich bin aber von der "AC-Lade-Fraktion" und habe demzufolge keinen Victron.  
@all: hat jemand Kenntnis, ob es sowas auch für die Kombi ESP, NRF, Huawei und Pylontech gibt? Da hätte ich großes Interesse.

@erwano Nach sowas habe ich auch schon gesucht, bisher aber nichts gefunden.

Vor allem der AC Ansatz hat glaube ich leider noch zu wenig Nutzer und deswegen gibt es nicht so viele Leute die speziell daran arbeiten, sowohl was bugs und neue features in der software betrifft, als auch das designen von PCBs.

@energy-geek Hallo, bei der Lektüre deines Beitrages musste ich an die Lösung von KlausI (BavarianSuperGuy) denken. Letztlich macht diese nichts anderes, aber mit m.E. kleinerem Aufwand. Die Lösung hatte ich im Einsatz und sie funktionierte für mich einwandfrei. Mich hat daran nur gestört, dass ich dann zusätzlich für die Steuerung meines HM-300 und eines Pylontech nochmals extra Hw/Sw betreiben muss. Das war letztlich der Grund für mich, mich mit der Onbattery auseinerander zu setzen. 
Schau dir gerne mal die Lösung an [ https://github.com/KlausLi/Esp-HuaweiR4850-Controller ], falls nicht schon bekannt und gibt mir/uns gerne Feedback, ob ich mit meiner Einschätzung falsch liege.

@energy-geek @erwano habt ihr einen Schaltplan plus Bezeichnung der Bauteile für mich? Dann würde ich mich Mal an eine PCB setzen.

Veröffentlicht von: @erwano

↑

@energy-geek Hallo, bei der Lektüre deines Beitrages musste ich an die Lösung von KlausI (BavarianSuperGuy) denken. Letztlich macht diese nichts anderes, aber mit m.E. kleinerem Aufwand.

Die Software von KlausLi hat nur einen ganz großen Fehler: sie ist Closed-Source.

Wenn er jetzt morgen keine Lust mehr hat evtl. auftretende Bugs zu fixen hast du keine Möglichkeit dir eine neue Version der Software zu compilieren.

Erweitern oder verbessern kannst du sie auch nicht.

Ich finde es gut dass @energy-geek seinen Sourcecode öffentlich zur Verfügung stellt.