Runnning DESS in greenmode, there was a relative low (dynamic) price bracket the past night, considering the season we are in
I charged my batteries overnight, expecting green mode to use stored energy for consumption only. But DESS plan for later today seems to implicte it will sell off during evening peak.
Can someone explain greenmode stating “only sells surplus solar” and “energy in battery is reserved for consumption” against the DESS plan to sell of non-solar
I don’t think the days plan changes instantly when you change mode. I assume there’s an automated job that pulls in new data from your energy supplier and tweaks the plan periodically. I’d check back in 3 to 6 hours.
Disabling and then re-enabling DESS seems to force a plan update.
Under normal conditions the scheduler takes upto a quarter hour to incorporate settings changes and push a new schedule. But lately we have been experiencing multiple periods of days in a row where that schedule update delay is late by upto 4 quarters.
The scheduler currently looks as far as it knows what the prices are (so until the end of today) and schedules for the known part. As soon as the new prices are in it will look beyond that and update the planning.
I admit that this isn’t ideal and we have a patch for that under review.
Wouldn’t you agree that it is less of an issue that the scheduler won’t look beyond the end of the known prices period, and more a matter of not having a (straightforward) option to choose how much energy it should plan to keep in reserve at the end of today/tomorrow instead of defaulting to ‘none’ (targeting MinimumSoC).
Experimenting with a large (virtual) consumption forecast adjustment for the last hour of the known prices period (automated to roll to the next day right after the new prices roll in) has shown to provide a well functioning workaround to achieve precisely this, albeit in a somewhat clumsy manner such as distorting the forecast graphs.
The results over the last weeks show this to be an effective way to overcome the ‘sell to MinimumSoC’ bias, fully eliminating the ‘DESS doesn’t buy the cheap energy in the morning/early afternoon’ that has been a recurring theme for quite some time now. It’s particularly noticeable when the price volatility increases these months March, April, May with unpredictable weather.
For those of us using Node-RED to fine-tune DESS, the singular solution that provides all the control we could wish for, is to be able to patch forward looking SoC target(s) to the scheduler algorithm. The API endpoint exists already and even the GUI already has entries for this, but both are disabled when running DESS.
