Improve convergence of DTU DPL algorithm by adding delta "Inverter Total Power" to "Current Limit" to power calculation

[gitisgreat2023]

Here I raised an issue which is in principle a DTU-OB issue.
Basically the DPL doesn't convergence to the target value (say 0 W) if the inverter total power doesn't match the limit set.

This can be avoided by adding the difference between the inverter total power and the limit set to the inverter to the power calculation.

@genmad
I could start messing in the code but I prefer to let you do that because I'm not experienced in Javascript and neither in the Shelly environment.

I have some programming experience howerver and look at the code. First in processHttpResponseForInverterPower the limit_absolute has to read out as well. (or a new routine is added, but I would generalize this process function and name it differently)
Then in calculateVirtualPowerReadings, when the limit_absolute is larger than the minRequiredPower_Watt, the difference between set (body.inverters[0].limit_absolute) and get (body.inverters[0].AC[0].Power.v) has to be added to line 262. It can be a negative as well as positive value!

My idea would be that we could show schlimmchen a proof of principle that it works stable and reliable in the Shelly environment. It's a bit slower as the Shelly adds delay to the feedback loop, but it should work in principle I would say. I would be happy to test it! Then it might make it as an improvement to the DTU-OnBattery code. Because in principle it's a DPL issue IMHO.

Did I oversee something? You think it's worth trying out?

[genmad]

Here I raised an issue which is in principle a DTU-OB issue. Basically the DPL doesn't convergence to the target value (say 0 W) if the inverter total power doesn't match the limit set.

This not convergence to a set Power Value is deliberately done, I guess. There is a hysteresis Power value you can set in odob in the dpl config which limits the convergence to some value, for only differences greater than the set value.

I guess that is what you found. I think this config/behaviour is there for a hardware related reason.

This can be avoided by adding the difference between the inverter total power and the limit set to the inverter to the power calculation.

@genmad I could start messing in the code but I prefer to let you do that because I'm not experienced in Javascript and neither in the Shelly environment.

Im also not an experienced Java Script or Shelly developer. So just go ahead and do what ever you like.

I have some programming experience howerver and look at the code. First in processHttpResponseForInverterPower the limit_absolute has to read out as well. (or a new routine is added, but I would generalize this process function and name it differently) Then in calculateVirtualPowerReadings, when the limit_absolute is larger than the minRequiredPower_Watt, the difference between set (body.inverters[0].limit_absolute) and get (body.inverters[0].AC[0].Power.v) has to be added to line 262. It can be a negative as well as positive value!

My idea would be that we could show schlimmchen a proof of principle that it works stable and reliable in the Shelly environment. It's a bit slower as the Shelly adds delay to the feedback loop, but it should work in principle I would say. I would be happy to test it! Then it might make it as an improvement to the DTU-OnBattery code. Because in principle it's a DPL issue IMHO.

If it shall be only a show case than there is no need to write good code and push it in an repo, I guess. It will, if I understand you correct only be a short lived change.

Did I oversee something? You think it's worth trying out?

You could implement it, you could talk to schlimmchen but think about the time it takes from schlimmchen to respond to requests. Decide yourself is it worth anybodys time.

[gitisgreat2023]

Implemented it this morning, will let it run a week or two to report back on its stability etc in practice.

[gitisgreat2023]

@genmad how can I upload code here? Can you enable that for me?

[genmad]

So jetzt solltest du etwas hochladen können.

[gitisgreat2023]

Danke! Ich merge erst noch mal meine zwei Versionen (cascade und parallel), da ich nur eine Routine modifiziert habe. Dann ist alles in einem script, cascade, parallel und natürlich die get/set mismatch compensation für die WRs.

Edit: done, alles ist in einem script. Kaskade läuft immer noch prima. Parallel bin ich noch zum ersten Mal richtig am testen. Beim HMT 2250 habe ich das Problem das bei grid 0W inverter power bei 125W ist (Limit 151W) und sich dann nichts mehr tut.... Inverter bleibt auf blauen Status wo er eigentlich auf gelb gehen sollte. @Manos1966 kennst du? Woran liegt das? Min Power in oDoB ist 45W.

[Manos1966]

Ja, deswegen bin ich auf Kaskade geblieben.

[gitisgreat2023]

Hmm interessant. Waren es genau die gleiche Symptome?

Ich probiere mal rum ab wann es nicht mehr auftritt. Hast du da einen Wert? Für welchen WR?

Warum funktioniert mein 1500er ohne Probleme? Es ist nur 1 MPPT mehr beim 2250er… (750W pro MPPT jeweils hőrt sich ähnlich an…)

[Manos1966]

Ich habe HM1500 und HM800
Ich habe nicht viel probiert, ich habe (damals) Probleme mit der parallelen Version und bin direkt bei der Kaskadierung geblieben.
Ich dachte damals das Problem liegt irgendwo bei mir und habe nicht weiter gesucht.

[gitisgreat2023]

Ich habe zwei Fehler behoben und jetzt läuft er gut. Das Problem was ich oben beschrieben habe ist damit auch erledigt. Leider wenig Sonne hier, also nicht viel getestet. Ich lade es trotzdem hoch, ihr könnt gerne mal testen.

Annahme: am oDoB 1 hängt einen Wechselrichter und Huawei charger, an oDoB 2 nur einen WR.
Das Skript könnte auch leicht angepasst werden dass zwei Huawei charger geregelt werden bei Überschuss (Analog zu den WR Regelung, cascade oder paralell).

edit @genmad sorry kenne mich mit github nicht aus, jetzt habe ich es zweimal hochgeladen... :-(