False number of producing channels

What happened?

Ab und zu (alle paar Tage, ohne erkennbares Muster) läuft der Wechselrichter (HMT2250) bei mir Amok - in diesem Fall werden Leistungsbegrenzungen eingestellt die deutlich über der im DPL eingestellten Höchstgrenze liegen (1000W). In Folge wird der Wechselrichter direkt danach durch den DPL wieder abgeschaltet, dann wieder ein usw. - ein tolle, schwingende Regelschleife. Mein Blick in den Log offenbart dabei 2 Auffäligkeiten: 1.) Es werden nur 2 channels (von 6) als producing gemeldet, alle 6 liefern aber Leistung. Das wird dann auch der Grund sein, das das Limit falsch gesetzt wird - Faktor 3 zu hoch. Die Frage ist: wie kann es dazu kommen, das die Anzahl der Kanäle fast immer mit 6 ermittelt wird und dann plötzlich nur mit 2, ohne Neustart o.ä. dazwischen? Ein Neustart nach Falscherkennung ändert übrigens nichts. 2.) Wenn 1.) auftritt, dann treten auch Meldung wie folgt auf: 16:52:37.196 > [DPL::commitPowerLimit] Stopping inverter... 16:52:37.245 > Frame kaputt 16:52:37.307 > Frame kaputt 16:52:37.449 > Middle missing 16:52:37.498 > Request retransmit: 5 16:52:37.550 > Success Das sieht mir irgendwie nach Problemen mit der Übertragung von/zum Wechselrichter aus, oder? Die OpenDTU ist 50cm vom WR entfernt und steht auf niedriger Sendeleistung. Was sagt die Meldung "Middle missing" aus? Trotz der Übertragungsfehler schafft es OpenDTU das Limit zu setzen, was dann leider viel zu hoch ist.

Mal abgesehen davon, das am besten die Übertragungsfehler zu beheben wären (wenn ich wüßte wie....), fände ich es doch gut, wenn man den Wechselrichter mit seinen Kanälen fest in OpenDTU konfigurieren könnte, d.h. die produzierenden Kanäle nicht automatisch erkannt werden und erst recht nicht dynamisch, Damit würde wenigstens das Schwingen im Fehlerfall nicht auftreten. Das Problem trat auch mit früheren Builds bereits auf.

To Reproduce Bug

s.o.

Expected Behavior

s.o.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

2024.02.19

Relevant log/trace output

Fetch inverter: 138290120215
16:51:40.813 > Success
16:51:42.150 > PowerMeterClass: TotalPower: -892.19
16:51:42.201 > [DPL::loop] ******************* ENTER **********************
16:51:42.252 > [DPL::loop] battery interface enabled, SoC: 53 %, StartTH: 25 %, StopTH: 15 %, SoC age: 0 s
16:51:42.302 > [DPL::loop] dcVoltage: 53.10 V, loadCorrectedVoltage: 54.47 V, StartTH: 53.20 V, StopTH: 51.20 V
16:51:42.352 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is producing
16:51:42.402 > [DPL::loop] SolarPT enabled, Drain Strategy: 0, canUseDirectSolarPower: yes
16:51:42.452 > [DPL::loop] battery discharging allowed, PowerMeter: -892 W, target consumption: 0 W
16:51:42.502 > [DPL::setNewPowerLimit] requested: 476 W, (re-)sending limit: 476 W
16:51:42.552 > [DPL::loop] ******************* Leaving PL, calculated limit: 476 W, requested limit: 476 W (updated from calculated)
16:51:42.602 > [ 187104.692] DPL: waiting for a power limit command to complete
16:51:44.234 > Success
16:51:44.286 > [ 187106.696] DPL: waiting for the system to settle
16:51:45.262 > Fetch inverter: 138290120215
16:51:45.747 > Power limiter normal operation
16:51:45.812 > Success
16:51:47.233 > [ 187109.693] DPL: waiting for sufficiently recent inverter data
16:51:50.266 > Fetch inverter: 138290120215
16:51:50.816 > Success
16:51:50.864 > [ 187113.277] DPL: waiting for sufficiently recent power meter reading
16:51:52.210 > PowerMeterClass: TotalPower: -908.67
16:51:52.261 > [DPL::loop] ******************* ENTER **********************
16:51:52.311 > [DPL::loop] battery interface enabled, SoC: 53 %, StartTH: 25 %, StopTH: 15 %, SoC age: 0 s
16:51:52.362 > [DPL::loop] dcVoltage: 53.40 V, loadCorrectedVoltage: 53.85 V, StartTH: 53.20 V, StopTH: 51.20 V
16:51:52.412 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is producing
16:51:52.460 > [DPL::loop] SolarPT enabled, Drain Strategy: 0, canUseDirectSolarPower: yes
16:51:52.512 > [DPL::loop] battery discharging allowed, PowerMeter: -909 W, target consumption: 0 W
16:51:52.562 > [DPL::commitPowerLimit] Stopping inverter...
16:51:52.706 > [DPL::loop] ******************* Leaving PL, calculated limit: -460 W, requested limit: 20 W (updated from calculated)
16:51:54.292 > Success
16:51:56.340 > Success
16:51:56.601 > Fetch inverter: 138290120215
16:51:56.803 > [DPL::commitPowerLimit] Stopping inverter...
16:51:56.889 > Success
16:51:57.155 > [ 187119.602] DPL: waiting for a power limit command to complete
16:51:59.140 > Success
16:52:00.695 > Power limiter normal operation
16:52:01.195 > Success
16:52:01.242 > [ 187123.656] DPL: waiting for the system to settle
16:52:01.513 > Fetch inverter: 138290120215
16:52:01.886 > Success
16:52:02.552 > PowerMeterClass: TotalPower: -54.44
16:52:02.719 > Last missing
16:52:02.764 > Request retransmit: 7
16:52:02.852 > Last missing
16:52:02.904 > Request retransmit: 8
16:52:03.152 > Last missing
16:52:03.205 > Request retransmit: 9
16:52:03.255 > Last missing
16:52:03.357 > Request retransmit: 10
16:52:03.561 > Last missing
16:52:03.616 > Request retransmit: 11
16:52:03.666 > Last missing
16:52:03.715 > Retransmit timeout
16:52:04.192 > [ 187126.653] DPL: waiting for sufficiently recent inverter data
16:52:06.340 > Fetch inverter: 138290120215
16:52:06.893 > Success
16:52:06.944 > [ 187129.353] DPL: waiting for sufficiently recent power meter reading
16:52:07.908 > Success
16:52:11.343 > Fetch inverter: 138290120215
16:52:11.601 > Frame kaputt
16:52:11.653 > Frame kaputt
16:52:11.926 > Middle missing
16:52:11.973 > Request retransmit: 4
16:52:12.031 > Success
16:52:12.620 > PowerMeterClass: TotalPower: 440.36
16:52:12.674 > [DPL::loop] ******************* ENTER **********************
16:52:12.725 > [DPL::loop] battery interface enabled, SoC: 53 %, StartTH: 25 %, StopTH: 15 %, SoC age: 0 s
16:52:12.777 > [DPL::loop] dcVoltage: 53.60 V, loadCorrectedVoltage: 53.60 V, StartTH: 53.20 V, StopTH: 51.20 V
16:52:12.827 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is NOT producing
16:52:12.879 > [DPL::loop] SolarPT enabled, Drain Strategy: 0, canUseDirectSolarPower: yes
16:52:12.927 > [DPL::loop] battery discharging allowed, PowerMeter: 440 W, target consumption: 0 W
16:52:12.977 > [DPL::setNewPowerLimit] 6 channels total, 2 producing channels, scaling power limit
16:52:13.027 > [DPL::setNewPowerLimit] requested: 440 W, (re-)sending limit: 1320 W
16:52:13.077 > [DPL::commitPowerLimit] Starting up inverter...
16:52:13.128 > [DPL::loop] ******************* Leaving PL, calculated limit: 440 W, requested limit: 1320 W (updated from calculated)
16:52:13.178 > [ 187135.164] DPL: waiting for a power limit command to complete
16:52:14.707 > Success
16:52:14.753 > [ 187137.167] DPL: waiting for a start/stop/restart command to complete
16:52:15.706 > Power limiter normal operation
16:52:16.752 > Success
16:52:16.806 > Fetch inverter: 138290120215
16:52:16.854 > [ 187139.212] DPL: waiting for the system to settle
16:52:17.302 > Success
16:52:19.749 > [ 187142.209] DPL: waiting for sufficiently recent inverter data
16:52:21.751 > Fetch inverter: 138290120215
16:52:22.304 > Success
16:52:22.356 > [ 187144.764] DPL: waiting for sufficiently recent power meter reading
16:52:22.672 > PowerMeterClass: TotalPower: -879.67
16:52:22.716 > [DPL::loop] ******************* ENTER **********************
16:52:22.766 > [DPL::loop] battery interface enabled, SoC: 53 %, StartTH: 25 %, StopTH: 15 %, SoC age: 0 s
16:52:22.818 > [DPL::loop] dcVoltage: 53.00 V, loadCorrectedVoltage: 54.36 V, StartTH: 53.20 V, StopTH: 51.20 V
16:52:22.867 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is producing
16:52:22.916 > [DPL::loop] SolarPT enabled, Drain Strategy: 0, canUseDirectSolarPower: yes
16:52:22.966 > [DPL::loop] battery discharging allowed, PowerMeter: -880 W, target consumption: 0 W
16:52:23.017 > [DPL::setNewPowerLimit] requested: 476 W, (re-)sending limit: 476 W
16:52:23.066 > [DPL::loop] ******************* Leaving PL, calculated limit: 476 W, requested limit: 476 W (updated from calculated)
16:52:23.117 > [ 187145.188] DPL: waiting for a power limit command to complete
16:52:23.168 > Middle missing
16:52:23.220 > Request retransmit: 7
16:52:23.270 > Middle missing
16:52:23.319 > Request retransmit: 8
16:52:23.372 > Success
16:52:25.420 > Success
16:52:25.680 > [ 187147.880] DPL: waiting for the system to settle
16:52:26.753 > Fetch inverter: 138290120215
16:52:27.309 > Success
16:52:28.418 > [ 187150.879] DPL: waiting for sufficiently recent inverter data
16:52:30.802 > Power limiter normal operation
16:52:31.755 > Fetch inverter: 138290120215
16:52:32.307 > Success
16:52:32.354 > [ 187154.767] DPL: waiting for sufficiently recent power meter reading
16:52:32.735 > PowerMeterClass: TotalPower: -890.77
16:52:32.779 > [DPL::loop] ******************* ENTER **********************
16:52:32.830 > [DPL::loop] battery interface enabled, SoC: 53 %, StartTH: 25 %, StopTH: 15 %, SoC age: 1 s
16:52:32.880 > [DPL::loop] dcVoltage: 53.30 V, loadCorrectedVoltage: 53.70 V, StartTH: 53.20 V, StopTH: 51.20 V
16:52:32.930 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is producing
16:52:32.980 > [DPL::loop] SolarPT enabled, Drain Strategy: 0, canUseDirectSolarPower: yes
16:52:33.031 > [DPL::loop] battery discharging allowed, PowerMeter: -891 W, target consumption: 0 W
16:52:33.080 > [DPL::commitPowerLimit] Stopping inverter...
16:52:33.130 > [DPL::loop] ******************* Leaving PL, calculated limit: -496 W, requested limit: 20 W (updated from calculated)
16:52:34.819 > Success
16:52:36.865 > Success
16:52:37.150 > Fetch inverter: 138290120215
16:52:37.196 > [DPL::commitPowerLimit] Stopping inverter...
16:52:37.245 > Frame kaputt
16:52:37.307 > Frame kaputt
16:52:37.449 > Middle missing
16:52:37.498 > Request retransmit: 5
16:52:37.550 > Success
16:52:37.832 > [ 187160.292] DPL: waiting for a power limit command to complete
16:52:39.835 > Success
16:52:41.889 > Success
16:52:41.939 > Fetch inverter: 138290120215
16:52:41.989 > [ 187164.350] DPL: waiting for the system to settle
16:52:42.441 > Success
16:52:42.936 > PowerMeterClass: TotalPower: -45.49
16:52:43.273 > Middle missing
16:52:43.320 > Request retransmit: 6
16:52:43.406 > Middle missing
16:52:43.461 > Request retransmit: 7
16:52:43.540 > Middle missing
16:52:43.591 > Request retransmit: 8
16:52:43.675 > Middle missing
16:52:43.720 > Request retransmit: 9
16:52:43.810 > Middle missing
16:52:43.861 > Request retransmit: 10
16:52:43.915 > Success
16:52:44.885 > [ 187167.346] DPL: waiting for sufficiently recent inverter data
16:52:45.754 > Power limiter normal operation
16:52:46.889 > Fetch inverter: 138290120215
16:52:47.447 > Success
16:52:47.494 > [ 187169.905] DPL: waiting for sufficiently recent power meter reading
16:52:51.892 > Fetch inverter: 138290120215
16:52:52.444 > Success
16:52:53.001 > PowerMeterClass: TotalPower: 438.52
16:52:53.045 > [DPL::loop] ******************* ENTER **********************
16:52:53.097 > [DPL::loop] battery interface enabled, SoC: 53 %, StartTH: 25 %, StopTH: 15 %, SoC age: 0 s
16:52:53.147 > [DPL::loop] dcVoltage: 53.60 V, loadCorrectedVoltage: 53.60 V, StartTH: 53.20 V, StopTH: 51.20 V
16:52:53.196 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is NOT producing
16:52:53.248 > [DPL::loop] SolarPT enabled, Drain Strategy: 0, canUseDirectSolarPower: yes
16:52:53.297 > [DPL::loop] battery discharging allowed, PowerMeter: 439 W, target consumption: 0 W
16:52:53.347 > [DPL::setNewPowerLimit] 6 channels total, 2 producing channels, scaling power limit
16:52:53.397 > [DPL::setNewPowerLimit] requested: 439 W, (re-)sending limit: 1317 W
16:52:53.446 > [DPL::commitPowerLimit] Starting up inverter...
16:52:53.497 > [DPL::loop] ******************* Leaving PL, calculated limit: 439 W, requested limit: 1317 W (updated from calculated)
16:52:53.547 > [ 187175.550] DPL: waiting for a power limit command to complete
16:52:55.091 > Success
16:52:55.138 > [ 187177.552] DPL: waiting for a start/stop/restart command to complete
16:52:57.136 > Success
16:52:57.187 > Fetch inverter: 138290120215
16:52:57.237 > [ 187179.597] DPL: waiting for the system to settle
16:52:57.688 > Success

Anything else?

No response

Hallo

dein fehlerbild ist das gleiche, wie in #686.

Wenn der inverter aus ist, zieht er vermutlich nur auf einen oder vielleicht zwei Eingängen Strom. Dadurch wird fälschlicher Weise gedacht, dass nur diese beiden Eingänge liefern und es wird skaliert.

Wenn er dann läuft, mit dem falschen Limit, speist du natürlich zu viel ein. Darauf soll mit einer Reduzierung des Limits reagiert werden.

Leider wird das Limit nicht gesetzt. Das sieht man ebenfalls bei dir in den ersten beiden DPL Loops.

Da das Limit nicht ankommt, der DPL aber denkt es sei bereits aktiv, ist die nächste und logische Schritt das abschalten des inverters.

Auf das falsche interpretieren der Daten kann man reagieren. Ich glaube, das hat @schlimmchen bereits auf dem Schirm und in der Pipeline (?)

deine grundursache ist ja aber, wie du auch erkannt hast, die schlechte Kommunikation zwischen openDTU und inverter.

Nachtrag: Interessant wie lange es dauert, bis der wechselrichter die Einspeisung stoppt.

’’’ 16:52:32.735 > PowerMeterClass: TotalPower: -890.77

16:52:32.779 > [DPL::loop] * ENTER ** 16:52:32.830 > [DPL::loop] battery interface enabled, SoC: 53 %, StartTH: 25 %, StopTH: 15 %, SoC age: 1 s 16:52:32.880 > [DPL::loop] dcVoltage: 53.30 V, loadCorrectedVoltage: 53.70 V, StartTH: 53.20 V, StopTH: 51.20 V 16:52:32.930 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is producing 16:52:32.980 > [DPL::loop] SolarPT enabled, Drain Strategy: 0, canUseDirectSolarPower: yes 16:52:33.031 > [DPL::loop] battery discharging allowed, PowerMeter: -891 W, target consumption: 0 W 16:52:33.080 > [DPL::commitPowerLimit] Stopping inverter... 16:52:33.130 > [DPL::loop] * Leaving PL, calculated limit: -496 W, requested limit: 20 W (updated from calculated)

16:52:42.936 > PowerMeterClass : TotalPower: -45.49 ’’’

9 Sekunden nach dem ersten „stopping“ hast du noch immer 45W Einspeisung ins Netz.

Vielleicht brauchen die HMS/HMT einfach mehr Zeit zum reagieren? Die Probleme gibt es scheinbar nur mit diesen Modellen. Von den HM bekomme ich das nicht so häufig mit.

Auf das falsche interpretieren der Daten kann man reagieren. Ich glaube, das hat @schlimmchen bereits auf dem Schirm und in der Pipeline (?)

Meinst du dafür zu sorgen, dass regelmäßig überprüft wird, ob das gesendete Limit angekommen ist bzw. zu prüfen, ob der Inverter wirklich aus oder an ist? Ja, dem nehme ich mir an. Wann ist halt die Frage... Es ist jedenfalls ein wichtiges Thema.

@spcqike Wie oft habe ich jetzt schon geschimpft, dass diese verdammte Skalierung des Power-Limits weg muss? Dass es auch Inverter mit sechs Eingängen gibt, war mir noch gar nicht klar, was es noch komplizierter machen würde, das einigermaßen gescheit zu implementieren. Und wie wir hier sehen, scheint es ja grundsätzlich bei diesem Inverter-Modell nicht zu funktionieren, egal wie gut es implementiert ist. Oder zumindest müsste für diesen eine Sonderlocke mit rein, oder eine grundsätzliche Sonderbehandlung wenn der Inverter im Standby ist.

Leider befürchte ich, dass es Wellen schlagen wird, wenn wir die Skalierung wirklich einfach weghauen. Einen Schalter einzuführen für ein Feature, das meiner Meinung nach dringend entsorgt werden muss, widerstrebt mir extrem. Ich denke gerade, dass man das Skalieren nur versuchen sollte, wenn der Inverter genau zwei Eingänge hat. Deren Verhalten war ja ursprünglich verstanden worden und für diese Inverter war das Feature gemacht und für die scheint das ja sogar zu funktionieren. Aber bei vieren hörts dann auf, insb. weil ich inzwischen weiß, dass die HMS einen MPPT pro Eingang haben, auch bei vieren, und die HM aber nur einen pro 2 Eingänge...

Hallo, danke für die Details. Ja, möglicherweise ist das so mit der Kanalermittlung, auch wenn hier eine Schwelle von 2.0W im Sourcecode steht, die ich bei deaktiviertem Wechselrichter noch nie gesehen habe - die Kanäle sind dann relativ gleichmässig zwischen 0.2 und 0.8W. In dem Zusammenhang wäre aber auch noch ein Szenario möglich: ich habe dieses Amok-Verhalten bisher quasi nur beobachtet, wenn die Sonne fast vollständig weg ist. Mit der Schwelle von 2W ergäbe das Sinn - der Solarertrag liegt dann eventuell in diesem Bereich und der DPL ermittelt dann irgendwann die Kanalzahl falsch, da ein paar Kanäle minimal drunter und einige drüber liegen. Vielleicht sollte man hier nicht die Leistung beurteilen, sondern nur die DC-Spannung, denn die sollte relativ gleichmässig bei allen genutzen Kanälen da sein. Dann wäre auch ein anderes Problem behoben: Wenn man z.B. nur einen Eingang eines MPPT belegt, erkennt der DPL ja auch nur einen Kanal (da nur einer Leistung meldet), daas Limit wird dann aber nicht korrekt eingestellt, da der Hoymiles immer die Leistung auf die MPPTs verteilt und nicht auf die Eingänge. Sprich: der DPL berechnet das Limit korrigiert für einen Kanal, der Hoymiles aber für 2 --> der Hoymiles zieht dann einfach mal 750W über einen Eingang und das ganze System schwingt wieder. Keine Tragik, da man ohnehin beide Kanäle eines MPPT belegen sollte, aber zumindest die falsche Korrektur wäre bei geänderter Kanal-Erkennung auch behoben. Temporär habe ich mir jetzt erstmal eine eigene Variante compiliert, ohne Kanalerkennung,

Was das Stoppen angeht - hier kann eine Eigenheit meines Powermeter zum Tragen kommen - größere Leistungssprünge (in Richtung Leistungsaufnahme) über 500W kommen bei mir erst verzögert, da diese einen Minimum-Filter durchlaufen, um die PWM meines Induktionskochfeldes auszufiltern. Andernfalls regelt mir der DPL wild der PWM hinterher und speist immer dann ein, wenn das Kochfeld gerade keinen Strom aufnimmt und umgekehrt. Funktioniert bei normalem Ablauf auch sehr gut, ist bei diesem Amoklauf aber nicht unbedingt förderlich.

Hast du Solarpaneele und Batterie gemischt angeschlossen?

Nein, nur Batterie an 6 Eingängen des HMT2250. Ich hatte aber zu Beginn, als ich mir noch nicht sicher war, wie gut das mit Parallel-Schalten der Eingänge und Aufladen der Eingangskondensatoren mittels Soft-Start des BMS klappt, erstmal mit einem Eingang experimentiert und habe mich dann über das Regelverhalten gewundert und einige Stunden in den Einstellungen verbracht (und die Funktionsweise des DPL am Ende im Code studiert, um dann dort über die Kanalermittlung zu stolpern), bevor ich das mit der Kanalerkennung geblickt habe. Dabei war aber gut zu sehen, das Hoymiles einfach die doppelte Leistung an einem Eingang zieht.

Nein, nur Batterie an 6 Eingängen des HMT2250.

Da bin ich aber sehr erleichtert :wink:

Dabei war aber gut zu sehen, das Hoymiles einfach die doppelte Leistung an einem Eingang zieht.

Das verstehe ich nicht genau, hab aber das Gefühl, dass hier etwas sein könnte, dass mir ggf. hilft zu argumentieren, dass das Skalieren im DPL weg muss. Magst du das einmal genauer erläutern, was du da gelernt hast?

Gerne. Folgende Szenario:

HMT2250 mit 6 Eingänge, 3 MPPT. Je 2 Eingänge gehen auf einen MPPT und sind quasi nur parallel geschaltet. Nur ein Strommessshunt trennt die Eingänge, damit der HMT Leistungsdaten getrennt für die Eingänge anzeigen kann.
Es wird nur ein Eingang eines MPPT belegt

Stellt man nun eine Leistungsbegrenzung ein, so verteilt der Hoymiles diese nicht gleichmäßig auf die Eingänge. sondern auf die MPPTs. Bei eingestellten 1000W für dem gesamten WR, nimmt er damit 333W an dem einen belegten MPPT auf. Dabei beachtet er auch nicht die eigenen Datenblattangaben zur Maximaleistung und Kurzschlußstrom pro Eingang. sondern nur pro MPPT. Dabei geht offensichtlich nichts kaputt, aber der DPL regelt dabei natürlich völligen Mist zusammen, da er nur die Leistungsaufnahme eines Kanals sieht, faktisch aber die Leistung zweier Kanäle geliefert wird.

Damit müsste bei Modellen mit 2 Eingängen pro MPPT somit immer die Anzahl der Leistung-lieferenden MPPTs ermittelt werden und nicht die Anzahl der Eingänge. Hoffe das ist irgendwie verständlich :-)

Und wie wir hier sehen, scheint es ja grundsätzlich bei diesem Inverter-Modell nicht zu funktionieren, egal wie gut es implementiert ist

naja, für mich sieht es aktuell immer so aus, als wäre die Skalierung nur dann ein Problem, wenn der Inverter aus ist. Da die Abfrage Leistung > 2W in dem Fall halt nirgends greift. Im Gegenteil, die Skalierung müsste erst einmal außen vor gelassen werden, wenn der Inverter im DPL::loop() als NOT producing erkannt wird.

Zusätzlich scheint es bei den HMS/HMT (oder generell bei Invertern mit dem CMT2300A) vermehrt zu Problemen zu kommen. Sei es das nicht starten, wenn der Startbefehl geschickt wird, oder auch das Reduzieren des Limits, wenn dieses geschickt wird. In Summe schaukeln sich diese Probleme zu dem auf, was wir sehen.

Falsches Limit (durch fälschlicher Weise skalierte Leistung, obwohl diese im AUS-Zustand gar nicht bewertet werden kann), dadurch viel zu viel Leistung und eine hohe Einspeisung. Im nächsten Durchlauf soll die EInspeisung reduziert werden, die Reduzierung des Limits kommt ggf. nicht an, dadurch wird im dritten Durchlauf der Wechselrichter fälschlicher Weise gestoppt. und ggf. anschließend mit falsch skaliertem Limit wieder gestartet.

Die Grundursache ist sicher, dass Befehle nicht ankommen (hier das Reduzieren des Limits, was ja im 2. Schritt im Stoppen des Inverters mündet). Aber da werden wir softwareseitig nicht viel machen können.

Wobei, vielleicht doch?

9 Sekunden nach dem ersten „stopping“ hast du noch immer 45W Einspeisung ins Netz.

Wenn die Wechselrichter so lange brauchen, bis sie auf Änderungen reagieren, vielleicht versuchen wir einfach viel zu schnell zu regeln? Irgendwo hab ich gelesen, dass Wechselrichter nur eine Gewisse Leistung pro Sekunde regeln dürfen (400W/s ? irgendwie so).

Bei kleineren Wechselrichtern (< HM-1200) und kleineren Leistungsanpassungen, kommen wir mit unserem 5-Sekunden Zyklus wohl hin. Wenn nun aber fälschlicher Weise > 1500W erzeugt werden und dies gefühlt 3 Sekunden später auf bereits auf ~ 400W reduziert werden soll, vielleicht reagiert der Inverter einfach nicht schnell genug. oben ist ja gut ersichtlich, dass vom "Stoppe" zum tatsächlichen Stopp mindestens 9 Sekunden vergangen sind.

Oder zumindest müsste für diesen eine Sonderlocke mit rein, oder eine grundsätzliche Sonderbehandlung wenn der Inverter im Standby ist.

ich denke, die Skalierung darf einfach nicht passieren, wenn der Inverter aus ist. Wenn der Inverter AUS ist, sollte erst einmal nur das theoretische Limit gesetzt werden. Erst danach kann vom DPL sinnvoll ermittelt werden, wie viele Eingänge belegt sind.

Leider befürchte ich, dass es Wellen schlagen wird, wenn wir die Skalierung wirklich einfach weghauen

das befüchte ich auch. Ich finde die Skalierung zwar auch nicht ideal, kann sie aber teilweise verstehen (und hätte, unter Berücksichtigung von reinen PV Anlagen (also ohne Batterie) sogar noch Erweiterungswünsche 😄 aber das ist ein anderes Thema). Bei einem reinen Batteriesystem macht sie meiner Meinung nach aber keinen Sinn. Wenn man eine "unendliche" Stromquelle hat, die Batterie, sollte man auch alle möglichen Eingänge benutzen. alles andere wäre unsinnig, da man automatisch höhere Ströme auf den verbleibenden Eingängen erzwingt und damit alle Nachteile selbiger bekommt (Verluste, Abwärme, dickere QUerschnitte nötigt etc. pp.)

Ich denke gerade, dass man das Skalieren nur versuchen sollte, wenn der Inverter genau zwei Eingänge hat. Deren Verhalten war ja ursprünglich verstanden worden und für diese Inverter war das Feature gemacht und für die scheint das ja sogar zu funktionieren. Aber bei vieren hörts dann auf, insb. weil ich inzwischen weiß, dass die HMS einen MPPT pro Eingang haben, auch bei vieren, und die HM aber nur einen pro 2 Eingänge...

Das denke ich (noch) nicht. Die Probleme, die wir in den letzten Wochen sehen, sind meiner Meinung nach immer nur, wenn der Inverter aus ist. Nicht, wenn er läuft. (wie gesagt, auch das Schwingen mit Start - runter regel Versuch - stopp, wie hier ... da ist die falsche Skalierung nicht das Grundproblem)

Ich denke, die Skalierung an sich sollte einfach anders gestalltet werden. Wann macht eine Skalierung allgemein Sinn? Wenn man, weil man sparen will oder nicht genug Platz hat (beides im reinen PV Betrieb!) nicht alle Eingänge belegen will oder kann. im Akku-Betrieb erschließt es sich mir wie gesagt nicht wirklich. Und ein Mischbetrieb schon gar nicht. also ggf. deaktivieren, wenn eine Batterie erkannt wird (ve.direct / bms / shunt ?)

Wenn man sie doch allgemein halten und ändern will, könnte man zusätzlich zur Skalierung auch prüfen, ob man den Inverter nicht überlasten würde. Ich weiß nur noch nicht, ob man raus bekommt, wie viele Tracker ein Wechselrichter hat. die Eingänge gibt er ja zurück, ebenso die Spannungen und Leistung pro Eingang. Das würde aber wohl nicht ausreichen, wenn man sicher stellen möchte, dass nicht 750W auf einem einzelnen Eingang gezogen werden sollen. (was der HMT-2250 wahrscheinlich probieren würde, wenn man nur 1 Eingang anschließt und 2250W als Limit setzt,oder?)

In dem Zusammenhang wäre aber auch noch ein Szenario möglich: ich habe dieses Amok-Verhalten bisher quasi nur beobachtet, wenn die Sonne fast vollständig weg ist. Mit der Schwelle von 2W ergäbe das Sinn - der Solarertrag liegt dann eventuell in diesem Bereich und der DPL ermittelt dann irgendwann die Kanalzahl falsch, da ein paar Kanäle minimal drunter und einige drüber liegen. Vielleicht sollte man hier nicht die Leistung beurteilen, sondern nur die DC-Spannung, denn die sollte relativ gleichmässig bei allen genutzen Kanälen da sein.

Nein, die DC-Spannung ist auf einem Tracker gleich. Wenn du 2 Eingänge an einem MPPT hast, haben beide Eingänge die gleiche Spannung. Auch, wenn nur einer verbunden ist. Der Shunt zum Messen der Leistung, liegt aber in der Masseleitung des jeweiligen Eingangs. also kann die Leistung pro Eingang berechnet werden, die Spannung ist in deinem Fall für jeweils 2 Eingänge gleich.

produziert der HMT-2250 bei 2W pro Kanal überhaupt noch`? 12W in Summe wären 0,5% des Maximums. Ich kann mir vorstellen, dass er erst irgendwo bei ~1% überhaupt anfängt, oder? Wenn man die Skalierung auf Leistungsbasis anpassen will, dann eventuell als prozentualen Wert vom Invertermaximum, bezogen auf den Eingang, oder? also hier 2250W / 6 Eingänge, davon 1%, also 4W.

Dann wäre auch ein anderes Problem behoben: Wenn man z.B. nur einen Eingang eines MPPT belegt, erkennt der DPL ja auch nur einen Kanal (da nur einer Leistung meldet), daas Limit wird dann aber nicht korrekt eingestellt, da der Hoymiles immer die Leistung auf die MPPTs verteilt und nicht auf die Eingänge. Sprich: der DPL berechnet das Limit korrigiert für einen Kanal, der Hoymiles aber für 2 --> der Hoymiles zieht dann einfach mal 750W über einen Eingang und das ganze System schwingt wieder.

ist das so? Das Problem sollte wohl auch eher nur bei Batteriesystem auftreten, oder? ich denke, die wenigsten Leute haben > 700W Modulleistung an einem Eingang angeschlossen.

Dabei beachtet er auch nicht die eigenen Datenblattangaben zur Maximaleistung und Kurzschlußstrom pro Eingang. sondern nur pro MPPT. Dabei geht offensichtlich nichts kaputt

Darauf würde ich langfristig nicht wetten :o wenn er stundenlang außerhalb der Spezifikation betrieben wird.

Ja, stimmt, die WR müssen bei Leistungsänderungen eine gewisse Geschwindigkeitsbegrenzung beachten, damit das Netz Zeit zum Regeln bekommt. Tatsächlich treten bei meinem Problem ja große Leistungsprünge auf, die nicht mit voller Geschwindigkeit ausgeführt werden dürfen. Die Skalierung ist hier zwar nicht der Grund, aber doch der Auslöser, da erst dadurch Leistungssprünge oberhalb der von mir derzeit eingestellten Leistungsgrenze auftreten bzw. eingestellt werden. Solange alles im Normal-Bereich (0-1000W) bleibt, habe ich noch kein Problem beobachtet. Wenn man die Skalierung verbessern will, dann muss man auch eine Zuordnung der Eingänge zu den MPPTs haben, da man eigentlich die Anzahl der produzierenden MPPTs benötigt und nicht die Anzahl der produzierenden Kanäle.

naja, für mich sieht es aktuell immer so aus, als wäre die Skalierung nur dann ein Problem, wenn der Inverter aus ist. Da die Abfrage Leistung > 2W in dem Fall halt nirgends greift. Im Gegenteil, die Skalierung müsste erst einmal außen vor gelassen werden, wenn der Inverter im DPL::loop() als NOT producing erkannt wird.

Ich würde es auch begrüßen, wenn die Anzahl der produzierenden Kanäle nur ermittelt werden wenn: a) der Inverter aktiv ist b) der Inverter oberhalb einer gewissen Leistung ist. Eine Lösung wäre, nicht fest auf >= 2W zu prüfen, sondern Min und Max der Kanal-Leistungen zu ermitteln und dann nur die Kanäle oberhalb von (Min+Max)/2 zu zählen. Und generell nur, wenn Min und Max mindestens 10W auseinander sind (da die einzelnen Eingänge durchaus einige W unterschiedlich sein können wegen verschiedener Leitungslängen, Sicherungen etc.) und der Inverter an ist. Dabei ist aber natürlich noch nicht das 2 Eingänge pro MPPT-Problem gelöst - da muss man generell anders zählen (doch DC-Spannung? - dann würden beide Eingänge eines MPPT gezählt).

Bei kleineren Wechselrichtern (< HM-1200) und kleineren Leistungsanpassungen, kommen wir mit unserem 5-Sekunden Zyklus wohl hin. Wenn nun aber fälschlicher Weise > 1500W erzeugt werden und dies gefühlt 3 Sekunden später auf bereits auf ~ 400W reduziert werden soll, vielleicht reagiert der Inverter einfach nicht schnell genug. oben ist ja gut ersichtlich, dass vom "Stoppe" zum tatsächlichen Stopp mindestens 9 Sekunden vergangen sind.

Hm, ja, vermutlich würde es tatsächlich was bringen, wenn man die begrenzte Leistungsanpassunggeschwindigkeit berücksichtigen würde. Mal sehen ob ich das nicht testen kann, in dem ich den Filter im Leistungsmesser träge genug mache und alternativ den HMT mal meine kompletten Netzschwankungen ausgleichen lassen. Bei 2250W statt 1000W sollte dann ja tendenziell eher ein Problem auftreten. Aber vielleicht ist auch nur ein Problem wenn er von AUS auf eine hohe Leistung kommen muss. Neu anfahren ist - wenn ich es recht in Erinnerung habe - langsamer.

Das würde aber wohl nicht ausreichen, wenn man sicher stellen möchte, dass nicht 750W auf einem einzelnen Eingang gezogen werden sollen. (was der HMT-2250 wahrscheinlich probieren würde, wenn man nur 1 Eingang anschließt und 2250W als Limit setzt,oder?)

Ja, der HMT2250 zieht 750W an einem Eingang, wenn er nicht begrenzt wird. Wenn man ihn derzeit so betreibt, sorgt der DPL für heftiges Schwingen, denn es wird das doppelte produziert gegenüber dem Erwartungswert - der HMT2250 begrenzt pro MPPT und nicht pro Eingang.

Nein, die DC-Spannung ist auf einem Tracker gleich. Wenn du 2 Eingänge an einem MPPT hast, haben beide Eingänge die gleiche Spannung. Auch, wenn nur einer verbunden ist. Der Shunt zum Messen der Leistung, liegt aber in der Masseleitung des jeweiligen Eingangs. also kann die Leistung pro Eingang berechnet werden, die Spannung ist in deinem Fall für jeweils 2 Eingänge gleich.

Was ja vorteilhaft wäre, weil dann beide Eingänge gezählt werden (beiden haben DC) und vom HMT dann auch betrieben werden, weil ja die Belegung nur eines Eingangs eines MPPT dazu führt, das trotzdem Leistung geliefert wird, als ob beide angeschlossen wären. Damit wäre das derzeitige falsche Verhalten des DPL bei nur halber Belegung eines MPPT behoben.

produziert der HMT-2250 bei 2W pro Kanal überhaupt noch`? 12W in Summe wären 0,5% des Maximums. Ich kann mir vorstellen, dass er erst irgendwo bei ~1% überhaupt anfängt, oder? Da bin ich mir nicht sicher - bei 18W produziert er noch, was 3W pro Kanal wären. Mit etwas Streuung, kann dann ein Kanal durchaus bei knapp unter 2W hängen und ein anderer bei 4W.

Dann wäre auch ein anderes Problem behoben: Wenn man z.B. nur einen Eingang eines MPPT belegt, erkennt der DPL ja auch nur einen Kanal (da nur einer Leistung meldet), daas Limit wird dann aber nicht korrekt eingestellt, da der Hoymiles immer die Leistung auf die MPPTs verteilt und nicht auf die Eingänge. Sprich: der DPL berechnet das Limit korrigiert für einen Kanal, der Hoymiles aber für 2 --> der Hoymiles zieht dann einfach mal 750W über einen Eingang und das ganze System schwingt wieder.

ist das so? Das Problem sollte wohl auch eher nur bei Batteriesystem auftreten, oder? ich denke, die wenigsten Leute haben > 700W Modulleistung an einem Eingang angeschlossen.

Ja, das ist wirklich so. Die Quelle ist dabei erstmal egal - die Eingänge sind bis auf einen Shunt mit ein paar mOhm direkt parallel verbunden. Der HMT nutzt den Shunt aber anscheinend nur zur Strom- und Leistungsanzeige der Kanäle. Erst der MPPT begrenzt dann das Ganze.

Darauf würde ich langfristig nicht wetten :o wenn er stundenlang außerhalb der Spezifikation betrieben wird. Ich auch nicht, deshalb habe ich ihn ja auch voll belegt. Bei meinen ersten Gehversuchen bzgl. Einschaltverhalten etc. habe ich halt erstmal mit einem Kanal angefangen (mir war ja nicht klar, ob die MPPTs überhaupt parallel geschaltet werden dürfen etc), ist mir dann gleich das Regelverhalten des DPL um die Ohren geflogen.

Hier mal das beste Beispiel warum die aktuelle Kanalzählung / Skalierung nicht richtig funktioniert (Inverter ist gerade im Standby): grafik Da sieht man prima, warum der bei mir ab und zu nur bis 2 zählt.

korrekt. du hast 2 Eingänge mit > 2W. daher erkennt die aktuelle Logik 2 von 6 Eingängen als aktiv und skaliert eben hoch. Diese Logik ist, sofern der Wechselrichter aus ist, natürlich falsch.

Ist es beim HMT-2250 auch so, dass die Spannung der Eingänge 1/2, 3/4 und 5/6 jeweils die gleiche ist? Im Moment sind sogar alle 6 identisch, aber du hast ja auch keine Last und damit keinen Spannungsabfall irgendwo, sodass alle Eingänge die unbelastete Batterie sehen :)

Ja, bis auf eine gewisse Toleranz (+/-0.1V) sind die gleich, selbst wenn nur ein Eingang eines MPPT belegt ist und der 750W zieht. Unter Last geht die Spannung minimal runter (der Akku kann immerhin 210A liefern und hat daher einen relativ kleinen Innenwiderstand), bleibt aber ebenfalls an allen Eingängen (nahezu) gleich. Ich habe alle 6 Eingänge so symmetrisch wie möglich verkabelt und unter Last ziehen alle auch nahezu die gleiche Leistung.

Ich habe aber jetzt versuchsweise die Skalierung ausgebaut und den Leistungsmesser umgeklemmt, damit vor dem Leistungsmesser eingespeist wird. Damit sieht der DPL nur noch die tatsächliche Last als Regelgröße, nicht mehr aber die Auswirkungen des WR-Limits. Das sollte dem Regelverhalten zuträglich sein und die Änderungsgeschwindigkeit der Leistung des WR dann keine Rolle mehr spielen. Mal sehen, ob ich es so auf Dauer stabil bekomme.

Hallo zusammen! kann das auch bestätigen dass die eingänge der MPPTs einfach parallel geschalten sind, die Spannung ist IMMER die gleiche ( Beweis : wird nur ein Modul an einen MPPT Tracker mit mehreren Eingängen angesteckt, hat der andere leere Eingang die selbe Spannung aber keinen Strom ) Die Schaltung ist somit Panel 1 ---- Messshunt ----| xxxxxxxxxxxxxxxxxxxxxxxxxx| ----- ~12mF Kapazität -------- MPPT Regler ---- Panel 2 ---- Messshunt ----|

Ein einzelner Panel - Eingang selbst und der Messhunt kann problemlos höhere Stromstärken, auch die maximale Stromstärke des MPPT Reglers, die beiden Messshunts und MC4-Stecker pro MPPT dienen einzig und allein der Anschlussmöglickeit und Monitoring einzelner Panels. Im Hoymiles intern wird die prozentuelle Leistungsbegrenzung intern immer pro MPPT an, bzw. ein Limit von x Watt wird immer gleichmäßig auf alle MPPT-Regler aufgeteilt.

Für das Regelkonzept muss das daher heißen ebenfalls nur pro MPPT zu rechnen, eine Verrechnung/Regelung einzelner Paneleingänge macht keinen sinn, diese sollten einfach addiert werden um den MPPT gesamtstrom zu erhalten.

In der OpenDTU onBattery SW sollte daher klar nur die Anzahl verwendeter MPPT Regler angegeben werden NICHT die Anzahl von Paneleingängen.

Wenn der User angibt alle MPPT Eingänge belegt zu haben ( also mit dem Akku verbunden zu haben ) dann wird der Hoymiles auch ziemlich genau den Leistungswert ins Netz abgeben welcher als Begrenzung übermittelt wurde.

Sind allerdings nur einzelne MPPT Regler belegt ( z.b. nur einer bei HM800/1500 oder nur 2 bei HM>2000) DANN ist eine Skalierung sinnvoll und notwendig! Beispiel HM1500, nur ein MPPT Regler mit Akku verbunden, Leistungsbegrenzung auf 750W (50%) bedeutet dann eine Leistungsabgabe ans Netz von nur ca. 400W da es 50% der Maximalleistung eines einzelnen MPPT sind.

Es sollte daher dem User empfohlen bis angewiesen werden ALLE MPPT-Regler mit dem Akku zu verbinden ODER ein Scaling implementiert werden welches bei einzelnen nicht mit Akku verbundenen MPPT-Reglern die Leistungsbegrenzung entsprechend faktorisiert um MaxMPPT/UsedMPPT.

Andrix82, wenn du die Zeichnung in einen Codeblock packst, zerreißt es die Formatierung nicht :)

Paneel1──Messshunt─┐                     
                   ├─12mF Kapazität──MPPT
Paneel2──Messshunt─┘

Ein einzelner Panel - Eingang selbst und der Messhunt kann problemlos höhere Stromstärken

Ist das so? In einem anderen Thread kam auf, dass der Messshunt nur für die im Datenblatt angegebene maximale Stromaufnahme ausgelegt ist. Daher kommt es bei 24V Systemen, die für die MPPT Leistung eben mehr Strom brauchen als im Datenblatt steht, zu falschen Einregeln und Auswerten.

Angenommen bei 400W am Eingang eines HM-800, bei 24V Batteriespannung braucht man halt 16.66A. der Shunt erfasst aber nur bis ~12.5A. daher gibt es ab > 300W massive Abweichungen, so dass der Inverter ab dann quasi nur "voll offen" läuft.

dargestellt unter anderem hier https://github.com/helgeerbe/OpenDTU-OnBattery/issues/613#issuecomment-1896302434

Ob die Hardware die Überbelastung im Hintergrund dauerhaft verträgt, weiß man wohl nur, wenn man bei Hoymiles arbeitet oder einen Wechselrichter öffnet und analysiert. Das Design "Spannungsabfall am Shunt inkl. AD-Wandlung und Interpretation dessen" scheint nur auf den Datenblatt-Strom abgestimmt zu sein.

Es mag sein, dass dies bei anderen Modellen anders ist, aber so lesen sich viele hier beschriebenen Probleme mit 24V Batterien, die zwangsweise zu höheren Strömen am Eingang führen. Die hohen Ströme könnten aber auch bei Wechselrichtern mit 2 Eingängen pro MPPT auftreten, wenn der zweite Eingang nicht oder schlecht verbunden ist.

Im Hoymiles intern wird die prozentuelle Leistungsbegrenzung intern immer pro MPPT an, bzw. ein Limit von x Watt wird immer gleichmäßig auf alle MPPT-Regler aufgeteilt.

Das entspricht auch meinen Kenntnisstand.

Es sollte daher dem User empfohlen bis angewiesen werden ALLE MPPT-Regler mit dem Akku zu verbinden

Das sehe ich genauso. Ein Akkubetrieb, in dem nicht alle Eingänge belegt sind, macht mMn. wenig Sinn. Damit erhöht man sich nur die Verluste etc. pp. durch höhere Ströme und holt sich Fehlerquellen rein.

Da wir auch reine PV-Systeme haben (also ohne Akku), macht die Skalierung doch Sinn, nur nicht so, wie sie aktuell implementiert ist. bspw. HM-800 Durch Verschattung und unterschiedliche Ausrichtung kann es sein, dass beide Eingänge (hier auch gleichzeitig MPPT) produzieren (bspw. 40W und 200W). Ein Limit auf 300W Einspeisung reduziert damit die Leistung auf 40W+150W, also 190W von möglichen 240W. Die Skalierung sollte hier berücksichtigen, dass beim gewünschten 300W Limit und damit wechselrichterinterner Begrenzung auf 150W pro MPPT, der eine MPPT eben in der Begrenzung läuft, der andere nicht. Es könnte also mehr produziert werden. in desem Fall müsste das Limit zum WR auf 520W gestellt werden. Damit kann jeder Eingang 260W erzeugen. der aktuell schwache liefert nicht mehr als 40W, der zweite darf bis zu 260W und damit erreicht man das Ziel der eigentlichen 300W wieder.

Als Formel in etwa so:

P_wr = (P_ziel - Summe(P_nicht_begrenzte_mppt))*Anzahl_MPPT

hier eben (300-40)*2 oder 520W.

Zumindest bei einem 48V System hatte ich kein Problem bis zu ~17A über einen einzelnen MC4 Eingang zu ziehen.

Bei 24V auf einem einzelnen Panel-Eingang eines HM1500 kann dies aber dann durchaus problematisch werden.

Bestätigen kann ich auch dass die Stromerfassung dann aber nicht mehr richtig arbeitet, d.h. der Strom fließt aber der Messbereich endet vlt. einfach bei ~13A.

Wenn man sich hier einig ist müsste dies in der DPL Config auch so angewiesen und überhaupt möglich werden ?! Aktuell kann man nur einen einzelnen Channel auswählen für die Akkuverbindung: WRchannel

Hier sollte eigentlich NUR der Akku-WR angegeben werden mit dem Hinweis auch wirklich jeden MPPT mit dem Akku zu verbinden, WENN das Feature zur Skalierung angeboten werden muss/soll halt noch ein Feld für die MPPTs welche leider nicht verbunden sind, sehe das aber eigentlich nicht als sinnvoll/notwendig an. Zumindest bei 24V System sollte auch der Hinweis stehen besser auch jeweils beide Panel Eingänge jedes MPPTs zu verbinden.

Weiter gedacht: Gab es eigentlich schon mal überlegungen mehrere WR für Akkuverbindungen zu ermöglichen ? In erster Stufe z.b. einfach mal gleichmäßige Aufteilung der Sollgröße für Netzbezugskompensation auf alle Akku-WR.

In weiterer Stufe konfigurierbar über Schlüssel ( z.b. bei bekannter Schieflast und Aufteilung der WR auf mehrere Phasen ) oder in letzter "wünsch dir was" Instanz vlt. sogar pro Phase eine Regelung bei 3 WR.

Wenn mir jemand kurze Hints geben kann/möchte wo im Code ich da am ehesten unterwegs sein muss sowie zur Einrichtung Build-Umgebung könnte ich da auch selbst mal aktiv werden vlt. :)

Aktuell kann man nur einen einzelnen Channel auswählen für die Akkuverbindung

ich glaube, das ist die Vorgabe, wo der Wechselrichter die Batteriespannung hernehmen soll, damit die spannungsbasierte Start- und Stoppschwelle korrekt erkannt wird. An der Stelle gab es in der Vergangenheit diverse Überarbeitungen im Code. ggf. kann/sollte das wirklich raus...

Gab es eigentlich schon mal überlegungen mehrere WR für Akkuverbindungen zu ermöglichen ?

Ja. öfters. einfach mal in den Diskussionen und Issues suchen. Der Wunsch wurde schon öfter geäußert. Allerdings ist es noch nicht implementiert, da es mehrere Probleme mit sich bringt. unter anderem die Erhöhung der Regelzeit, da immer nur mit einem Wechselrichter kommuniziert werden kann und alle nacheinander abgefragt werden müssen.

In weiterer Stufe konfigurierbar über Schlüssel ( z.b. bei bekannter Schieflast und Aufteilung der WR auf mehrere Phasen ) oder in letzter "wünsch dir was" Instanz vlt. sogar pro Phase eine Regelung bei 3 WR.

Sowas gab es noch nicht. Ich bin mir auch gar nicht sicher, ob 3 einzelne Wechselrichter im Sinne der Schieflastverordnung erlaubt sind. Ein System aus mehreren Multiplus bspw., agiert als ein großer 3phasiger Wechselrichter. 3 einzelne Wechselrichter hingegen nicht unbedingt.

Another recommendation would be to have a fuse rated to the inverter SC current rating in each connected input. i.e separate fuse for each input. None of the Hoymiles inverters have fuses on the inputs, there is of course no need for this because a PV panel has max current in all conditions including fault.

kurzes Feedback noch von mir

ich habe dieses Amok-Verhalten bisher quasi nur beobachtet, wenn die Sonne fast vollständig weg ist. Mit der Schwelle von 2W ergäbe das Sinn - der Solarertrag liegt dann eventuell in diesem Bereich und der DPL ermittelt dann irgendwann die Kanalzahl falsch, da ein paar Kanäle minimal drunter und einige drüber liegen.

Das habe ich bei meinem HM-600 jetzt mal genauer beobachtet. Ja. in den aller frühsten Minuten kurz nach dem Starten des WR (auch kurz vorm Ausschalten am Abend), passiert das.

die obere gelbe Linie ist das gesetzte Limit (Skala links), rot und blau sind die DC Leistungen der beiden Eingänge (Skala rechts)

grafik

Wie man sieht, starten beide Eingänge < 2W, da skaliert er normal. Dann übersteigt der erste Eingang die 2W, er skaliert doppelt. der Eingang fällt wieder unter 2W, er skaliert normal. Das Ganze passiert noch 3 mal, bis beide Eingänge ab 07:48 Uhr > 2W liefern.

Ich wage aber zu bezweifeln, dass das falsche Limit hier ein signifikantes Problem darstellt, da die Modulleistung ja so oder so nicht mehr zulässt.

für ein Amok-Verhalten bedarf es ja mehr Leistung im Hintergrund. sei es aus einer Batterie, oder von den Modulen.

Auch hier um ~ 16:15 Uhr, wo es stark bewölkt war, sieht man dieses Verhalten. Ein Eingang fällt <2W, aber die Gesamtleistung beträgt so oder so nur 3-4W. grafik

Amok läuft die Regelung mMn. aktuell nur, wenn der Wechselrichter gestoppt ist und beim Wiedereinschalten ein viel zu hohes Limit, aufgrund der hier fälschlicher Weise genutzten Skalierung, gesetzt wird.

Man sieht hier aber auch, dass die WEchselrichter scheinbar nicht alle gleich sind. Im oberen Bild ist der HM-600 ja am Anfang noch aus. da zieht er auf den Eingängen ~0.8W und ~1.1W, das Limit ist in dem Moment noch korrekt. der HM-600 hätte also mit der aktuellen Regelung kein Problem beim Anlaufen und im Akkubetrieb.

dein HMT-2250 hingegen zieht auf String3 und String4 > 2W, auf den anderen nicht. Da greift die (falsche) Regelung/Skalierung 😄

Ja, richtig. Mit Paneln stellt sich das Problem kaum - wenn die Skalierung fehl schlägt ist eh keine Leistung da. Mit Akku allerdings sehr wohl. Deswegen habe ich das auch eher am Abend - am Morgen ist der Akku im Moment meistens leer. Da passiert dann genau, was du beschrieben hast: WR ist gestoppt, läuft mit falscher Skalierung und viel zu hoher Leistung wieder an, wird deswegen wieder gestoppt etc. Bisher hilft die Deaktivierung des Skalierens auch bei mir.

am Morgen ist der Akku im Moment meistens leer. Da passiert dann genau, was du beschrieben hast: WR ist gestoppt, läuft mit falscher Skalierung und viel zu hoher Leistung wieder an, wird deswegen wieder gestoppt etc.

das Stoppen könnte in dem Fall aber 2 Ursachen haben.

Auf der einen Seite haben wir den Effekt, dass die Befehle scheinbar nicht ankommen. Das Limit ist im ersten Schritt viel zu hoch (falsche Skalierung, wenn WR aus ist), im zweiten Schritt kommt der Befehl zum Reduzieren des Limits nicht an, im dritten Schritt wird der Wechselrichter gestoppt, da eine weitere "Reduzierung" für den DPL bedeutet, dass du < unteres Leistungslimit reduzieren müsstest. Das haben wir weiter oben im Logauszug nachvollzogen.

die zweite Stopp-Ursache könnte natürlich auch sein, dass der WR anläuft, aufgrund des meistens leer (niedriger SoC) die Spannung stark einbricht und der DPL aufgrund der niedrigen Spannung einfach wieder abschaltet. Das kann auch bei korrekter (oder fehlender) Skalierung passieren und ein Schwingen (AN/AUS/AN/..) verursachen. Der Spannungseinbruch ist last- und SoC-abhängig.

und, wo du es sagst:

Ja, richtig. Mit Paneln stellt sich das Problem kaum

und

ich habe dieses Amok-Verhalten bisher quasi nur beobachtet, wenn die Sonne fast vollständig weg ist

hast du einen Akku? Dann sollte es bei dir ja nicht sonnenabhängig sein 😄

am Morgen ist der Akku im Moment meistens leer. Da passiert dann genau, was du beschrieben hast: WR ist gestoppt, läuft mit falscher Skalierung und viel zu hoher Leistung wieder an, wird deswegen wieder gestoppt etc.

Sorry, war zu schnell. Am Morgen passiert das deswegen NICHT. Ich habe das Problem bisher nur am Abend.

Auf der einen Seite haben wir den Effekt, dass die Befehle scheinbar nicht ankommen. Das Limit ist im ersten Schritt viel zu hoch (falsche Skalierung, wenn WR aus ist), im zweiten Schritt kommt der Befehl zum Reduzieren des Limits nicht an, im dritten Schritt wird der Wechselrichter gestoppt, da eine weitere "Reduzierung" für den DPL bedeutet, dass du < unteres Leistungslimit reduzieren müsstest. Das haben wir weiter oben im Logauszug nachvollzogen.

Eventuell liegt es auch (mit) daran, das der WR erstmal eine Rampe fährt bis er die geforderte hohe Leistung überhaupt erreicht. Wie gut die DPL dem Rechnung trägt, weis ich im Moment noch nicht.

die zweite Stopp-Ursache könnte natürlich auch sein, dass der WR anläuft, aufgrund des meistens leer (niedriger SoC) die Spannung stark einbricht

Ne, der Akku hat 10kWh, kann problemlos 200A Entladestrom und der Hoymiles zieht max. 45A. Ich entlade auch nur bis 15% SOC. Der SOC läuft aber immer monoton - da sind keinerlei Sprünge unter Last zu beobachten. Die Spannung wird nicht beachtet - die werte ich nur übergeordnet aus, um - falls der WR mal nicht korrekt abgeschaltet wird - den WR ganz vom Netz zu nehmen. Diese Grenze ist aber ein deutliches Stück entfernt und hat noch nie ausgelöst.

ich habe dieses Amok-Verhalten bisher quasi nur beobachtet, wenn die Sonne fast vollständig weg ist hast du einen Akku? Dann sollte es bei dir ja nicht sonnenabhängig sein 😄 Doch, denn ich decke meinen Grundbedarf mit einem weiteren ungeregelten Hoymiles und weiteren Panels. Der Hoymiles hat daher nur was zu tun, wenn noch Zusatzbedarf im Haus ist. Am Abend häufen sich die Starts dabei allmählich, da die Deckung des anderen WR langsam verschwindet und bei Lastwechseln häufiger gestartet/gestoppt wird. Aber ja - du hast in recht, das der WR zumindest meistens auf recht viel Leistung zugreifen kann. Es scheint damit häufiger aufzutreten, wenn viele Start/Stopps kommen und der WR oft bei niedrigen Leistungen pendelt.

@hhoebel Ich behaupte dein Problem ist mit #725 oder spätestens mit b0795a21310ec04a05b96736b5e9c11e698c77ee behoben. Diese Änderungen sind in Version 2024.03.07 enthalten. Ist dieses Issue damit erledigt?

Ja, ich denke schon. Soweit ich die Code-Änderungen bisher nachverfolgt habe, sollte das keine Probleme mehr an dieser Stelle geben. Bei meinem HMT2250 kommt ja dann gar keine Skalierung mehr zum Einsatz, wenn ich das richtig gesehen habe :-) Das Release funktioniert bisher auf jeden Fall ohne Probleme. Danke dafür!

Danke für die Rückmeldung, @hhoebel.

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.

hoylabs / OpenDTU-OnBattery