[Bug]: The logic of the algorithm will charge the batteries at maximum load to target without a) taking into account the solar forecast and thus taper the charging and b) once fully charged, with plenty of PV power coming in, throttle down the MPPT chargers and instead take power from the grid at a positive cost. #31
24 (is actually 28.8 but I tried to throttle it down for efficiency)
FB max
24 (is actually 31 but tried to throttle it down for efficiency)
TG max
43.47
FG max
43.47
Battery costs
.05
Buy price
(p+.0175+.12175)*1.21 (ANWB pricing in NL)
Sell price
(p+.0175+.12175)*1.21/1.1 (I use the division by 1.1 to account for the additional inefficiency in the system when operating D-ESS at max charge and discharge)
feed-in possible
yes
feed-in possible
yes
What happened?
A bug is strong wording but the algorithm did not achieve its stated aim in this event on the 16th of July 2023.
Knowing I wanted the system to arbitrage prices I invested in a large inverter setup compared to the battery.
ie. systems that are charge/discharge constraint within the price windows will likely not show this outcome.
Nevertheless it would be great to see the algo working for systems that seek to arbitrage for most of their capacity bandwidth.
Note for the screen shot: With the PV inverter (on AC out) at 819w I would expect the PV Charger capacity to be double that.
The grab was taken at 16.51pm when the battery had been filled since 14.25pm. Given the Solar forecast was reasonable all afternoon I did not expect the algorithm to switch off/partially down throttle (both states were observed on the day) the MPPTs.
Free solar is always better than paying energy tax on slightly negative prices.
Same situation repeated on 25/7/2023
The D-ESS plan was:
As seen in the schedule the plan was to charge very high up even though there was a lot of PV power forecasted by the VRM model. Once full the algorithm kills the MPPTs and keeps them off until 17.03 even though there was a good market price the previous 2 hours.
MPPTs of shown on dashboard on 14:55
and MPPTs still of at 16:45
As the algorithm cannot predict perfectly how much solar is still to come some prudence seems logical. However the algorithm should not kill the MPPTs in this scenario but rather deliver back to the grid and optimise profit.
I think I understand why the MPPTs are switched off but it is still an issue.
It looks like when the wholesale prices are negative after reaching full charge the MPPT's are switched off.
However the Sell price is not negative at all during this time due to energy taxes etc.
Hence it would make much sense to reference each installations Sell Price < 0 before switching off the MPPT's rather than the wholesale prices or at least make it a separate option. thx
Forget the last comment. I turned of the toggle "Feed-in-control" in the Dynamic ESS node as that is intended to avoid feeding in at negative prices. However with the toggle turned off the algorithm still switches off the MPPT arrays when the battery is full even though there are positive sell prices (based on my sell price setting) in the hours thereafter and it would be more profitable to feed back the MPPT energy. On a sunny day this bug will waste a few hours of free solar energy.
section b) of this issue has been sorted. To ensure the MPPT's keep working once the batteries are full I had to change a setting in the ESS/Grid-feed-in where both AC and DC coupled PV's are allowed to feed in. The algorithm uses this setting to decide what to do so nothing to do with the Dynamic ESS it seems.
We've just published a new release, that is more incorporated into the Venus OS and follows the target SOC instead of setting a setpoint and a less than ideal way of idling the battery.
As this uses a different approach, you will need to:
update Venus OS (to 3.10 or above)
update the victron-dynamic-ess node to version 0.1.1
update the example flow
reconfigure the Dynamic ESS node (as it uses VRM portal ID instead of the Site ID)
Ik heb Venus OS Large ge-update naar 3.10 maar de victron-dynamic-ess noder versie is nog steeds 0.43 en er is geen 0.1.1. versie beschikbaar in node red die ik kan installeren?
------- Original Message -------
On Tuesday, September 12th, 2023 at 17:07, Dirk-Jan Faber @.***> wrote:
We've just published a new release, that is more incorporated into the Venus OS and follows the target SOC instead of setting a setpoint and a less than ideal way of idling the battery.
As this uses a different approach, you will need to:
update Venus OS (to 3.10 or above)
update the victron-dynamic-ess node to version 0.1.1
update the example flow
reconfigure the Dynamic ESS node (as it uses VRM portal ID instead of the Site ID)
De 0.1.1.update is gelukt en het draait allemaal met groene status.
Alleen het DESS dashboard kan ik niet benaderen.
Venus OS en node red draaien op de Cerbo GX en ik heb geen idee hoe ik daar bij kom?
Wellicht kunnen jullie voor de niet IT-ers een kleine hint in de readme zetten hoe je bij die locale pagina komt op een Cerbo GX?
De Graphs niet zien is niet ideaal omdat je dan niet kan zien wanneer het systeem gaat arbitreren zodat je daar geen rekening mee kan houden met EV laden etc.
toevoegt aan de flow, dan krijg je een linkje vanaf de dashboard pagina. Wellicht is dat het eenvoudigste.
Op je lokale netwerk kun je er via https://venus.local:1881/dess ook bij. En wanneer je de "Node-RED dashboard" knop op VRM aanklikt en dan het laatste stukje van de url aanpast ui in dess, dan kom je er ook.
Bedankt voor je snelle reactie!
Dat werkt prima idd.
Helemaal top.
Ik had nog een brain wave aangaande de efficiency van de D-ESS systemen van jullie klanten en specifiek hoe het D-ESS algoritme hier mee om gaat.
Momenteel verdisconteer ik een arbitrage rondje batterij en terug (+/- 20% verlies) in de Sell Price van de node settings. Zodoende gaat het systeem niet arbitreren als dat verlies gaat opleveren bij een te kleine inkoop-verkoop prijs delta.
Echter jullie hebben van alle VRM sites alle gebruiksdata dus het algoritme kan hier zelf rekening mee houden en hier een parameter per site voor genereren welke het algoritme gebruikt.
Het voordeel is dat de grafieken dan kloppen want nu verdisconteer ik een Kwh verlies in de Sell Prijs waarde. Sommige klanten hebben het efficiency verlies wellicht niet eens in de gaten en maken veel meer kosten dan ze bij voorbaat verwachten.
Enkel met de battery cost variabele spelen werkt niet want dat is een Euro gebaseerde variable en niet een in Kwh uitgedrukte variable.
Wellicht heb je hier wat aan.
Met vriendelijke groeten en nogmaals bedankt voor je snelle reactie!
toevoegt aan de flow, dan krijg je een linkje vanaf de dashboard pagina. Wellicht is dat het eenvoudigste.
Op je lokale netwerk kun je er via https://venus.local:1881/dess ook bij. En wanneer je de "Node-RED dashboard" knop op VRM aanklikt en dan het laatste stukje van de url aanpast ui in dess, dan kom je er ook.
image
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>
De nieuwe release lijkt niet het geplande schema af te werken.
Het plan was:
[image.png]
Maar om 7.00am staat het systeem nog maar op 22%SOC ipv de geplande 50%SOC.
[image.png]
Ook was het algoritme enorm aan het laden vlak voor 7.00am terwijl de prijs dip tussen 5.00en 6.00 was vandaag en er juist een beetje ontladen geplaned was na 7.00am.
Er lijkt iets niet goed te gaan in de nieuwe release.met de uitvoering van het schema.
MarcoFace
commented
11 months ago 
dirkjanfaber
Contact Details
marcofaasse@protonmail.com
VRM / Site iD
263771
Country / region
Netherlands (nl)
B max
86.4
TB max
24 (is actually 28.8 but I tried to throttle it down for efficiency)
FB max
24 (is actually 31 but tried to throttle it down for efficiency)
TG max
43.47
FG max
43.47
Battery costs
.05
Buy price
(p+.0175+.12175)*1.21 (ANWB pricing in NL)
Sell price
(p+.0175+.12175)*1.21/1.1 (I use the division by 1.1 to account for the additional inefficiency in the system when operating D-ESS at max charge and discharge)
feed-in possible
yes
feed-in possible
yes
What happened?
A bug is strong wording but the algorithm did not achieve its stated aim in this event on the 16th of July 2023. Knowing I wanted the system to arbitrage prices I invested in a large inverter setup compared to the battery. ie. systems that are charge/discharge constraint within the price windows will likely not show this outcome. Nevertheless it would be great to see the algo working for systems that seek to arbitrage for most of their capacity bandwidth.
Note for the screen shot: With the PV inverter (on AC out) at 819w I would expect the PV Charger capacity to be double that. The grab was taken at 16.51pm when the battery had been filled since 14.25pm. Given the Solar forecast was reasonable all afternoon I did not expect the algorithm to switch off/partially down throttle (both states were observed on the day) the MPPTs. Free solar is always better than paying energy tax on slightly negative prices.
Hope this helps and thanks for the great work!
Relevant log output
No response
Screenshots