ich versuch’s noch mal auf Deutsch… Ich möchte den Ladestrom begrenzen, vornehmlich bei kalten Temperaturen. Dazu bietet sich ja die Einstellung im DVCC an, als Objekt /Settings/SystemSetup/MaxChargeCurrent (Modbus Register 2705). Etwas blöd ist allerdings, dass das nicht die DC-Last berücksichtigt, die bei mir veränderlich ist, weil noch ein WR drauf hängt. Es ergibt sich also
hallo,
die bms-daten kannst du nicht aendern, da die staendig vom bms gesetzt werden!
die dvcc-einstellungen zu aendern ist auch kein problem. die daten werden wohl nur einmal am tag gespeichert. auf jeden fall wird nicht jede aenderung gespeichert.
ich konnte naemlich keine datei finden, die so oft geschrieben wird.
Warum musst Du den MaxChargeCurrent im Sekundentakt neu schreiben? Welchen Nutzen soll das bringen? IMO reicht es, falls man es überhaupt nötig findet (ich tu’s nicht, weil mein Akku warm steht), hier einfach zwischen Sommer- und Winterbetrieb zu unterscheiden, und da reichen dann zwei Schreibvorgänge binnen eines Jahres.
Ja, Flash-Speicher haben Grenzen bei der Anzahl von Schreibvorgängen, aber auch da gibt es Unterschiede zwischen Herstellern/Produkten, mit Angaben von 10.000 bis 100.000. Aber auch die 100.000 wirst Du bei einem Schreibvorgang pro Sekunde recht schnell erreichen.
@d_ferdi es wird eine Stelle im Venus Code geben, wo die CAN Daten des BMS verarbeitet werden. Wenn das keine Binärdatei ist, kann man da eingreifen. Ich habe auch schon das Schreiben des Ladespannungs-Sollwertes vom Multi auskommentieren müssen, weil der mir in meinem Setup pauschal die Lader disabled.
Das mit der Betrachtung der Speicherzeitpunkte der Dateien ist ein interessanter Ansatz. Hast du eine Idee, in welcher Datei die DVCC Settings gespeichert werden?
@TomBerger den Grund für die Änderung im Sekundentakt hatte ich ja oben dargelegt. Das MaxChargeCurrent berücksichtigt zwar den Strom, den der Multi sich nimmt, aber nicht den Strom, der in die DC-Last geht.
Es muss ja Strom der Lader geregelt werden. Wenn ich sage in den Akku sollen nur 50A gehen, und der Multi nimmt sich 20A, dann werden die Lader auf 70A geregelt. Wenn aber mein Lumetree WR, der als DC-Last in Erscheinung tritt, auch 20A nimmt, bleiben für den Akku nur noch 30A über, obwohl ich 50A eingestellt habe.
Das ist blöd gemacht, und weil ich den Setpoint des Lumentree im 1-Sekundentakt vorgebe, muss ich auch das MaxChargeCurrent im gleichen Takt vorgeben, wenn es Sinn machen soll.
Aber wenn ich da drüber nachdenke, wäre es eigentlich besser, im Venus Code die Stelle zu suchen, wo der Strom des Multi einbezogen wird, und da noch den DC-Load Strom mit beizuschreiben…
hallo,
schau mal unter /data/conf nach, da gibt es eine datei mit einstellungen.
ansonsten kannst du dir auch mit ls -lR /data|less eine fileliste anzeigen lassen. mit ls -lrtR wird die auch nach datum sortiert, allerdings nur verzeichnisweise!
in einem ess werden die charger nie deaktiviert, sondern maximal der ladestrom auf 0 gesetzt!
uebrigends soll es moeglich sein, dc-lasten ueber einen smartshunt so ins system einzubinden, dass der strom bei der regelung beruecksichtigt wird. probiert habe ich das aber noch nicht.
in fact werden sie vom DVCC auf eine Lade-Sollspannung von 0V gesetzt (die kommt vom Multi, k.A. warum der dazu kommt), was aber auf’s Gleiche rausläuft Deswegen musste das weg.
I have a habit to only modulate parameters available in the Node-Red nodes provided by Victron. I also fear hitting the max flash write cycles and yes my fingers itch from time to time but years of experience learned me hard lessons.
I don’t have Venus Large installed, so I access values via MQTT or Mobus. There are they all available, so I don’t know…
I wonder why the charge current control isn’t done preferably based on the value measued by SmartShunt or BMS, and only if those are not available using the result of this calculated sums and diffs… But that’s the way it is…
I guess in most systems charge current is a sum of the prefered battery charging current plus DC loads plus AC loads minus DC/DC plus/minus etc… I just went with the venusOS a matter of not reinventing hot water as we say in Belgium. It covers most needs and you can always program some extra’s.
Deswegen musste das weg.
