Closed MarcoFace closed 9 months ago
MarcoFace
commented
9 months ago Interestingly the SolarEdge inverter (PV inverter at -2W) shut itself down due to too high net voltage (252v). Dumping the battery at max rate during solar peak of the day might have pushed the local net voltage over the edge....
dirkjanfaber
commented
9 months ago Checked your site and you have the Dynamic ESS mode set to value 0 (off). That explains it.
You can re-enable it by clicking on the inject node:
To add to this. Graphing your vrm logger data shows that after the mode changed to 0, the battery started discharging.
MarcoFace
commented
9 months ago Hi Dirk-Jan,
Dank voor de tip. Ik heb de knop aangedrukt en in de console staat de D-ESS status op unknown zoals het zou moeten.
Het algorithme is ook bezig met acties maar ze komen niet overeen met de geplande acties...
Deze ochtend tussen 07.00-08.00am had het algoritme gepland om de battery tot min. SOC 15% te legen maar deed dit niet. Hieronder de screen shots van het plan en wat er gebeurde met time stamps.
Zoals je ziet gaat het algoritme pas vlak voor 09.00 proberen om max vermogen de battery te legen maar dit lukt niet in die korte tijd en na 09.00 stopt het met proberen...
Plan waar tabel overeen kwam met de planning grafiek die niet zichtbaar is in de screen grab:
[image.png]
But the system keeps charging some of the MPPT Solar.
However this is leads to unnecessary battery losses where immediate inverting to AC would be way more efficient.
Secondly the system could reduce the grid use during a peak price period but it does not.
In conclusion this iteration of the system is wasting Kwh during a peak price period contrary to its set goal.
[image.png]
As the 8.00-9.00 time slot was coming to an end the system does start discharging the battery and a slowly increasing pace. However it is not fast enough to stick to the planned schedule.
[image.png]
Going full pace a minute before the end of the hour…
[image.png]
And then after the hour passes the algorithm stops chasing its goal..
[image.png]
So now it is 9.01am and we are not at 16% SOC but 33.3% and the current price window is much lower. Hence the algorithm is not executing to its plan.
Second thing I notice is that the algorithm should have discharged the battery an hour earlier than it failed doing it. Ie. The high price window was 07.00-0.800 and thus it was planned in this hour.
However by 09.00 it had not completed it but did start trying 5 minutes before the end of the period…
Heb ik een instelling verkeerd staan of gaat er iets mis in het algoritme?
Met vriendelijke groet,
Marco
Sent with Proton Mail secure email.
------- Original Message ------- On Wednesday, September 13th, 2023 at 13:10, Dirk-Jan Faber @.***> wrote:
Checked your site and you have the Dynamic ESS mode set to value 0 (off). That explains it.
You can re-enable it by clicking on the inject node: image
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
dirkjanfaber
commented
9 months ago Je plaatjes komen niet door wanneer je op een github issue per mail antwoord geeft.
Het lijkt erop dat de batterijcapaciteit niet goed is ingesteld op je systeem. Zie hier voor instructies om dat op te lossen.
MarcoFace
commented
9 months ago Hi Dirk-Jan,
Ik heb de flow aangepast conform instructies. Met de extra flow erbij werkt het goed!
Vriendelijk dank,
Marco
Sent with Proton Mail secure email.
------- Original Message ------- On Thursday, September 14th, 2023 at 09:57, Dirk-Jan Faber @.***> wrote:
Je plaatjes komen niet door wanneer je op een github issue per mail antwoord geeft.
Het lijkt erop dat de batterijcapaciteit niet goed is ingesteld op je systeem. Zie hier voor instructies om dat op te lossen.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
MarcoFace
commented
9 months ago Beste Dirk-Jan
Hoe gaat het D-ESS algorithm om met de batterij en omvormverliezen? Al die data is aanwezig maar gebruikt het algorithm deze ook?
Zie onderstaande staatje als voorbeeld. Op 28/9 heeft het systeem 2 cycli gedaan met negatief resultaat.
Je kan het enigzins compenseren met de batterij kost parameter of als discount op de verkoopprijs. Echter dit zijn Euro/kwh parameters en niet kwh parameters. Anderzijds zou het algorithm het zichtbaar kunnen maken zodat je als klant weet waar het rekening mee houdt zodat je zelf nog wat kan spelen.
28/Sep Geladen Gebruikt Terug te leveren Terug geleverd Rest in batt Verlies Kwh Verlies% Ochtend 62,74 7,21 55,53 37,43 8,18 9,92 15,8% Middag 61,97 8,02 62,13 52,24 0 9,89 16,0%
Kn prijs/kwh Kn/kwh kn batt/kwh Totale kosten Opbr/kwh Opbrengst RESULTAAT Ochtend €0,23 €11,05 €1,42 €12,47 €0,33 €12,30 €-0,17 Middag €0,26 €16,09 €1,86 €17,95 €0,33 €17,47 €-0,48
Mvrgr,
Marco
Sent with Proton Mail secure email.
------- Original Message ------- On Thursday, September 14th, 2023 at 09:57, Dirk-Jan Faber @.***> wrote:
Je plaatjes komen niet door wanneer je op een github issue per mail antwoord geeft.
Het lijkt erop dat de batterijcapaciteit niet goed is ingesteld op je systeem. Zie hier voor instructies om dat op te lossen.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
dirkjanfaber
commented
9 months ago Op het moment zijn er nog geen extra parameters opgenomen in het systeem om hier rekening mee te houden. Zoals je zegt kan het nu in de formule en/of in de kosten parameters opgenomen worden. Het opnemen van extra parameters om rekening te houden met omzetverliezen staat al wel op de todo lijst.
MarcoFace
commented
9 months ago Hi Dirk-Jan,
Thx voor de verduidelijking. Wellicht een idee om dit te vermelden in de readme tekst omdat niet iedereen dit tot in detail zal snappen. Zeker mensen die hun batterij kosten op 1 cent zetten zullen vaak verlies draaien op de dagen dat de spread te klein is.
Als jullie de efficiency gaan meenemen is een minimum winst % parameter wellicht een idee. Onder dat plafond kan het systeem dan ESS stijl draaien en de batterij inhoud zelf gebruiken.
Ik heb ook zitten rekenen op de salderingsregeling afbouw. Zoals het D-ESS systeem nu draaide in Augustus en September kwam ik op een salderings percentage van 54%-55% uit. Dat is prima tm 2027 in Nederland.
Deze data zit ook in het VRM dus voor de periode daarna zou je het in het VRM kunnen opnemen zodat klanten defacto hun winsteis % kunnen opschroeven om op een salderingspercentage te komen wat maximaal de ruimte benut om te salderen.
Thx en bedankt voor jullie mooie product!
Marco
Sent with Proton Mail secure email.
------- Original Message ------- On Thursday, October 5th, 2023 at 08:26, Dirk-Jan Faber @.***> wrote:
Op het moment zijn er nog geen extra parameters opgenomen in het systeem om hier rekening mee te houden. Zoals je zegt kan het nu in de formule en/of in de kosten parameters opgenomen worden. Het opnemen van extra parameters om rekening te houden met omzetverliezen staat al wel op de todo lijst.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
Contact Details
marcofaasse@protonmail.com
VRM / Site iD
263771
Country / region
Netherlands (nl)
B max
81.2
TB max
36
FB max
33
TG max
36
FG max
43.47
Battery costs
.01
Buy price
(p+.0175+.12175)*1.21
Sell price
((p+.0175+.12175)*1.21)/1.20
feed-in possible
yes
feed-in possible
yes
What happened?
A bug happened! The algorithm 0.1.2. does the opposite of its planning. It is dumping the battery at low prices when it is supposed to charge with the solar energy available...
The plan was to:
What happened was:
Relevant log output
No response
Screenshots