Regelverhalten HMS-2000 niedrige Leistung

[spcqike]

Mahlzeit,

mir wurde nun endlich der Victron VM-3P75CT eingebaut. Die openDTU unterstützt ihn ja bereits nativ und fragt fleißig im 1s Intervall ab.

Home Assistant unterstützt Modbus Geräte ebenfalls und fragt ebenfalls im 1s Takt ab. (da gibts sogar mehr Messwerte, bspw. die Netzfrequenz, die zukünftig für "echte" Netzdienlichkeit herangezogen werden könnte)

nun ist mir etwas aufgefallen, was ich mit dem Shelly 3EM nie gesehen habe. Die Leistung und die Ströme schwanken stark im niedrigen Lastbereich des WR.

was ich meine sieht man hier

der HMS-2000 läuft offen auf 2kW Limit, die niedrige Leistung ist eben durch die Sonne/Wolken.

unter ~0.8A (gemeldet vom HMS) scheint er zu takten oder ne PWM auszugeben oder sowas. er meldet gleichmäßige Ströme und Leistungen (gelb), der Victron misst jedoch starke Schwankungen/Takte.
über ~0.8A (~180W), meldet auch der Victron konstante und "glatte" Ströme und Leistungen.

das passt irgendwie auch zu den bisherigen Erkenntnissen, dass der HMS sein gesetztes Limit unter 180W-200W eben nicht erreicht.

Was heißt das für mich im Umkehrschluss? unter dieser Leistung meldet er zwar eine "konstante" Produktion, beim minimalen Limit von ~12W pro MPPT bzw 48W insgesamt eben auch die 48W, er produziert sie aber nicht. der Stromzähler am Netz hat in diesem Kleinstlastbereich immer Import und Export (man beachte die starken Schwankungen der Leistung am Victron)

man sollte wohl die großen Wechselrichter an einer Batterie nicht unter 200W betreiben, da die Regelung da wohl einfach nicht das macht, was man denkt, oder? :)

der Victron kann wohl 10Hz schnell messen, anders als die Shelly. Aktuell nehme ich auch nur in 1Hz Messwerte auf.

Wenn da Bedarf besteht, kann ich auch mal gucken, was eine 10Hz Messung tatsächlich ergibt, was bei kleinen Leistungen am Stromzähler wirklich rein und raus geht :)

Grüße

[spcqike]

noch stärker sieht man das gezappel und das Verhalten noch davor, bei noch kleineren Leistungen

es sieht so aus, als würde der HMS-2000 immer um die ~1.8A ausgeben. der Zähler springt bspw. von 0.96A auf -0.9A

ich glaub ich muss die Abtastung mal erhöhen :D

[Sorbat]

Man legt nur eine Modbus.yaml an und kopiert diesen Code mit angepasster IP da rein?
Und dann sollte ein Gerät auftauchen?
Oder muss man in der configuration.yaml noch auf die Modbus.yaml verweisen?

[spcqike]

Du musst in der configuration noch den passenden „!include“ setzen. Damit sie auch geladen wird.

[Sorbat]

Welcher ist denn der "passende" include?

Wenn ich !include Modbus.yaml schreibe kommt nur ein Fehler

[spcqike]

modbus: !include modbus.yaml

bzw. so wie du die Datei genannt hast

[Sorbat]

Danke, damit ging's 💪

[spcqike]

@SW-Niko was ich an deinem oszi Bild nicht verstehe: warum ist der rms von F2 (Leistung DC?) geringer als von F1 (Leistung AC?)

sollte es nicht umgekehrt sein?

Nachtrag
Hab’s gefunden. Hab rms F1 und mean F2 verglichen.

Mean F1 ist niedriger als mean F2 und rms F2 fehlt :)

[SW-Niko]

👍
Genau. RMS und Mittelwert vom gleichen Signal sind meistens unterschiedlich. 😀

[spcqike]

@AndreasBoehm @schlimmchen

ich hab mir grad die powermeter geschichte angeguckt und probiert, einen Ringbuffer einzubauen. in anderen (weniger komplexen) Projekten funktioniert das folgende wunderbar

class RingBuffer {
public:
    static constexpr size_t N = RINGBUFFER_SIZE;
    int16_t values[N]{};
    size_t  index   = 0;     // nächste Schreibposition
    bool    filled  = false;

    void add(int16_t value) {
        values[index] = value;
        index = (index + 1) % N;
        if (index == 0) filled = true;
    }

    // get(0) = zuletzt geschrieben, get(1) = davor, ...
    int16_t get(size_t i) const {
        size_t count = size();
        if (i >= count) return 0; // oder assert/throw, je nach Geschmack
        // zuletzt geschriebener Index ist (index - 1)
        size_t pos = (index + N - 1 - i) % N;
        return values[pos];
    }

    size_t size() const {
        return filled ? N : index;
    }
};

meine Idee wäre erst einmal einen Buffer für PowerTotal zu hinterlegen. dieser kann / sollte ruhig 10 Werte halten.
Im Falle des Victron Stromzählers würde ich es wohl hier dazwischenschieben.

OpenDTU-OnBattery/src/powermeter/udp/victron/Provider.cpp

Line 201 in d7a575e

_dataCurrent.add<Label::PowerTotal>(readInt32(&p, 1)); // 0x3080f

also die Antwort vom Stromzähler erst einmal in den Buffer schieben (buffer.add() ), zusätzlich würde ich den Buffer oben um "getAverage", "getMax" und "getMin" erweitern.

"getAverage" würde ich dann in meinem Fall erst einmal standardmäßig ins _dataCurrent zurück geben wollen. (ich hab das Powermeter Interval direkt in der Config auf 250ms, im WebUI geht das leider nicht, obwohl sowohl die openDTU als auch der Victron es können)

"getMin" und "getMax" könnte man bspw. in der irgendwann und irgendwo mal angedachten "Sommer-" und "Winterentladung" der Batterien hernehmen und als "PowerTotal" zurück geben. So würde im "Wintermodus" bspw. mit getMin nur der niedrigste Wert ausgeglichen, was Überschüssige Einspeisungen, wenn auch nur kurze Spitzen, ausschließt. Im SOmmer umgekehrt.

Macht das Sinn? Wie seht ihr das?

Grüße

[AndreasBoehm]

Konntest du damit eine Verbesserung erreichen?
Ich dachte das der HMS-2000 bei niedrigen Limits immer so rumzappelt? Egal was wir tun?

[spcqike]

Das Gezappel des wechselrichters wird sich dadurch nicht ändern. Allerdings sollte der Stromzähler Wert stabilisiert werden.

Wie du oben siehst (wenn auch schwer) erfasst der Stromzähler Schwankungen von gut 100W und mehr. Diese sehe ich auch in der OpenDTU. Wahrscheinlich weil der Stromzähler eben um einiges schneller ist und auch sehr kurze peaks als Live wert ausgibt. Diese peaks könnten, so meine Vermutung, hier durch das Gezappel entstehen. (Es gibt ja abe auch Verbraucher die Takten und zyklisch ziehen, was hier und da Schwingungen in de Regelung verursachen kann)

so, mit diesen Schwankungen, müsste ich die hysterese wohl sehr hoch stellen :D

[SW-Niko]

Hmmmm.......
Ich sehe mehrere Probleme:

• Die Inverter wechselt bei kleinen Lasten in einen lückenden Betrieb. (50ms ein, 50ms aus)
• Der Victron VM-3P75CT misst in 100ms Intervallen
• Wenn wenig Energie zur Verfügung steht, möchte man nichts verschwenden und steigendem Verbrauch eher langsam folgen.
• Wenn viel Energie zur Verfügung steht, dann kann man etwas verschwenden und fallendem Verbrauch eher langsam folgen..

Ich muss mal intensiver darüber nachdenken, ob das alles mit einem Ringpuffer zu lösen ist. 🤔

Abgesehen davon würde eine Glättung (Mittelwert) speziell für den Victron VM-3P75CT natürlich funktionieren.

[spcqike]

@AndreasBoehm hier sieht man das nochmal, was ich meine. Leider kann ich in HA das Zeitfenster nicht weiter verkleinern

Der HMS-2000 produziert sehr wenig, da wenig Sonne. Da ich aktuell keine Batterie habe und keinen DPL nehme, ist es auch nicht tragisch.
hötte ich jedoch eine Batterie und den DPL aktiv, würde der gemeldete Stromzähler Wert um bis zu 200W schwanken. Wo der Mittelwert eher so bei konstant 400W lag.

Nachtrag:
Bei höheren erzeugungsleistungen ist das Problem geringer. Aber auch vorhanden

hier sind es so bis zu 40W Sprünge. Die können aber auch durch Verbraucher mit schaltnetzteil kommen.

Der Victron ist einfach recht schnell (: vom Shelly hab ich leider keine sekündlichen messdaten sondern nur 30-sekündliche. Da sehe ich so kurze Schwankungen nicht. Es kann aber auch sein, dass der die gar nicht erfasst.

[spcqike]

hier hab ich es mal mit Node Red ausgewertet. die einzelnen Rohwerte kommen aller 250ms von der openDTU.

ich habe einen Ringpuffer mit 10 Werten, also 2.5s im Mittelwert. Bei Anstiegen oder Abfällen hängt er also 1-2s hinterher.

den Zähler könnte man jedoch mit 100ms abfragen. dann wäre der Mittelwert immer 1s Messzeit. Oder man macht einen gewichteten Mittelwert und die neueren Daten bekommen mehr Gewicht, um schneller auf Veränderungen zu reagieren

[spcqike]

FIY, hier nochmal ein (wahrscheinlich schwer erkennbarer, da nur am Handy gemachter) Screenshot mit der maximal, minimal, momentan und der, wie oben beschriebenen ,gemittelten Leistung, die der Victron misst.

Ich habe seit kurzem ein 3D Drucker, der scheinbar beim heizen sehr kurz und hoch taktet.

die Leistung springt teils aller 500ms um 600W hoch und runter. Das wäre für eine DPL Regelung wohl äußert ungeeignet :)

[SW-Niko]

Das wäre für eine DPL Regelung wohl äußert ungeeignet

Ja, das ist ungünstig. Wenn die Änderung schneller als die Regelung ist dann steigen die Verluste.
Ich habe noch 2-3 Ideen wie man im DPL schneller regeln könnte. 🤔 Aber so schnell wird es nicht werden. 😉

[spcqike]

Nein, eine schnellere Regelung macht keinen Sinn. Allen voran sind die wechselrichter gar nicht so schnell. Es dauert mehrere Sekunden, bis sie wieder bereit sind einen neuen Befehl zu nehmen, oder?

Dann ist der Victron halt auch einfach mal viel schneller, als der typische MID Zähler. Der Victron tastet mit 10Hz ab und gibt auch so schnell die Leistung raus. (OpenDTU erlaubt nur 2Hz an dieser Stelle :D man kann ihn nicht schneller Pollen) ein Cerbo GX oder der multiplus würde wahrscheinlich entsprechend schnell reagieren. Immerhin ist der multiplus ein Insel WR, der auch auf so schnelle Last Wechsel reagieren können muss.

Ein MID Zähler mittelt, wenn ich es richtig gelesen habe, ebenfalls über eine Sekunde. 500ms 100W Export und 500ms 100W Import wären da ne 0. kein Zählwerk zählt.

Beim Victron hingegen zählen beide entsprechend der Zeit weiter :)

wenn man in OpenDTU mit dem viel schnelleren Victron einen typischen Stromzähler ersetzen will, sollte man ihn wohl schneller Pollen und die Werte Mitteln. Und nur mit maximal Sekunden genauen Mittelwerten arbeiten.

auf der anderen Seite war bereits irgendwo mal ein „verzögertes Regeln“ in Diskussionen. Im Sinne von „im Winter eher die Mindestleistung der letzten X Sekunden halten, um nichts zu verschenken und einzuspeisen“ und „im Sommer ruhig die Maximalleistung der letzten X Sekunden ausgleichen, um bei Überschuss auch ja nichts aus dem netz zu ziehen“

[SW-Niko]

Es dauert mehrere Sekunden, bis sie wieder bereit sind einen neuen Befehl zu nehmen, oder?

Das kann ich dir nicht beantworten. 🤷‍♂️
Ich bin mir aber sicher das der Hoymiles immer 0-20ms Totzeit hat bis er die Poweränderung umsetzen kann. (werten auf Nulldurchgang)

wenn man in OpenDTU mit dem viel schnelleren Victron einen typischen Stromzähler ersetzen will, sollte man ihn wohl schneller Pollen und die Werte Mitteln. Und nur mit maximal Sekunden genauen Mittelwerten arbeiten.

Ja, so sehe ich das auch.

auf der anderen Seite war bereits irgendwo mal ein „verzögertes Regeln“ in Diskussionen.

Das würde natürlich auch helfen.

Insgesamt brauchen wir für den Victron eine andere Lösung. Auf der einen Seite hat man ein schnelles Messgerät und auf der anderen Seite muss man ihn drosseln damit man bei kleinen Leistungen nicht über die "lückende Steuerung" der Hoymiles bei kleinen Leistungen stolpert.