False number of producing channels #697
Comments
|
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: ’’’ 16:52:32.779 > [DPL::loop] ******************* ENTER ********************** 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. |
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, 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. |
Da bin ich aber sehr erleichtert 😉
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:
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 :-) |
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 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?
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.
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.
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.)
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. 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?)
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?
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.
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.
Ich würde es auch begrüßen, wenn die Anzahl der produzierenden Kanäle nur ermittelt werden wenn:
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.
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.
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.
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.
|
|
Hier mal das beste Beispiel warum die aktuelle Kanalzählung / Skalierung nicht richtig funktioniert (Inverter ist gerade im Standby): |
|
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. |
|
Hallo zusammen! 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. 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 |
|
Andrix82, wenn du die Zeichnung in einen Codeblock packst, zerreißt es die Formatierung nicht :)
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 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.
Das entspricht auch meinen Kenntnisstand.
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. Als Formel in etwa so: P_wr = (P_ziel - Summe(P_nicht_begrenzte_mppt))*Anzahl_MPPT hier eben (300-40)*2 oder 520W. |
|
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. 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. 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. Wenn man sich hier einig ist müsste dies in der DPL Config auch so angewiesen und überhaupt möglich werden ?! 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. Weiter gedacht: 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. :) |
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...
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.
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. |
|
kurzes Feedback noch von mir
Das habe ich bei meinem HM-600 jetzt mal genauer beobachtet. die obere gelbe Linie ist das gesetzte Limit (Skala links), rot und blau sind die DC Leistungen der beiden Eingänge (Skala rechts)
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 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.
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. |
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. die zweite Stopp-Ursache könnte natürlich auch sein, dass der WR anläuft, aufgrund des und, wo du es sagst:
und
hast du einen Akku? Dann sollte es bei dir ja nicht sonnenabhängig sein 😄 |
Sorry, war zu schnell. Am Morgen passiert das deswegen NICHT. Ich habe das Problem bisher nur am Abend.
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.
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.
|
|
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 :-) |
|
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. |
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
Anything else?
No response
The text was updated successfully, but these errors were encountered: