Warum laden die SmartSolar Lader nicht?

Other languages Deutschsprachiger Bereich
,
1

ich habe eigentlich ein ganz einfaches Setup:

  • Multiplus II
  • SmartSolar MPPT Lader
  • Akku mit JK PB BMS
  • Raspi mit Venus als GX Device

Einstellungen etc sind

  • alle Geräte sind mit dem GX verbunden: SmartSolars per VE.direct, Multi per MK3 (also als VE.bus), das BMS per CAN
  • auf dem Multi ist der ESS Assistant aktiv mit external control (Leistungsvorgabe per Skript entsprechend Hausverbrauch laut Zähler).
    grafik
    grafik480×272 11.8 KB
  • DVCC ist enabled, Controlling BMS ist das JK BMS
    grafik
    grafik480×272 19.6 KB
  • das BMS überträgt seine Parameter und fordert entsprechend Ladespannung an
    grafik
    grafik480×272 12.2 KB

Problem: Trotzdem erhalten die SmartSolar MPPTs eine Ladespannungsanforderung von 0V und laden entsprechend den Akku nicht.

Das ist nur so, sobald/solange der MultiPlus eingeschaltet ist. Wird er ausgeschaltet, läuft alles wie es soll (nur nutzt mir das nix, weil ich ja den Multi brauche, um die Energie auch zu benutzen).

Auf dem Multi ist der Charger disabled, weil ja die MPPTs entsprechend der Anforderung des BMS laden sollen, und nicht der Multi aus dem Netz.

38102-grafik
38102-grafik632×496 88.2 KB

Es hatte schon mal jemand vermutet, dass es da dran läge, und ich hatte den Charger auf dem Multi enabled

grafik
grafik632×496 97.8 KB

aber das hatte nichts geändert - die SmartSolar Chargers laden trotzdem nicht. Sobald der Multi eingeschaltet wird, geht /Hub/ChargeVoltage auf 0 und das wird an die Charger weitergegeben.

Warum laden die Lader nicht? das ist ja eigentlich kein ungewöhnliches Setup!?

@M_Lange du wurdest mir wärmstens empfohlen - fällt dir was auf? Natürlich freue ich mich über Tipps von jedem/r der/die was dazu sagen kann!

danke & Grüsse!
Phil

ps. Firmware Multi: 2629552, Venus 3.41, 3.55, 3.65 überall gleich

2

Guten Morgen,

unter „Advanced“ In VE config darf nichts aktiviert sein. ?

Wenn du die Zusammenfassung des Assistenten noch zeigen könntest?

3

Wie läuft es denn, wenn du den ESS mode mal auf “Optimiert” stellst und das System mit den eigenen Algorithmus laufen lässt?

Beim “external control” kenne ich mich nicht aus, ggf. muss man da noch mehr Befehle permanent senden, damit es läuft.

4

danke euch schon mal!

@dennibu

38105-grafik
38105-grafik632×496 73.5 KB

38098-grafik
38098-grafik541×447 64.8 KB

@M_Lange ich hatte es mal ne Weile mit Optimiert laufen, das ändert aber nichts da dran, dass die Lader auf 0 gehen, sobald der Multi eingeschalltet ist. (eigentlich ändert es sowieso fast nix, wenn ich den ‘Netzsollwert’ (AcPowerSetpoint / Reg. 37) von aussen vorgebe? das geht ja bei Optimiert auch)

vielleicht noch zur Info: aktuell funktioniert das System, weil ich die Zeilen 1318/1319 (3.55) im dvcc.py auskommentiert habe:

grafik
grafik850×552 52.2 KB

aber das kann ja (eigentlich) nicht die Lösung sein.

5

dieser ‘Hack’ veranschaulicht auch gut das eigentliche Problem:

Sobald ein Multi im System ist, gibt dieser die Charge Voltage vor, aber die ist 0, weil sie ja eigentlich vom BMS kommen soll.

Ich meine hier liegt ein Fehler im System vor!?

Andererseits bin ich ja nicht der einzige, der Multi, VE.direct Charger, CAN BMS und ESS benutzt - warum geht es bei vielen anderen?? wobei es auch nicht bei allen geht - manche haben das gleiche Problem und auch meinen Hack benutzt…

6

mir ist grad noch was eingefallen:

ich habe keinen Teperatursensor am Multi angeschlossen (war nich dabei). Kann es sein, dass der Multi trotz STS denkt es wäre zu kalt zum Laden und deshalb self._multi.hub_voltage auf 0 steht?!

Kann mir jemand sagen, was das für ein Sensor ist?! vielleicht hab ich einen da und könnte den einfach mal testweise anklemmen. oder einfach einen Festwiderstand

andererseits würde dann die charge voltage vom BMS nicht übernommen… (Zeile 1322…)

7

Also den Temp-Sensor braucht man nicht, ist eigentlich für den Akku/Batterie vorgestehen..

ich denke einfach, dein Treiber ist nicht richtig installiert oder hat zu alt oder nicht kompatibel zum BMS

8

Moin Holger,

welchen Treiber meinst du? Alle benutzten ‘Treiber’ stecken im Venus, und das habe ich 3 Mal installiert von alt bis brandneu. Auch die Multi Firmware hatte ich damals upgedatet. ich erinnere nicht mehr, welche vorher drauf war, aber 552 ist nicht allzu alt und bei beiden Versionen war das Verhalten gleich.

Die Daten vom JK BMS kommen alle wie sie sollen. Das BMS ist ja auch nicht das Problem, sondern der Multi.

9

Offensichtlich kommen ja vom JK BMS falsche Werte … sonst würden sie weitergereicht.

Das was Du oben zeigst .. sind die MAX-Werte die übertragen werden.

Was zeigt denn der MP II für Werte an.. z.B. vom Akku? In der Console.

10

Naja, das BMS wir nicht offiziell unterstützt und wenn ich mich richtig an andere solcher Fragen erinnere, kann/muss man im den BMS doch auch noch Werte programmieren?

Also ich bin hier jedenfalls raus, wenn hier an Systemdateien von Venus OS Veränderungen vorgenommen werden (müssen).

11

Die Werte vom BMS sind
a) nicht falsch sondern so wie im BMS programmiert
b) werden korrekt weitergereicht (sobald ich dem Multi ‘den Mund verbiete’ und er sie nicht mit seiner 0 blockiert)
c) sind natürlich MAX-Werte (heissen ja auch …Limit), die ja nur erreicht werden können, wenn die PV mindestens soviel hergibt. Die Begrenzung auf diese Werte durch das DVCC funktioniert tadellos (sobald ich dem Multi ‘den Mund verbiete’…)

@M_Lange naja, ein Standard CAN BMS wird unterstützt, und es kommen ja alle Werte korrekt an und werden korrekt verarbeitet - solange der Multi nicht seine 0 drüber dominiert. Das BMS wurde ja auch in OffGridGarage auf Herz und Nieren auf das Zusammenspiel mit Venus getestet und für gut und kompatibel befunden.

Alle BMS Werte stehen sowohl in MQTT als auch in den dbus Werten richtig auf den richtigen Objekten! (MQTT ist ja auch nur ein ‘Spiegel’ der dbus Sachen)

Nicht wegen dem BMS muss der Hack gemacht werden, sondern wegen dem Multi bzw. weil /Hub/ChargeVoltagevom System nicht korrekt bedient wird.

–>> Sag mir, was ich an den Einstellungen ändern soll, damit der Hack überflüssig wird!

Guck dir den Code an: Sobald ein self._multi.active ist, ist charge_voltage nicht mehr Nonesondern der Wert von /Hub/ChargeVoltage- wer/was setzt die zu 0 oder setzt sie nicht?? Das BMS von sich aus jedenfalls nicht, das hat garkeinen direkten Zugriff auf die dbus Objekte. Auch die “offiziell unterstützten” nich.

12

ps. @M_Lange wenn dich das mit dem Hack stört, dann tu einfach so, als wäre er nicht gemacht, und ich muss dringend eine Lösung haben, damit die Charger laden… :wink:

13

grafik
grafik480×272 16.1 KB

grafik
grafik480×272 16.2 KB

grafik
grafik480×272 14.8 KB

alles wunderschön und korrekt. oder fehlt dir was?

Die einzigen Werte, die da vom Akku angezeigt werden, sind ja nun Spannung und Temperatur. Die passen. Die Spannung kommen übrigens per SVS vom SmartShunt, nur die Akkutemperatur kommt vom BMS.

Wenn du willst, lasse ich ihn auch mal wechselrichten, damit du siehst, dass der Strom auch passt…

14

“Passthru” sollte nicht sein.
In einem normalen ESS bedeutet das normalerweise, das die Verbindung zum Netzsensor unterbrochen ist und dann fährt das System runter bzw. geht eben in einen Fehlermodus.

Hast du einen Netzsensor im System?
Ich vermute diese Werte musst du bei “external control” auch manuell senden.

Wie genau ist dein System aufgebaut?

Wie gesagt, wir hatten hier schon den ein oder anderen Fall, da war das BMS falsch programmiert.

Und genau deswegen installieren wir nur Systeme mit “fertigen” und unterstützen Akkus.
Die sind zwar teuer, aber man hat einfach weniger Probleme damit.

Ich würde wetten, wenn du das System noch mal neu aufsetzt und die BMS Kommunikation weg lässt, wird es erst mal funktionieren wie es soll und die Probleme fangen erst an, wenn du das BMS anschließt und du versuchst das System per external control manuell zu steuern (warum willst du das eigentlich machen?).

15

das Passthru kommt weil der Multi grad keine Leistung macht. Mit Toaster sieht das anders aus:

grafik
grafik480×272 16.1 KB

Die Anzeigen sind manchmal etwas ‘irreführend’…

Der einzige Netzsensor im Victron System steckt im Multi (oder was meinst du mit Netzsensor)?

PV Panels → SmartSolar MPPT Charger → SmartShunt → JK BMS → Akku
Akku → BMS → SmartShunt → MultiPlusII → Netz

Ein rein “DC gekoppeltes” System.

Die Vorgabe des Netzsollwertes für den Multi erfolgt per externem Skript welches das Smartmeter überwacht.

Das BMS liefert die Lade-Sollspannung entsprechend Akku-Ladestand (umgesetzt im Venus)

hm, muss ich dazu die Kommunikation (physisch) wegmachen oder kann ich auch das ‘Controlling BMS’ auf Nix setzen? ich hätte ja gern weiterhin die min/max Cell Voltage, Temperaturen und so…

Klar wird es funktionieren, wenn ich den Multi machen lasse ohne BMS Control (natürlich muss ich dann die beiden Zeilen wieder rein nehmen…

Der eigentliche Hintergrund ist, dass ich SoC-basiert die Ladespannung absenke, damit der Akku nur bis 80..85% läd. Das ist ja im Venus so nicht vorgesehen. Aber das wird wieder alles zu kompliziert da drauf einzugehen und lenkt den Fokus weg vom eigentlichen Problem, das da weiterhin heisst “Warum setzt das System /Hub/ChargeVoltage zu 0.0?”

das versuche ich nicht, sondern tue es erfolgreich und ohne Probleme. Das hat ja auch nix damit zu tun, dass die Lader nicht laden, weil /Hub/ChargeVoltage 0 ist. Das hat auch nix mit External Control zu tun, sondern verhält sich genauso bei Optimized.

Der Hintergrund warum ich überhaupt per Skript den Setpoint vorgebe ist weil ich noch einen weiteren Wechselrichter im System habe, der nicht Victron ist, und das Venus oder das ESS nicht darauf ausgelegt ist, noch einen anderen WR zu steuern. Der Lumentree macht die kleinen Lasten unter 100W sehr viel glatter, deswegen ist bis 300W nur der Lumentree aktiv und erst da drüber kommt der Multi dazu… Aber wie gesagt, das ist alles kein Problem und hat mit dem eigentlichen Problem nix zu tun.

16

@M_Lange wie kann ich denn erreichen, dass der Multi eine Ladespannung vorgibt (begrenzen kann ich die ja immer noch) aber NICHT aus dem Netz läd?

17

aber was soll an dem BMS problematisch sein, wenn doch CVL und CCL sauber übertragen werden und auch sauber verarbeitet werden, wenn nur der Multi nicht mit seinen 0 Volt dazwischen funkt??

18

@M_Lange Ha! ich hab grad was interessantes gesehen: Sobald der Toaster an ist und der Multi von “Passthru” auf “Bulk” wechselt, geht /Hub/ChargeVoltageauf 57.6V hoch (wo immer der Wert jetzt auch her kommt, ich hab den nirgends(!) programmiert).

Aber es kann doch nicht Sinn der Sache sein, dass die Charger nur laden sollen, wenn der WR auch wechselrichtet?!?

19

so, ich hab noch ein wenig rumprobiert. Es ist tatsächlich so - wenn der Inverter (die Taktung) aus ist, ist/Hub/ChargeVoltageauf 0. Wenn ich einen Sollwert von auch nur 0 sende, geht der Inverter an, und /Hub/ChargeVoltage geht auf einen ‘reasonable’ Wert. Wie der sich genau ergibt müsste ich noch ergründen, bei Sollwert 0 ist es die vorgegebene Ladespannung, bei 1000W auch noch. k.A. wo die 57,6V vorhin herkamen.

/Hub/ChargeVoltageauf 0 ist ‘synchron’ mit “Passthru”. Ist die ChargeVoltage ungleich 0, wird auch irgendein Ladestatus angezeigt, auch in Form der LEDs am Multi.

Fazit:

Es hat also nichts mit dem BMS zu tun, nichts damit, dass das System nochmal frisch aufgesetzt werden muss, es resultiert nicht aus irgendeinem Fehlerzustand, und es hat auch nur bedingt was mit External Control zu tun.

Es ist halt so, dass der Inverter aus geht, wenn länger kein Sollwert gesendet wird. Das ist auch so beabsichtigt, weil was soll der Inverter takten, wenn er nichts machen soll?!

Ich hab keine Ahnung, ob man in Optimized den Inverter auch dazu bringen kann, dass er ausschaltet, meine aber, dass das da auch irgendwie passiert (auch ohne in Fehler zu gehen), weil ich mit ziemlicher Sicherheit zu erinnern meine, dass ich auch Optimized ohne meinen Hack probiert habe, und die Lader haben auch dann irgendwann nicht mehr geladen.

Das erklärt auch, warum es bei den meisten Leuten funktioniert aber nicht bei allen: bei den meisten Leuten ist der Multi eigentlich immer “in Betrieb” (also der Inverter tut irgendwas), und bei denen, wo es nicht geht, macht der Multi dann halt auch mal Pause.

Interessant ist, dass wenn man den Multi in den Modus ‘off’ versetzt, die /Hub/ChargeVoltage wieder ihren richtigen Wert annimmt. Nur braucht er dann halt ne Weile, bis er wieder am Netz ist, wenn er wieder eingeschaltet wird. Das ist also keine Option für ‘Bereitschaft’.

Was bedeutet das jetzt?

Das bedeutet wohl, dass ich bei meinem Hack bleibe, solange Victron es für sinnvoll hält, das Laden abzuschalten, sobald und solange der Inverter nicht taktet. Der Sinn dahinter will mir zwar nicht einleuchten, aber sei’s drum.

Vielen Dank nochmal allen und besonders @M_Lange dass du doch noch dabei geblieben bist!

Zumindest habe ich so bestätigt bekommen, dass ich nicht zu blöd bin, sondern dass das System halt offensichtlich nicht davon ausgeht, dass man einen Multi in Bereitschaft hält, für falls man ihn braucht, den Inverter aber ruhen lässt, solange man ihn nicht braucht.

Grüsse!

ps. @M_Lange vielleicht kannst du ja mal anregen, drüber nachzudenken, ob es wirklich sinnvoll ist, bei gestopter Taktung auch externe Lader abzuschalten!?

20

Die Ladespannung kannst Du doch im DVCC vorgeben … und damit kann man dann auch auf z.B. 90% begrenzen..

Und wenn Du den Inverter ausschaltest wird wohl auch der MPPT abgeschaltet..