Betrieb ohne Batterie zur Nulleinspeisung

[micw]

Hallo zusammen,

ich bin auf das Projekt aus einem Thread aus dem originalen OpenDTU zur Nulleinspeisung gestoßen und würde gern wissen, ob es möglich ist, das damit zu realisieren, so dass auf ein externes Script zur Nulleinspeisung verzichtet werden kann.

Aus meiner Sicht dürfte im Projekt so ziemlich alles vorhanden sein, was benötigt wird (Regelung des Inverters mit Regelkreis, Bezug der Stromzähler-Daten).

Ich habe aktuell die folgenden Einstellungen und es scheint zumindest prinzipiell irgendwas zu regeln (leider heute nicht testbar mangels Sonne):

Was genau bedeutet "Solar Passthrough"?

Könnte man auch den zweiten Inverter in die Regelung einbeziehen?

Viele Grüße,
Michael.

[micw]

Ich habe inzwischen gesehen, dass es das Limit auf den aktuellen Netzbezug abzüglich des Outputs des 2. Inverters regelt, was genau dem entspricht, was ich mir vorgestellt habe.

Etwas irritierend sind die batteriebezogenen Felder, wenn keine Batterie angeschlossen ist. Welche davon werden benötigt (Kanal?, DC-Spannung?) und welchen Effekt haben sie?

[micw]

Bin leider nur "halb schlau" geworden. DC Spannung auf 0...50 klappt bei mir. Hätte angenommen, das muss über/unter der Spannung vom Modul liegen, damit es nicht abschalten. Warum steht dann aber in dem Ticket als Empfehlung 1/10 V? Sollte man lieber 0/0V reinschreiben?

Die Bedeutung vom Kanal ist mir auch nicht klar. Die verstehe ich nichtmal im Kontext des Betriebs mit einer Batterie. Die würde doch samt Laderegler an AC hängen, oder? Oder betreibt ihr sonst die Batterie direkt am Hoymiles?
Edit: hab's glaube ich gerade verstanden. Wird hier der Hoymiles statt mit Solarzellen als Inverter mit einer Batterie betrieben?

[helgeerbe]

Wird hier der Hoymiles statt mit Solarzellen als Inverter mit einer Batterie betrieben?

Jo, eigentlich sogar parallel. Ich muss wirklich mal eine Zeichnung machen. Die Panels hängen am Laderegler, der MPPT lädt die Batterie. Parallel hängt da auch der Inverter dran. Je weiter ich den Inverter aufdrehe, um so weniger wird die Batterie geladen.

So funktioniert dann auch SolarPassthrough. Die Leistung die am Panel anliegt, wird 1:1 über PowerLimit an den inverter gegeben.

PV	Inverter	Batterie
100	100	0
100	50	50
100	0	100

Wenn ich also den Inverter entsprechend der Leistung am Panel begrenze, geht der Strom in den Inverter, die Batterie wird nicht belastet (aber auch nicht geladen). Damit spare ich mir die Leistungsverluste beim Speichern vom Strom, wenn ich ihn gleich verbrauchen kann.
Nur wenn ich Strom exportieren würde, begrenze ich den Strom am Inverter und der Überschuss wird in die Batterie eingespeist.

[micw]

D.h. Batterie + Panels am WR? Kommt der damit klar? Kann ich an den 4 Anschlüssen eines HM-1500 eine Batterie und 3 Module anschließen?

Welche Spannungen und Ströme lassen sich damit relaisieren? Kann ich mit einem HM-1500 1,5kW Leistung aus einer Batterie abrufen?

Eine Zeichnung wäre genial. Im Readme ganz oben sollte vielleicht auch stehen, was das Projekt macht ;-)

[helgeerbe]

D.h. Batterie + Panels am WR? Kommt der damit klar? Kann ich an den 4 Anschlüssen eines HM-1500 eine Batterie und 3 Module anschließen?

Der Wechselrichter kommt damit klar. Es liegen dann in meinem Falle (24V Batterie) ca. 22-27V an.

Welche Spannungen und Ströme lassen sich damit relaisieren? Kann ich mit einem HM-1500 1,5kW Leistung aus einer Batterie abrufen?

Aber der Hoymiles zieht maximal 10.5 A pro Eingang (24 V * 10.5A = 252W). D. h. ich komme bei meinem HM-300 nur auf maximal 252 W.

Beim HM-600 mit beiden Eingängen sind es ca. 500W. Mehr als 600W darf ich aus meiner Batterie nicht ziehen. Hier wären dann 48V Batterien besser geeignet.

Eine Zeichnung wäre genial. Im Readme ganz oben sollte vielleicht auch stehen, was das Projekt macht ;-)

ist in Gedanken schon fast fertig ;)

[micw]

D.h. Batterie + Panels am WR? Kommt der damit klar? Kann ich an den 4 Anschlüssen eines HM-1500 eine Batterie und 3 Module anschließen?

Der Wechselrichter kommt damit klar. Es liegen dann in meinem Falle (24V Batterie) ca. 22-27V an.

Auch im Mischbetrieb mit Solarpanel und Batterie am selben Tracker? Fängt dann nicht das Panel an, die Batterie zu laden?

Welche Spannungen und Ströme lassen sich damit relaisieren? Kann ich mit einem HM-1500 1,5kW Leistung aus einer Batterie abrufen?

Aber der Hoymiles zieht maximal 10.5 A pro Eingang (24 V * 10.5A = 252W). D. h. ich komme bei meinem HM-300 nur auf maximal 252 W.

Beim HM-600 mit beiden Eingängen sind es ca. 500W. Mehr als 600W darf ich aus meiner Batterie nicht ziehen. Hier wären dann 48V Batterien besser geeignet.

Kann man die Batterie dann an 2 Eingänge anschließen? Oder (beim HM-1500) an 4 Eingänge parallel? Kommen die Tracker damit zurecht?

Wie funktioniert das beim Pass-Through? Batterie voll mit 27V, Solarpanel liefert wegen schlechtem Wetter weniger als 27V, Limit ist auf Ertrag vom Panel gestellt -> würde doch die Batterie entladen und nicht vom Panel nehmen, oder?

Wie schaut es beim Laden der Batterie aus? Dann liegt dort ja eine höhere Spannung an. Wird die nicht vom WR gleich wieder ins Netz eingespeist?

[helgeerbe]

Der Strom sucht sich den Weg des geringsten Widerstandes. Wenn die Panels mehr Strom liefern, als der Inverter verbraucht, wird die Batterie geladen. Bei Solarpasstrhough wird der Inverter immer nachgeregelt. Zumindest bis zum oberen Limit.

Sonne 100 W -> Inverter auf 100W -> keine Ladung der Batterie
Sonne 200 W -> Inverter bleibt bei 100 W -> 100 W geht in die Batterie

Ich habe z. B. 300 W als oberes Limit. Liefert die Sonne nun 600 W gehen 300 W in die Batterie.

[helgeerbe]

Du kannst eine Batterie an mehrere Anschlüsse anschliessen. Allerdings must du schauen, dass du deine Batterie nicht überlastest. D. h. es kommt auf die Leistung an, die du aus der Batterie ziehen darfst. Ferner zieht der Hoymeils meines Wissens maximal 10.5 A pro Anschluss. Bei einer 24 V Batterie sind es 24 V * 10,5A * 4 = 1008W D. h. du verschenkst fast 500W. Bei einer 48 V Batterie sind es 48 V * 10,5 A * 4 = 2016 W. D. h. du kannst den Inverter voll ausreizen.

[helgeerbe]

Wie funktioniert das beim Pass-Through? Batterie voll mit 27V, Solarpanel liefert wegen schlechtem Wetter weniger als 27V, Limit ist auf Ertrag vom Panel gestellt -> würde doch die Batterie entladen und nicht vom Panel nehmen, oder?

Da hast du einen Denkfehler. Solarpanel liefert 20 W wegen schlechten Wetters. Der Inverter wird auf 20 W limitiert. Dh. es werden 20 W vom Panel genommen. D. h. es wird immer von der OpenDTU nachgeregelt. Dann ist es egal wie voll die Batterie ist.

Wenn du auf Batteriebetrieb gehst, wird trotzdem die Leistung vom Panel mit berücksichtig wird. Also inverter auf 200 W gesetzt, Panel liefert 50 W, dann wird die Batterie mit 150 W belastet.

[micw]

Solarpanel liefert 20 W wegen schlechten Wetters. Der Inverter wird auf 20 W limitiert. Dh. es werden 20 W vom Panel genommen. D. h. es wird immer von der OpenDTU nachgeregelt. Dann ist es egal wie voll die Batterie ist.

Warum werden die 20 W nicht aus der Batterie genommen?

[micw]

PS: Vielleicht hilft da doch erstmal die Grafik ;-)

[micw]

Eine Möglichkeit wäre, die Grafik in draw.io zu malen und mit ins Repo einzuchecken. Die kann dann direkt über draw.io gerendert und ins README eingebunden werden: https://github.com/jgraph/drawio/wiki/Embed-Diagrams

[helgeerbe]

Warum werden die 20 W nicht aus der Batterie genommen?

Ich vermute mal das hat was mit dem Kirchhofschen Gesetz zu tun:
In einem Knotenpunkt ist die Summe der zufließenden Ströme gleich der Summe der abfließenden Ströme.

Natürlich könnte der Strom in die Batterie und dann in den Inverter fliessen. Aber da vermute ich, dass der Strom den Weg des geringsten Widerstandes geht.

Aber ich bin nur Informatiker und kein Elektrotechniker

[micw]

Mal ein kurzes Update. Das Wetter war passend, ich konnte die Einspeiseregelung testen:

Es gibt eine gewisse Verzögerung, so dass nicht NULL rauskommt. Aber es ist recht gut dran.

Hier die Module dazu, Sonne war in der Zeit seht konstant.

Nur Modul 2.1 und 2.2 wurden geregelt, die laufen zusammen an einem Inverter. Vor 9:50 hatte ich den anderen Inverter gewählt, auch der wurde korrekt geregelt, solange ich den mit Südausrichtung auf die Grundlast reduziert habe.

Hier kommt auch schon ein Problem zum tragen. Früh bis Mittag habe ich auf dem 2.* Modulen Sonne, Mittag und Nachmittag auf den 1* Modulen. Geregelt werden kann nur einer der WR.

Hier noch ein Bild ohne die Regelung zum Vergleich:

[helgeerbe]

Den zeitlichen Versatz wirst du nicht rausbekommen. Aber ich denke, damit kann man leben. Ist eben keine Echtzeitsteuerung.

An mehreren Ladereglern werde ich noch arbeiten. Mehrere Wechselrichter zu steuern wäre auch cool. Aber da bräuchte man noch mal ein Konzept. Alle gleich, einen bevorzugt......... Wenn du also Zeit hast und Entwickeln kannst immer gerne. Auch die Doku zu verbessern hilft ;)

[mawa85]

Hi zusammen, danke für den Hinweis auf die bestehende Diskussion. Ich habe das gleiche Ziel, meine Dynamic Power Inverter Settings Seite sieht aber etwas anders aus und egal was ich einstelle, der Wechselrichter schaltet immer ab (Shut down by remote control
). Bin auf dem aktuellen Stand was die Version angeht.

Die Leistungswerte vom Hausstromzähler sende ich per MQTT und die werden auch in den Live-Daten angezeigt

[bf4ed]

Ich hab das gleiche Problem. Ohne Batterie funktioniert das irgendwie nicht.

Soll jemand alle Einstellungen genau angeben was alles zu einstellen ist.

Oder ein extra Menü für Netzbetrieb ohne Batterie.

[zapfs]

Hi zusammen, danke für den Hinweis auf die bestehende Diskussion. Ich habe das gleiche Ziel, meine Dynamic Power Inverter Settings Seite sieht aber etwas anders aus und egal was ich einstelle, der Wechselrichter schaltet immer ab (Shut down by remote control ). Bin auf dem aktuellen Stand was die Version angeht.

Die Leistungswerte vom Hausstromzähler sende ich per MQTT und die werden auch in den Live-Daten angezeigt

Auch bei mir gleiches Verhalten ohne Batterie.
(Ich nutze Leistungswerte von Shelly 3EM, die in der Live-View auch angezeigt werden)

Was ich auch immer im Power-Limiter einstelle - der Wechselrichter schaltet sofort ab, wenn ich die Settings speichere.

Hat jemand eine Idee?

[bf4ed]

Hmmm... jetzt spiele ich wieder damit ich vermute wo das Problem bei mir ist.

Hab einen HM-1500 und nur 2 Panels. Wenn mein Verbrauch 100W ist, regelt er auf 100W, aber weil der nur 2 Panels hat ist der Ausgang nur die Hälfte 50W. Und dann nach paar Sekunden regelt er erneut und so kann er sich nicht stabilisieren.

Ich muss noch 2 Panels montieren und dann melde ich mich erneut.

Das sind meine Einstellungen:

[zapfs]

Auch bei mir gleiches Verhalten ohne Batterie.
(Ich nutze Leistungswerte von Shelly 3EM, die in der Live-View auch angezeigt werden)

Was ich auch immer im Power-Limiter einstelle - der Wechselrichter schaltet sofort ab, wenn ich die Settings speichere.

Hat jemand eine Idee?

[bf4ed]

Ab heute funktioniert das bei mir perfekt. Hab gestern noch 2 Panels montiert. Hab jetzt alle 4 Eingänge angeschlossen bei HM-1500.

Ich hab jetzt nur die eine Phase bei Power meter eingeschaltet in die ich auch einspeise.

Meine Einstellungen sind folgende:

Enable Solar-Passtrough: OFF
Target power consumption from grid: -20W
Hysteresis for power consumption from grid: 10W
Lower power limit: 10W
Upper power limit: 1500W

Inverter is behind Power meter: ON

DC Voltage - Start threshold: 10V
DC Voltage - Stop threshold: 1V
DC Voltage - Load correction factor: 0.001

Probiere meine Einstellungen.

[zapfs]

Danke für die schnelle Antwort. Ich habe nur 3 Panels (je 405 W).

Mit Deinen Werten sieht es besser aus. Der WR bekommt ein Limit und schaltet nicht sofort aus.
Ich werde das jetzt mal beobachten.

[mawa85]

@bf4ed vielen Dank, mit deinen Einstellung wird zumindest schonmal geregelt.

Komischerweise habe ich seit Aktivierung der Regelung Inverter Shutdowns im Log.

Ideal wäre noch eine Möglichkeit, die Regelung erst bei einer bestimmten Inverterleistung anzusetzen also zB. bei weniger al 600W Gesamtleistung ungedrosselt die Limits komplett rauszunehmen. und erst bei höherer Leistung die Drosselung zu beginnen

[breuerm710]

Ich hatte das Problem auch. Grund war wohl das ich zwei kleine BKWs habe und nur eins hat eine Hoymiles WR. Wenn das andere allein schon mehr als die Grundlast, über alle drei Phasen sumiert, geleistet hat, wurde das BKW mit dem Hoymiles zwar runter geregelt, aber gleichzeitig gab es den shutdown (ist vielleicht ein bug oder liegt daran, das ich noch keine Batterie habe). Da die beiden BKWs auf unterschiedlichen Phasen liegen, habe ich nur die Phase mit dem Hoymiles WR und die Phase ohne BKW im Power Meter definiert. Damit kann die Summe über die beiden Phasen nicht mehr negativ sein, wenn der Hoymiles runter regelt und seit dem funktioniert die Regelung auch ohne den Shut down auszulösen.

[ghost]

Guten Tag, das Problem habe ich auch. Es sollte einen eigenen Schalter für die Nulleinspeisung ohne Laderegler geben, die auch berücksichtigt das eine weitere ungeregelte Anlage über den Stromverbrauch hinaus ins Netz drücken kann.
Die ganzen Spannungsangaben bzw. dafür unnötigen Eingabefelder können somit aus dem Menue verschwinden sobald diese Funktion eingeschaltet ist.

Daher die Abschaltung des Hoymiles Inverters muss dafür blockiert werden und er darf nur auf das eingestellte Minimum zurück regeln. Ist der aktuelle Verbrauch 100 W und die ungeregelte Anlage bringt 120W und beim geregelten Hoymiles sind als minimum 20W eingestellt. Dann liefert er weiterhin seine min 20W so das eine Einspeisung von 40W erfolgt ohne Inverter shutdown. Das Problem ist nämlich das der Inverter sonst ständig in den Shutdown geschickt wird und er erwacht leider nur sehr langsam aus dem Shutdown.

[Tiese]

Daher die Abschaltung des Hoymiles Inverters muss dafür blockiert werden und er darf nur auf das eingestellte Minimum zurück regeln. Ist der aktuelle Verbrauch 100 W und die ungeregelte Anlage bringt 120W und beim geregelten Hoymiles sind als minimum 20W eingestellt. Dann liefert er weiterhin seine min 20W so das eine Einspeisung von 40W erfolgt ohne Inverter shutdown. Das Problem ist nämlich das der Inverter sonst ständig in den Shutdown geschickt wird und er erwacht leider nur sehr langsam aus dem Shutdown.

Deshalb habe ich mir einen OpenDTU-Client gebaut (Prototyp - suche Tester).
Das ist ein zweiter ESP32, der unabhängig einen Wechselrichter steuert, der in OpenDTU eingebunden ist :-)
Und noch weitere Extras hat :-)) - siehe hier

[oszi-xx]

Hallo an alle
ich hbe eine frage zum Abfrageintervall des Stromzählers. Kann man den Abfrageintervall irgenwo einstellbar machen (< 10 sec) ?

[spcqike]

Der wert sollte in der config stehen.

Versuch mal die config zu exportieren. Dann kannst du den Wert anpassen und wieder importieren.

[oszi-xx]

Super
Danke hat funktioniert

[schlimmchen]

Siehe #669.

[MatzeMuc86]

Ich bekomme die Nulleinspeisung ohne Batterie leider nicht erfolgreich zum Laufen. Ich habe es sowohl mit den Einstellungen hier wie auch in der offiziellen Doku (andere Werte!) probiert. Der Wechselrichter beendet die Produktion leider immer - mal früher (1 Minute) mal später (1h). Setup ist ein Balkonkraftwerk hinter Stromzähler ohne Specials.

[spcqike]

kann es sein, dass dein "unteres leistungslimit" auf 800W steht? oder anderweitig hoch ist?

[MatzeMuc86]

Ja Limits sind 800 bis 2000 als Test. Warum?
Das sollte ja möglich sein wenn ich es richtig verstehe. Auch gemäß Doku.

[spcqike]

das ist dein Problem. das "untere LImit" ist kein "bitte immer speise mindestens 800W ein" sondern "speise erst ein, wenn du mindestens 800W einspeisen musst".

in deinem Log sieht man aber, dass du zum Zeitpunkt des ausschaltens keine 800W benötigst.

13:53:07.381 > [DPL::loop] ******************* ENTER ********************** 
13:53:07.456 > [DPL::loop] battery interface disabled, SoC: 0 %, StartTH: 80 %, StopTH: 20 %, SoC age: 89859 s, ignore: no 
13:53:07.514 > [DPL::getBatteryVoltage] BMS: -1.00 V, MPPT: -1.00 V, inverter: 43.30 V, returning: 43.30V 
13:53:07.593 > [DPL::loop] dcVoltage: 43.30 V, loadCorrectedVoltage: 43.59 V, StartTH: 1.00 V, StopTH: 0.00 V 
13:53:07.705 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is producing 
13:53:07.938 > [DPL::loop] SolarPT disabled, Drain Strategy: 0, canUseDirectSolarPower: no 
13:53:08.027 > [DPL::loop] battery discharging allowed, PowerMeter: 254 W, target consumption: -30 W 
13:53:08.363 > [DPL::commitPowerLimit] Stopping inverter... 
13:53:08.450 > [DPL::loop] ******************* Leaving PL, calculated limit: 575 W, requested limit: 800 W (updated from calculated) 
13:53:09.541 > Success 
13:53:11.603 > Success 
13:53:11.658 > [DPL::commitPowerLimit] Stopping inverter... 

der DPL berechnet, dass du nur 575W erzeugen müsstest, um dein Ziel von -30W zu erreichen. Daher schaltet er aus.

Stell dein unteres Limit auf 20W oder 30W, dann speist er auch entsprechend ein.

[MatzeMuc86]

Unteres Limit muss mindestens 50 sein => schade aber der Grundverbrauch liegt sowieso höher. Das Limit ist ja der BEDARF und nicht was die PV Anlage kann, korrekt?
Gibt es eine Möglichkeit auch mindestens x W einzuspeisen so wie ich es verstanden hatte?
Macht es ggf. Sinn die Doku bzgl. Verständlichkeit und auch der korrekten Werte anzupassen?

[spcqike]

Das Limit ist ja der BEDARF und nicht was die PV Anlage kann, korrekt?

korrekt

Gibt es eine Möglichkeit auch mindestens x W einzuspeisen so wie ich es verstanden hatte?

bisher nicht. wurde schon öfter angefragt, aber ist so nicht hinterlegt

Macht es ggf. Sinn die Doku bzgl. Verständlichkeit und auch der korrekten Werte anzupassen?

Das Projekt ist Open Source, mitarbeit ist gern gesehen. Wenn du Verbesserungspotential siehst, darfst du es gerne einbringen 😄

[firedp]

Hallo. Ich sehe gerade etwas, was ich wohl gerne möchte. Habe zwei hm-600 mit bald je zwei Modulen, aktuell habe ich das 4. Modul noch in der Garage.

Kann ich jetzt die WR dynamisch selber begrenzen lassen ohne auffällig viel ins Netz einspeisen zu müssen oder wie jetzt statisch zu begrenzen?
Welcher Lesekopf wäre am besten?
Sollte man nur einen hm-600 drosseln oder beide zeitgleich? Wenn ich 150W brauche, theoretisch 2x600W produziere (eher unrealistisch) würde ich nur einen so einbremsen das noch 500W ins Netz verschenkt werden.
Nur würde ich das volle Süd BKW dann drosseln oder das NO/SW BKW?

[spcqike]

bisher kann die openDTU-onBattery nur einen Wechselrichter dynamisch regeln.

Welcher Lesekopf wäre am besten?

kommt auf dein Smartmeter bzw. eher auf dein restliches System (Smart Home) und deine Bastelaffinität an. Ich verwende einen einfach esp8266 mit einem IR-Empfänger, den ich vor den Zähler gehangen habe. andere kaufen fertige "Hichi", die am Ende nichts anderes sind, oder bauen einen neuen Shelly ein.

Sollte man nur einen hm-600 drosseln oder beide zeitgleich

die openDTU-oB kann nur einen dynamisch regeln.

Nur würde ich das volle Süd BKW dann drosseln oder das NO/SW BKW?

ich würde das NO/SW voll einspeisen lassen. Da wirst du die 600W alleine wahrscheinlich nie sehen. Dann das Süd BKW mit dynamischer Drosselung auf Nulleinspeisung gehen.
Wenn das NO/SW BKW deinen aktuellen Bedarf deckt, würde das Süd BKW gestoppt, so dass du nur den Überschuss aus dem nicht gedrosselten NO/SW BKW einspeist. wenn dies deinen Bedarf nicht alleine deckt, würde das Süd BKW dazu "geholt" und deinen Bedarf mit abdecken.

[firedp]

Hallo spcqike.
Wie Du schreibst, dachte ich es mir ähnlich, das Süd zu steuern.
Derzeit habe ich ausschließlich ein openDTU und ein AhoyDTU laufen. Zwei verschiedene aus Spaß am Basteln.
Bevorzugen würde ich einen Lesekopf für den smarten Zähler.
Basteln tue ich gerne, aber halt nur nach Anleitungen. Habe die DTU Teile selber bei Ali gekauft, verkabelt und geflasht.
Aber ich habe kein Smarthome oder ähnliches. Meine Hoffnung lag eher darauf, das der Lesekopf direkt mit der DTU kommuniziert und ich nicht noch etwas dazwischen schalten müsste.
Also läuft es nur so ähnlich wie Smart Micro Solar?

[spcqike]

Hallo firedp

wenn du Spaß am Basteln und Lernen hast, kannst du dir mit einem ESP deiner Wahl und Tasmota eine Auswerteeinheit für deinen Stromzähler bauen. Wenn es bereits ein digitaler ist, kannst du sowohl die Impulse auswerten, als auch (vielleicht) die D0 Schnittstelle direkt abgreifen. Bei nem analogen Ferrariszähler .... naja, da müsste man mehr basteln, und es wäre bei weitem nicht so genau und schnell ... Da würde ich dann eher einen Shelly dazu einbauen (lassen)

https://tasmota.github.io/docs/Smart-Meter-Interface/#smart-meter-interface

Dieses Tasmotadevice (oder den Shelly) kannst du dann von der openDTU-oB direkt abfragen lassen. (PowerMeter HTTP(S)+JSON https://github.com/helgeerbe/OpenDTU-OnBattery/wiki/Power-Meter)

Dann hast du nur das WLAN als Schnittstelle dazwischen.

[firedp]

Danke, dann fange ich mal die nächsten Tage an mit der Weiterbildung. Mit über 50 will man ja nicht ganz abgehangen werden :-)

[firedp]

So, so ein Lesekopf habe ich fertig gekauft mit Tasmota 12.3.1 drauf
Schnell noch ne Hutschienensteckdose eingebaut und mit der leichten Anleitung von diesem Hichi Ding konnte ich beim ersten Versuch meine Zählerwerte auf dem PC sehen.
Mit dem Open DTU on Battery hatte ich unerwartet Empfangsprobleme zum hm-600. Mit maximaler Antennenleistung wird aber jetzt alle 7-10 Sekunden aktualisiert und geht nicht mehr offline.
Dann war ich so richtig Jungfrau die Zählerwerte an on Battery weiterzuleiten. Wie immer nicht viel verstanden, aber mit HTTP(S) + JSON habe ich auch das hinbekommen, wird in Live-Ansicht angezeigt, kopieren kann ich :-)
Aber hat einer einen Link oder Tips zu funktionierenden Einstellungen?
Bei Stromzähler weiß ich nicht was „individuelle HTTP request pro Phase“ bewirkt und „Timeout“ 1000.
Bei DPL sind und anderswo sind „Ausführliche Protokollierung“ aus.
Wenn ich einen hm-600 habe, ist das obere Limit legal/egal?
Welche Tips für eine schnelle Regeltechnik habt ihr noch für einen alten Mann?

[Janorei]

Hallo zusammen,
ich bin mir nicht ganz sicher, ob ich hier im richtigen Thread bin, aber zumindest der Überschrift nach ist es das was ich machen will.
Ich bin erst am Anfang mit der DTU und habe jetzt schon ein wenig gelesen und herumprobiert. Auch ich habe das Problem. daß mit des öfteren der HM in Shutdown geht, seit dem ich dem Power Limiter verwende. Ich habe die DTU jetzt mal so positioniert und von der Sendeleistung eingestellt, daß ich deutlich weniger Übermittlungsfehler bekomme (apropos Sendeleistung: "Nicht immer gilt viel hilft viel ;-) )
Eine meiner ersten Fragen ist: Wie wird eigentlich die "requested Leitsung" berechnet ?
Ich werde aus meinem Trace nicht schlau:
16:15:11.468 > [DPL::loop] ******************* ENTER **********************
16:15:11.670 > [DPL::loop] battery interface disabled, SoC: 0 %, StartTH: 80 %, StopTH: 20 %, SoC age: 1058 s, ignore: no
16:15:11.776 > [DPL::getBatteryVoltage] BMS: -1.00 V, MPPT: -1.00 V, inverter: 40.50 V, returning: 40.50V
16:15:11.831 > [DPL::loop] dcVoltage: 40.50 V, loadCorrectedVoltage: 40.53 V, StartTH: 1.00 V, StopTH: 0.00 V
16:15:11.910 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is producing
16:15:12.185 > [DPL::loop] SolarPT disabled, Drain Strategy: 0, canUseDirectSolarPower: no
16:15:12.252 > [DPL::loop] battery discharging allowed, PowerMeter: 239 W, target consumption: -20 W
16:15:12.301 > [DPL::setNewPowerLimit] requested: 287 W, last limit: 283 W, diff: 4 W, hysteresis: 25 W, age: 43324 ms
16:15:12.358 > [DPL::loop] ******************* Leaving PL, calculated limit: 287 W, requested limit: 283 W (kept last requested)

239 W + abs(-20) W = 259 W requested ist aber 287 W . Wo kommt die Differenz von 28 W her

Habe dann mal rumgespielt

6:44:45.443 > [DPL::loop] ******************* ENTER **********************
16:44:45.487 > [DPL::loop] battery interface disabled, SoC: 0 %, StartTH: 80 %, StopTH: 20 %, SoC age: 23 s, ignore: no
16:44:45.538 > [DPL::getBatteryVoltage] BMS: -1.00 V, MPPT: -1.00 V, inverter: 39.30 V, returning: 39.30V
16:44:45.751 > [DPL::loop] dcVoltage: 39.30 V, loadCorrectedVoltage: 39.31 V, StartTH: 1.00 V, StopTH: 0.00 V
16:44:45.805 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is producing
16:44:45.875 > [DPL::loop] SolarPT disabled, Drain Strategy: 0, canUseDirectSolarPower: no
16:44:45.953 > [DPL::loop] battery discharging allowed, PowerMeter: 157 W, target consumption: 0 W
16:44:46.005 > [DPL::setNewPowerLimit] requested: 170 W, last limit: 172 W, diff: 2 W, hysteresis: 25 W, age: 13368 ms
16:44:46.052 > [DPL::loop] ******************* Leaving PL, calculated limit: 170 W, requested limit: 172 W (kept last requested)

hier kommt eine Differenz von 13 W raus.

Frage 1: Wie wird eigentlich die "requested Leistung" berechnet ?
Frage 2: welche optimale Einstellung gibt es für den Powerlimiter, damit der WR (HM 800) auf keinen Fall ausgeschaltet wird sondern notfalls halt einfach ein wenig einspeist ?

[schlimmchen]

Frage 1: Wie wird eigentlich die "requested Leistung" berechnet ?

Das ist keine einfache Frage, der DPL ist einigermaßen komplex. Ich stimme dir aber zu, dass das eine merkwürdige Abweichung ist... Kannst du C/C++ Code lesen? Ah, hier: Vom Wert, den der Stromzähler meldet, wird die zuletzte gemeldete Ausgangsleistung des Inverters abgezogen. Da die nicht (immer) dem eingestellten Leistungslimit entspricht, gibt es da eine Differenz.

Frage 2: welche optimale Einstellung gibt es für den Powerlimiter, damit der WR (HM 800) auf keinen Fall ausgeschaltet wird sondern notfalls halt einfach ein wenig einspeist ?

Die gibt es nicht. Aber das wurde die letzten zwei Wochen so häufig gefragt, dass ich mir was ausgedacht habe: Wäre für dich ein Schalter ausreichend, der dafür sorgt, dass der Inverter nicht in den Shutdown geht, sondern auf das "minimale Leistungslimit" eingestellt wird?

[spcqike]

Ich meine die Differenz ist einfach das, was der WR bereits einspeist.

Im log sehen wir mir den powermeter (hier Netzbezug) und das Ziel. Nicht aber das, was bereits selbst erzeugt wird.

Angenommen man produziert bereits 100W, zieht noch 100W aus dem Netz und will 0W erreichen, braucht man natürlich ein Limit von 200W. Da 200W ja der aktuelle Gesamtverbrauch ist.

Das gilt wohl nur für nicht Batterie Systeme. Bei einer Batterie sollte das letzte Limit natürlich der aktuellen Einspeisung entsprechen. Da bleiben dann die kleinen Ungenauigkeiten aufgrund unterschiedlicher Zweitstempel / Versatz beim abfragen des powermeters und des inverters.

@schlimmchen
Ich vermute genau so ein Schalter wäre perfekt für 95% der Benutzer, da die meisten (mich eingeschlossen) das „untere Limit“ im DPL genau so verstehen am Anfang :)

[Janorei]

Frage 1 : ok, das heißt für mich halt einfach, das die im Trace ausgegebenen Werte nicht ausreichen um das Ergebnis exakt nachzurechnen, sondern das da auch noch andere Werte oder Logik drinsteckt. Ist ok, kannich mit leben.
Frage 2 : Nach allem was ich hier so an Fragen und Dikussionen zu dem Thema gelesen habe (und auch in einer Facebook Gruppe ("OpenDTU, OpenDTU onbattery") ist der vorgeschlagene Schalter glaube ich das was sich viele wünschen. Ich glaube so wird auch der Parameter "Unteres Leistungslimit:" immer (mis)verstanden.
Ich glaube mit so einem Schalter könnte man einige Leute sehr glücklich machen :-)

[Janorei]

Ich meine die Differenz ist einfach das, was der WR bereits einspeist.
--> klingt vernüftig, prüfe ich morgen, wenn die Sonne wieder scheint

[Janorei]

Die gibt es nicht. Aber das wurde die letzten zwei Wochen so häufig gefragt, dass ich mir was ausgedacht habe: Wäre für dich ein Schalter ausreichend, der dafür sorgt, dass der Inverter nicht in den Shutdown geht, sondern auf das "minimale Leistungslimit" eingestellt wird?

Nachdem mir das mit dem Schalter für "Am unteren Limit keinen Shutdown" nicht aus dem Kopf geht, ich mich aber nicht so genau in der strukturellen Organisation des Projektes hier auskenne noch 2 Fragen:

1. Wo könnte man den Vorschlag am sinnvollsten posten, damit ihn auch Leute sehen, die das dann evtl. umsetzen könnten ?
2. Wie groß schätzt Du denn die Chance ein, das so was in nächster Zeit gemacht wird ?
3. Falls das jemand in einem Branch umsetzen wollen würde ich mich sofort als Beta Tester bereiterklären

Ich bin übrigens auch einer von denen, der sozusagen 2 HM laufen hat (einen ungeregelt und einen der geregelt werden soll)

[Janorei]

Ich kann zwar kein C oder C++ aber ein paar alte 4 GL Sprachen und so mittelmäßig Java. (außer 25 Jahren berufliche Programmiererfahrung ;-) )

Meine Vermutung ist, daß die Codestelle in etwa hier ist, wobei ich natürlich keine Ahnung habe, was eine Änderung hier für Seiteneffekte hat

`/**

• enforces limits and a hystersis on the requested power limit, after scaling

• the power limit to the ratio of total and producing inverter channels.

• commits the sanitized power limit. returns true if a limit update was

• committed, false otherwise.
  */
  bool PowerLimiterClass::setNewPowerLimit(std::shared_ptr inverter, int32_t newPowerLimit)
  {
  CONFIG_T& config = Configuration.get();

  // Stop the inverter if limit is below threshold.
  if (newPowerLimit < config.PowerLimiter.LowerPowerLimit) {
  // the status must not change outside of loop(). this condition is
  // communicated through log messages already.
  return shutdown();
  }`

[spcqike]

Für den Code bedarf es, je nach Umsetzung, etwas mehr.

Das webUI muss angepasst werden, die übergreifende config und das speichern / lesen dieser.

Ja, am Ende gehört das Limit im Dynamic power limiter an wenigstens einer Stelle korrekt interpretiert. Je nach Umsetzung gehört dann die aktuelle Interpretation des Limits noch überarbeitet.

Wo könnte man den Vorschlag am sinnvollsten posten, damit ihn auch Leute sehen, die das dann evtl. umsetzen könnten ?

Ich glaube, das brauchst du nicht erneut machen. Wenn @schlimmchen sagt, dass er sich was ausgedacht hat, ist das Thema schon in guten Händen 😄

[Janorei]

1. Beim Code gebe ich Dir recht, langjährige Erfahrung bei Änderungen in 20 Jahre altem 4 GL Code sagen mir: Einen unerwünschten Nebeneffekt gibt es meistens :-)
2. Wenn das bei @schlimmchen in guten Händen ist um so besser !

[Janorei]

Habe garade noch mal nach meinem Thema gesucht wo es um den Schalter für "Am unteren Limit keinen Shutdown des Inverters" geht. Ich habe eine Konfiguration mit 2 HM (einen geregelt einen ungeregelt) laufen. Der geregelte geht momentan sehr oft in Shutdown und wacht wieder auf (Teils im Minutenrhythmus). Das ist erstens sehr träge und kann zweitens eigentlich auf Dauer nicht gut für den HM sein.
Daraufhin habe ich überlegt ein Issue zu eröffnen, habe aber natürlich vorher ein wenig gesucht. @schlimmchen : Kann es sein, daß es so ein Issue schon gibt, nämlich hier : #626 ?
Ich würde mich (mit etlichen anderen Benutzern) freuen, wenn das Thema bald angegangen werden könnte und würde sofort als Betatester bereitstehen. Ggf. kann man den Schalter ja auch erstmal ohne Oberfläche nur in der config Datei konfigurierbar machen ?

[Janorei]

Ich meine die Differenz ist einfach das, was der WR bereits einspeist.
--> klingt vernüftig, prüfe ich morgen, wenn die Sonne wieder scheint

ja das ist tatsächlich so um der Code gibt das auch so wieder

`
int32_t acPower = 0;
int32_t newPowerLimit = round(PowerMeter.getPowerTotal());

if (!solarPowerEnabled && !batteryDischargeEnabled) {
  // Case 1 - No energy sources available
  return 0;
}

if (config.PowerLimiter.IsInverterBehindPowerMeter) {
    // If the inverter the behind the power meter (part of measurement),
    // the produced power of this inverter has also to be taken into account.
    // We don't use FLD_PAC from the statistics, because that
    // data might be too old and unreliable.
    acPower = static_cast<int>(inverter->Statistics()->getChannelFieldValue(TYPE_AC, CH0, FLD_PAC)); 
    newPowerLimit += acPower;
}

// We're not trying to hit 0 exactly but take an offset into account
// This means we never fully compensate the used power with the inverter 
// Case 3
newPowerLimit -= config.PowerLimiter.TargetPowerConsumption;

`

[hex2647]

Hallo zusammen,
hab jetzt schon einiges gelesen aber leider noch keine Lösung gefunden...
Folgendes Setup 4x400W an einem HMS1600... Die Module stehen verteilt im Garten, mehr als 2 haben selten (nie) gleichzeitig Sonneneinstrahlung... Nun kommt genau das Problem zum Tragen das bei 600W Limit jeder MPPT Eingang auf 150W Limitiert wird. Oftmals haben aber 2 MPPTs lediglich ca. 20W und dadurch begrenzt sich das System mit den anderen beiden MPPTs 2x150W künstlich auf ~340W... Habt ihr mir einen Tipp mit welchen Einstellungen in das Problem "lösen" kann?

[spcqike]

Hallo @schlimmchen

Wie anderswo bereits geschrieben, für reine PV Systeme wäre solch ein limiter wie folgt

P_eff=(P_theo-Summe(P_eingang_nicht_begrenzt))*Anzahl_MPPT

bspw
Theoretisches Limit von 300W. Die drei nicht begrenzten Eingänge liefern je 20W. Macht (300-60)4 = 2404 = 960

Damit liefern die drei nicht begrenzten Eingänge weiterhin ihre je 20W also 60W. Der nicht begrenzte darf allerdings bis zu 240W. Damit erreicht man am Ende die gewünschten 300.

[hex2647]

Die Informationen sind doch in der DTU alle sichtbar also welcher String aktuell wieviel Leistung liefert und wieviel W das System eigentlich liefern soll… über die spannungskurve der Module könnte man der DTU dann beibringen welches Modul nicht mehr kann und welches künstlich beschnitten wird… nur so als Idee?

[spcqike]

@hex2647 es braucht keine spannungskurven.

Wir wissen, welches Limit der inverter aktuell hat.

Wir wissen, wie viele Eingänge er hat und welche Leistung welcher Eingang liefert.

Damit weiß man, welcher Eingang durch das Limit begrenzt bzw. welcher durch schwache Sonneneinstrahlung begrenzt.

Was wir nicht wissen: wie viele MPPT der wechselrichter hat.

Für wechselrichter, die einen Eingang pro MPPT haben, ist das recht einfach. Für wechselrichter wie den HM-1500 oder HMT-2250 nicht.

Ich hatte die Berechnung genau so in einem Fork integriert. Das hat mir meinen HM-600 prima geklappt. Seither habe ich die Paneele anders positioniert und nutze jetzt wieder die hier verfügbare Firmware ohne meiner Änderung.

[schlimmchen]

Also ich verstehe, dass es machbar wäre, unter der Annahme dass es okay ist in Kauf zu nehmen, dass der Inverter ungewollt zu viel Leistung abgibt. Habt ihr verstanden, dass ich Code nicht mit meinem Namen versehen möchte, der absichtlich ein höheres Limit am Inverter einstellt, als der Benutzer als "oberes Leistungslimit" eingestellt hat? Weil es dann nämlich Szenarien gibt, in denen der Inverter sein Limit ungewollt ausreizt und weil dann zu viel Strom fließt auf der AC-Seite. Im einfachsten Fall löst dann eine (absichtlich?) klein gewählte Sicherung aus, was nur lästig wäre, aber im schlechtesten Fall speist der Inverter zu viel Leistung ein, obwohl der Benutzer gesagt hat "oberes Leistungslimit bitte (z.B.) 600W", und das kann gefährlich sein.

[spcqike]

Das kann ich völlig verstehen. Daher hab ich auch meine Ausrichtung der Module angepasst.

Was man ggf machen könnte, da diese Frage und indirekt auch der Wunsch nach einer solchen Regelung nun mehrfach kam: ein Opt-in mit entsprechendem Hinweis.

Der DPL Die Skalierung allgemein ist fragwürdig. Er Sie erzeugt viele Probleme und Fragen.
Vielleicht wäre eine Art zwei-stufiger Opt-In möglich.

1. den DPL die Skalierung aktivieren, so wie er sie bisher integriert ist.
2. den DPL die Skalierung integrieren, so wie hier von mir beschrieben mit möglicher „über Limitierung“

Beides mit entsprechendem Hinweis Text, oder Verweis aufs Wiki, über mögliche Folgen.

Da das Projekt ja in erster Linie „onBattery“ ist, und das Batterie System meiner Meinung nach immer alle Eingänge angeschlossen haben sollte, würde ich den DPL die Skalierung wahrscheinlich auch als Standard raus nehmen. Du hattest es an anderer Stelle angemerkt, dass du das ebenfalls bevorzugen würdest, das aber bei bestehenden System zu Änderungen im Verhalten führen kann.

Ich würde es dennoch so machen als Breaking change. Damit User beim Upgrade darauf hingewiesen werden.

[schlimmchen]

Der DPL allgemein ist fragwürdig.

Was? Wieso das denn? Was meinst du damit? Vielleicht verstehe ich auch nicht, was du meinst, aber diese Aussage finde ich recht verstören. Der DPL ist doch das Herzstück der OnBattery-Erweiterung?! 🤷‍♂️

Er erzeugt viele Probleme und Fragen.

Naja, er ist ja auch komplex.

[zapfs]

Ok - ich mach mich mal schlau. Ich berichte - brauche aber erst noch etwas sonnige Tage.

[schlimmchen]

braucht es das? Reicht nicht die Anzahl der MPPT?

@spcqike Ne, reicht meiner Einschätzung nach nicht. Wir müssen doch wissen, wie viel Leistung durch Eingänge an den jeweiligen MPPTs bereits konkret erzeugt wird, um die Berechnung anzustellen. Die Frage lautet: Wie viel Leistung wird vom einen MPPT erzeugt? Wir können aber nur Kanäle iterieren. Daher muss dann pro Kanal entschieden werden, zu welchem MPPT das gehört. Wir können gerne annehmen, dass die Anzahl der Eingänge stets ein Vielfaches der MPPTs ist, falls wir der Meinung sind, dass bei allen Hoymiles Invertern die Eingänge entsprechend durchnummeriert sind, also das wir beim Iterieren den Kanal genau dann dem nächsten MPPT zurechnen, wenn der letzte MPPT bereits (Anzahl Kanäle)/(Anzahl MPPT) Kanäle "aufgenommen" hat.

kannst du das näher erklären? Welche Fälle siehst du, die nicht durch die oben beschriebene Logik abgedeckt wird?

Du weißt nicht, was ein Unit-Test ist oder wie ich es hier meine: Das ist ein Stück Code, dass diese Funktion, die wir hier gerade besprechen, testet. Also sie mit einem bekannten Satz Eingaben ausführt und jeweils prüft, ob die Ausgabe den Erwartungen entspricht.

Ich habe im Zuge dieser Diskussion den 4. Eingang in der DTU als ebenfalls mit 405 W belegt konfiguriert

das bringt nichts. Bzw sollte keinen Effekt haben.

So ist es.

[hex2647]

@schlimmchen vielen Dank für deine Antwort. Das Zeit und motivation rar sind kann ich natürlich verstehen. Da ich es dir nicht abnehmen kann, kann ich lediglich versuchen deine Zeit so gering wie möglich zu halten indem ich ggf. das was du benötigst bestmöglich zuarbeite...
Wenn ich es richtig verstanden habe wäre eine Sache eine Zuordnung von Typ, Eingänge, MPPTs
also als ein Beispiel: HMS-1600-4T;4;4?
So eine Übersicht kann ich gerne kreieren... Wäre nur davon ausgegangen das der DTU das bereits weis, da er ja die Anzahl an Strings angibt und diese doch immer die Anzahl an Eingängen wiederspiegelt oder?
Wenn du sonst noch was weißt was deine Motivation erhöht, immer her damit :)

[schlimmchen]

Wie viele Eingänge der Inverter hat, können wir erfragen, das stimmt. Was fehlt ist das Wissen darüber, welcher Eingang mit welchem anderen Eingang einen MPPT teilt (oder auch nicht, weil er einen eigenen hat).

Wir können für den Start vereinfachend annehmen, dass die Anzahl der Eingänge ein ganzzahliges Vielfaches der Anzahl MPPTs ist, und dass die Eingänge korrekt durchnummeriert sind. Also dass z.B. Eingänge 1 und 2 zum ersten MPPT gehören, und 3 und 4 zum zweiten. Und die Annahme wäre, dass es sowas wie 1&3 am ersten MPPT oder 1&4 am ersten MPPT nicht gibt. Das ist aber nur eine Annahme. Eigentlich hätte ich das gerne recherchiert, dass das in der Praxis tatsächlich so ist.

Zu liefern ist eine Tabelle mit Spalten "Inverter Serie" und "Anzahl MPPTs".

Das hier sind die Zeilen bzw. Inverter-Serien, die in OpenDTU bekannt sind:
"HMS-300/350/400/450/500-1T"
"HMS-500-1T v2"
"HMT-1600/1800/2000-4T"
"HMS-1600/1800/2000-4T"
"HM-300/350/400-1T"
"HM-600/700/800-2T"
"HMS-600/700/800/900/1000-2T"
"HM-1000/1200/1500-4T"
"HMT-1800/2250-6T"

Wichtig wäre insb. zu wissen, ob es in einer dieser Serien verschiedene Modelle mit verschieden vielen MPPTs gibt.

Da kann am Ende rauskommen, dass die Zahl vor dem T, die OpenDTU dort dem Typen hinzufügt, tatsächlich die Anzahl MPPTs ist. Aber das müssen wir bitte erst sicherstellen, bevor wir uns darauf verlassen.

[spcqike]

Da kann am Ende rauskommen, dass die Zahl vor dem T, die OpenDTU dort dem Typen hinzufügt, tatsächlich die Anzahl MPPTs ist.

dem ist nicht so. die HMT-1600/1800/2000-4T haben nur 2 MPPT

die HMT-1800/2250-6T haben 3 MPPT.

im Upstream gibt es direkt auf der Hauptseite eine Tabelle, die, wenn ich das richtig überblickt habe, dem aktuellen Stand der Wechselrichter entspricht. die HMT sind dort auch korrekt hinterlegt

https://github.com/tbnobody/OpenDTU?tab=readme-ov-file#currently-supported-inverters

Nachtrag:
bisher ist es wohl so, dass T die Anzahl der MPPT ist, mit Ausnahme der 3 Serien:
"HMT-1600/1800/2000-4T"
"HM-1000/1200/1500-4T"
"HMT-1800/2250-6T"
Diese haben nur <x/2> MPPT.

Warum auch immer Hoymiles da so etwas krummes macht...

[MatzeMuc86]

Ich lese interessiert mit da ich am meinem hmt-2000 (4 separate Eingänge) mit 1x Ost, 2x Süd und 1x West vermutlich demnächst in ähnliche Probleme laufe.

Wer aber einen Wechselrichter mit mehr maximaler Ausgangsleistung betreibt als seine Verkabelung hergibt, handelt grob fahrlässig. Es kann auch im offizielle Betrieb zu Fehlern kommen was das Limit angeht und die maximale Leistung wird eingespeist. Da erachte ich einen Hinweis als nett und gut zur Absicherung.

Nur so meine Meinung.

Viele Grüße

[spcqike]

Der HMT-2000 hat nur zwei MPPT. Da gibt es noch andere Probleme was die Berechnung angeht. Auch kann man da einen Eingang überlasten, wenn zu viel Leistung angeschlossen wird. Was mit reinen PV Modulen wohl nicht passieren sollte.

Wer aber einen Wechselrichter mit mehr maximaler Ausgangsleistung betreibt als seine Verkabelung hergibt, handelt grob fahrlässig.

Ich denke auch, die AC Leitung sollte natürlich immer zum wechselrichter passen. Auch muss man sicher stellen, dass keine weiteren Verbraucher im Kreis hängen sodass diese überlastet werden könnten. (16A vom LS und 10A vom wechselrichter bspw) das ist aber kein openDTU Thema. Das gehört bei der Installation und Abmeldung berücksichtigt.

[MatzeMuc86]

Der hmt 2000 - 4T (hatte ich nicht geschrieben, sorry) hat 4 MPPT. Ggf gibt es da auch einen mit nur zwei MPPT.

[spcqike]

Laut Datenblatt hat er zwei tracker mit je zwei Eingängen

Der HMS-2000 hat vier tracker mit je einem Eingang.

[MatzeMuc86]

Und am Ende meinte ich den HMS-2000-4T ;-)

[magic7864]

Hallo zusammen, auch ich betreibe zwei HM-1500, ohne Akku, beide geregelt. Und auch bei mir geht immer wieder einer von beiden in die Abschaltung und erwacht nur schwer oder gar nicht mehr und ich muss den WR mit dem Neustartbefehl wieder zum Leben erwecken.

Darum würde auch ich mir einen Schalter in der Software wünschen, der die Abschaltung ganz verhindert.

Würde mich sehr freuen, dann währe das System für mich perfekt

[spcqike]

Bei Änderungen am upstream hast du natürlich recht.

Eine weitere möglich wäre vielleicht, das System als PV System zu behandeln, wenn die Eingänge des wechselrichters mit einer Wp Angabe versehen sind. Oder?

Nutzen User mit batteriesystemen diese vorhandenen eingabefelder? Im webUI sieht man damit ja eine berechnete Einstrahlung

Das macht bei batteriesystemen irgendwie wenig Sinn :)

Einprogrammieren kann man vieles. Sowohl über das vorhandene Feld als auch über ein separaten Schalter. Man muss es am Ende nur im Wiki richtig beschreiben und festhalten :)

[schlimmchen]

Dokumentation ist ein Thema, du sagst es. Und genau deshalb ist "Ein Wert ungleich Null bei 'Max. Leistung String' bedeutet, dass der Inverter an Solarmodulen hängt" meiner Meinung nach eine sehr schlechte Idee.

Ich verstehe deinen Gedanken, der macht Sinn, aber wenn du von der anderen Richtung kommst (Neuling) ist das äußerst unintuitiv. Das ist ja dann nur ein Seiteneffekt.

Es spart natürlich einen Schalter, das ist ein klarer Vorteil 😉

[magic7864]

Wäre aber doch trotzdem einfach beide Nutzer über Schalter sicher einzubinden. Der User ohne Batterie setzt den Schalter -keine Batterie- und ein zweiter Schalter erscheint -Option Wechselrichter kein Shutdown-. Alle Batterieeinstellung hier einfach dann ausblenden. Schalter auf ich habe eine Batterie dann alle Einstellungen für Batterie aber keine Möglichkeit den Shutdown abzuschalten. Dann gingen auch mehrere Wechselrichter mit einer DTU.

[schlimmchen]

und ein zweiter Schalter erscheint -Option Wechselrichter kein Shutdown-.

Mein Vorschlag lautet aber, dass alle Nutzer ohne Batterie diese Option sinnvollerweise einschalten würden oder sollten. Also tut der DPL das für sie, wenn er schon weiß, dass der Inverter nicht an einer Batterie hängt.

Alle Batterieeinstellung hier einfach dann ausblenden.

Work in progress.

Dann gingen auch mehrere Wechselrichter mit einer DTU.

Diesem Gedankensprung konnte ich nicht folgen...

[magic7864]

Mit mehrere WR an einer DTU meinte ich, wenn ihr die Funktion implementiert, könnte eine DTU gefahrlos mehrere WR steuern, sobald aber ein WR zusammen mit einer Batterie läuft muss dieser zwingend eine separate DTU bekommen. Bisher steuert eine DTU ja eh nur ein WR aber für die Zukunft gedacht.

[schlimmchen]

Bitte helft testen in #733.

[magic7864]

So, heute ist bei mir im Norden endlich mal wieder Sonne. Der HM-1500 darf scheinbar nicht zu tief im unteren Leistungslimit eingestellt werden, sonst geht der WR trotzdem in den shutdown. Ich habe jetzt beide auf 50 eingestellt und seitdem läuft die Sache super vielen Dank @schlimmchen.

[Janorei]

Ich habe meinen HM 800 auf 2% = 16 Watt eingestellt. Das sind ca 8 - 9 W ro Mpp Tracker. Das funktioniert ganz gut ohne Shutdown in den letzten Tagen. Drunter würde mich nicht gehen, da kommt mir die Regelung etwas instabil vor. Notfalls eher noch etwas höher und lieber was einspeisen. Ansonsten habe ich Netzbezug auf 0 und Hysterese auf 30 W gestellt. Das läuft ganz gut mit den Einstellungen. Ggf Hysterese noch etwas höher, dann wird nicht so oft geregelt. Alles in allem super.

[Janorei]

@schlimmchen : ist der Branche eigentlich schon in den Master gemerged und das Feature in der neuesten Version verfügbar ? Dann würde ich meine OPENDTU wieder auf dem Master setzen (da ist momentan noch der Branche am laufen)

[schlimmchen]

#733 ist noch nicht in ein Release verpackt, aber Teil vom Branch "development". Wenn du selbst baust, baue von "development". Andernfalls musst du auf ein neues Release warten. Bis dahin verpasst du ja nichts, solange nicht anderes für dich wichtiges im "development" Branch landet.

[Janorei]

Danke, ich warte ;-)

[firedp]

Hallo,
mal eine Frage. Ich habe einen hm-600 und würde gerne noch einen hms-500 kaufen. Dafür scheint es OpenDTU Fusion zu geben.
Aber kann man mit der Fusion Platine auch „on Battery“ aufspielen, beide Wechselrichter auslesen, nur den hm-600 dynamisch mit einem Hichi Tasmota Lesekopf steuern, also Nulleinspeisung oder definierter Einspeisung? Und eventuell noch ein Display anschließen?

[schlimmchen]

Ja.

[Janorei]

Habe ich so laufen mit 2 HM 800 und einer opendtu on Battery und einem Shelly 3 EM Pro, sollte aber auch mit Hichi/ Tasmota gehen, wenn der zuverlässig und vor allem zügig auf die Anfragen vom Powermeter antwortet. Meine Versuche mit Lesegerät Poweropti von Powerfox waren eher nicht von Erfolg gekrönt, wegen der langen Antwortzeiten. Ich habe allerdings ein open DTU von Nordic Skills mit LAN Anschluss (also nix WLAN) laufen. Da der Shelly auch im LAN hängt sind die Antwortzeiten schon sehr gut.

[schlimmchen]

Auf den Hichi macht man Regeln, sodass die Power-Werte sekündlich auf den MQTT Broker gehen, und die kommen dann auch über MQTT sehr leichtgewichtig (verglichen mit HTTP) in den DPL. Stimmt nicht, das macht mein Shelly 3EM mit Tasmota drauf...

[firedp]

Na dann gehe ich mal einkaufen.
Danke für die Antworten, nun komme ich über Ahoy und normales Open doch noch hinaus.

[schlimmchen]

Am Ende kommen sie alle hier her 😁 Viel Erfolg und viel Spaß.

[Janorei]

Auf den Hichi macht man Regeln, sodass die Power-Werte sekündlich auf den MQTT Broker gehen, und die kommen dann auch über MQTT sehr leichtgewichtig (verglichen mit HTTP) in den DPL.

ok. wieder was gelernt :-) Ich baue nämlich seit einer Woche an meinem Raspery PI mit Home Assistant mit MQTT Broker

[schlimmchen]

Ich muss mich korrigieren: Mein Hichi macht das nicht. Ich hab noch nicht tief genug recherchiert, um das vom Hichi aus (auch) zu machen.

Die angesprochenen Regeln (Kommandos rule1 etc.) sind in meinem Shelly 3 EM mit Tasmota.

Wie das mit dem Tasmota fürs Hichi geht (da muss USE_SCRIPT aktiviert sein, was mit USE_RULES inkompatibel ist), weiß ich leider nicht. Lass es mich daher gerne wissen 😉

[spcqike]

@schlimmchen dafüe muss die precision des readings um 16 erhöht werden.

Gemäß Doku

number of decimal places. Add 16 to transmit the data immediately. Otherwise it is transmitted on TelePeriod only.

https://tasmota.github.io/docs/Smart-Meter-Interface/#meter-metrics

edit

wo ich das hier so lese, auch dein Kommentar zum MQTT …. Vielleicht hat stelle ich es bei mir auch mal um.

Ist das direkte senden der Werte von Shelly, oder tasmota, per MQTT und das empfangen / verarbeiten des MQTT powermeters denn schneller, als ein forced https+json powermeter? Also eins, welches direkt im powerlimiter durchlauf passend neu abgefragt wird?

„Liver“ (mehr live? Zeitlich näher) als mit forced Update wird es bei der Berechnung doch nicht, oder?

Nachtrag2:
habs grad getestet. der Tasmota Lesekopf sendet damit fast sekündlich (manchmal auch erst nach 2s) den aktuellen Leistungswert. Leder kann man dies so nicht direkt in openDTU hinterlegen und abfragen, oder? man müsste auch dort zum Topic noch den JSON Pfad angeben können.

und, im Teleperiod sendet der Lesekopf dennoch ganz normal sein gesamten JSON. Was nicht schlimm wäre, würde man ein JSON Pfad angeben können, wie man es im HTTP(S)+JSON auch kann.

[schlimmchen]

dafüe muss die precision des readings um 16 erhöht werden.

Danke für diesen Tipp!

Ist das direkte senden der Werte von Shelly, oder tasmota, per MQTT und das empfangen / verarbeiten des MQTT powermeters denn schneller, als ein forced https+json powermeter? Also eins, welches direkt im powerlimiter durchlauf passend neu abgefragt wird?

Ja, denn es scheint bei diesen Gedanken (ich glaube spcqike hat das auch geglaubt) keiner zu berücksichtigen, dass die gesamte DPL Loop wartet auf ein junges PowerMeter Reading. Das hab ich vor Monaten eingebaut und es ist scheinbar niemandem aufgefallen, dass der DPL bei HTTP-PowerMeter nun "langsamer" regelt. Das heißt selbst mit ungewolltem forced-Update-Reading des PowerMeter wird "ganz oben" im Code erstmal gewartet, dass nach neuen Inverter-Daten auch der PowerMeter einen neuen Wert hat ohne dort schon ein forced-Update zu verlangen. Ist das verständlich, was ich meine?

Das bedeutet, dass ein sekündlicher Power-Meter Wert aus MQTT diese Wartezeit entsprechend drastisch verkürzt (im Allgemeinen).

Ich bin absolut dagegen, dass der DPL der PowerMeter Implementierung versucht den Takt vorzugeben. Das ist nicht die Aufgabe des DPL. Die PowerMeter Implementierung soll Werte liefern, nach ihrem jeweiligen Gusto.

Leder kann man dies so nicht direkt in openDTU hinterlegen und abfragen, oder? man müsste auch dort zum Topic noch den JSON Pfad angeben können.

Korrekt, das unterstützen wir zur Zeit nicht. Ich hab das Problem nicht, weil man mit Regeln (USE_RULES in Tasmota auf dem Shelly 3 EM) das Topic und den Wert je genau festlegen kann:

rule1
ON energy#total DO publish grid/energy/total %value% ENDON
ON energy#power[1] DO publish grid/power/phase1/watts %value% ENDON
ON energy#power[2] DO publish grid/power/phase2/watts %value% ENDON
ON energy#power[3] DO publish grid/power/phase3/watts %value% ENDON

Das würde ich gerne auch mit dem Hichi realisieren. Dein Tipp bringt mich dem ein ganzes Stück näher, aber wie du schon festgestellt hast, muss dann das JSON seziert werden.

Und auch noch Danke für die Screenshots. Der MQTT Explorer kann also auch Dark Mode, man muss es nur einstellen... Was eine Erleichterung 😅

[spcqike]

ich glaube spcqike hat das auch geglaubt

ja das habe ich. Tue ich eigentlich auch noch. (: hab es nur noch nie näher untersucht. Zumindest nicht in letzter Zeit.

Als das forced Update rein kam lief der powermeter::loop() artig aller 10s. Da kam es definitiv vor, dass das powermeter reading >5s alt war, wenn der powerlimiter::loop() durchlief.

Mein powermeter läuft nach der Anpassung der config im 5s interval.

Als Ich mir das letzte mal die Timings näher angeguckt habe, hatte ich das forced Update noch drin. Und in der Konsole hat man gesehen dass damals der powermeter::Loop quasi nicht lief weil das Update immer vorrangig im powerlimiter initiiert wurde

Korrekt, das unterstützen wir zur Zeit nicht

könnte man als Erweiterung doch sicher machen, oder? Der Code ist ja quasi schon fast vorhanden, oder?

Das würde ich gerne auch mit dem Hichi realisieren.

es gibt noch das äquivalent zur rule. Den Script Befehl =>publish. Diesen kann man bspw im Segment >S aufrufen. Allerdings hatte das bei meinen letzten Versuchen auch nur mäßig live geklappt.
einfacher wäre da wahrscheinlich der Umweg über ein MQTT Dienst der das Reading in einem eigenen topic neu published. Oder das json parsen in der openDTU.

Und auch noch Danke für die Screenshots.

gerne (:

[schlimmchen]

Die Variante mit =>publish habe ich inzwischen woanders beschrieben und nutze es selbst. Mein Hichi veröffentlicht somit die vom Stromzähler gemessene Leistung sekündlich an den MQTT Broker.

[Schleppe]

[schlimmchen]

Ich kann auch gerne ein Logfile erstellen

Na dann mal los. Ohne können wir auch nur raten. Wir brauchen die ausführliche Protokollierung des DPL eingeschaltet und dann einen Auszug aus der Konsole während das Problem besteht.

[Janorei]

Habe heute auf meiner Open DTU den Branch durch den Master ersetzt. Die Oberfläche schaut ja jetzt echt aufgeräumt aus. Sehr schön !!!
Morgen wird nochmal beobachtet :-)

[firedp]

Heute 5.9.24
nutze jetzt schon seit Monaten onBattery ohne Batterie. Ein Hichi dazu und ein BKW läuft ungeregelt auf max. 740W, ein zweites wird geregelt mit min. 56W Einspeisung oder mehr, was halt gebraucht und möglich ist. Die meiste Zeit aber nur mit 56W, das andere BKW liefert meist mehr als ich brauche. Warum das alles? Weil es Spaß macht.
Völlig fehlerfrei! TOLLE ARBEIT !!!
Habe mir aber trotzdem mal einen ESP32 mit 8mb bestellt um bei Regentage etwas zu basteln.
Werde ich dann Vorteile zu heute haben? Regelt das System vielleicht schneller? Was könnt ihr mir berichten?

[Gururom]

Ähnlich betreibe ich mein System auch
Jetzt neu eine OpenDTUonbattery fusion.
Ein bkw ungsregelt (WR 600 Watt)
Ein bkw geregelt WR1600watt
Das ungeregelte zeigt Richtung Westen und hat eigentlich nur einen schmalen Korridor, im Sommer wenn die Sonne hoch steht eigentlich noch ganz gut.
Beim großen zeigt ein Modul Richtung Süd Osten die anderen drei Richtung Süden, ca 30grad aufgeständert.
Im Moment wird mein Bedarf Tags über von ca 8.00-18.30 fast voll abgedeckt.
Zusätzlich schalte ich per shelly wenn genug Leistung vorhanden noch einen heizstab mit 900watt im Pufferspeicher dazu.
Am zähler habe ich einen shelly 3em.
Meine fusion ist die neuste Generation mit 16mb.
Bin aber erst diese Woche umgestiegen von der kleinen opendtuonBattery, kann also keinen Erfahrungsbericht liefern.
Aber ich bin zuversichtlich dass das genau wie vorher läuft.
Eventuell sind sogar die einmal im Monat auftretenden verluste der Verbindung weg.
Grüße

[firedp]

Viele scheinen aber nicht ohne Batterie zu arbeiten.
Für mich ist es eine günstige Geschichte 2 BKW ohne übermäßige Einspeisung arbeiten zu lassen.
Dazu zwei alte hm-600 mit Flole Invertertool auf 800W und 1000W gebracht, habe ich wenigstens in den Verbrauchsspitzen was davon und natürlich bei diffusem Licht dank der 2000W Modulleistung.
Ein gebrauchtes BKW und seine älteren 2 Module zu verkaufen wäre ja fast sinnlos gewesen.

[Gururom]

Nein, wahrscheinlich wirklich nicht viele, aber doch einige.
Solche Leute,so wie ich eben auch, die mehr als zulässig installiert haben das Netz und auch die eigenen Leitungen nicht mehr als nötig belasten wollen und so immer unterm Radar bleiben können,
Ich glaube hier kann man sich outen, im Photovoltaik-Forum kommst du dafür auf den Scheiterhaufen. ;-)
Bei mir gibt es im Keller, ganz in der Nähe der Einspeisung vom 16ooer eben den Pufferspeicher mit Heizstab selbstverständlich mit vernünftigen Kabelquerschnitten und auch ordentlich abgesichert. Läuft alles sauber und problemlos, es gibt halt im Sommer schon Zeiten an denen 3-4kw gefordert werden und meine Anlage dann eben ihre guten 2kw dazu geben kann.
Das ist die Ausnahme, normal würde eben eine 600er reichen, die große Anlage wird durch oDTUoB eigentlich zu 70% nur hochgefahren um den Heizstab zu bedienen.
Das dass nicht die ursprüngliche Intension von oDTUoB ist, ist aber schon klar

Nebenbei bemerkt jetzt ab Oktober bekommt die oDTUoB so gut wie nichts mehr zu tun, also regeln fällt aus.