DESS: Totally unexpected Grid-To-Battery

Question

question

dognose asked Jun 15, '24

DESS: Totally unexpected Grid-To-Battery

I'm using DESS since a few weeks now - and occasionally it does some total unexpected Grid-To-Battery-Charging:

Example Today:
- Solar Forecast is 66 kWh
- Battery is around 83% SoC already
- Energy prices are "high", with a definitie LOW later at 2pm

Yet, DESS decided that it has to charge 2.4 kWh from grid at 10am...

Any Idea what could be a trigger for this strange behaviour?

I mean, even if there wasn't sufficent solar expected - shouldn't the grid-to-battery have been scheduled for 2pm, when energy prices are basically halfed?

This has nothing todo with accuracy of the forecasted data id say - even with the forecasted data, this is strange.

dynamic ess

screenshot-20240615-113226-chrome.jpg (295.4 KiB)

screenshot-20240615-113244-chrome.jpg (376.3 KiB)

screenshot-20240615-115135-chrome.jpg (255.8 KiB)

2 |3000

Attachments: Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Modifications Space

Node Red Space

Answer 1 · 2024-06-16T10:33:27Z

dognose answered · Jun 16 at 10:33 AM

Again today at 10...

1000024275.jpg (345.1 KiB)

1000024276.jpg (381.6 KiB)

2 |3000

Attachments: Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Answer 2 · 2024-06-16T11:37:36Z

dutchsolarfreak answered · Jun 16 at 11:37 AM

In general DESS behaves like this:

As far as I know (and observed in my systems) if target SOC cannot be reached at the end of the hour (due to missing sun for example) DESS tries to reach target SOC by charging the battery from grid.

Sometimes even when DESS charge battery from grid is disabled!!!

My observations are that if DESS is enabled the ESS settings are not always respected.

For example the ESS max charge/discharge current limits, especially the MAX charge current limits are exceeded.

From my point of view this is not correct. As I said it just my option.

5

2 |3000

Attachments: Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

dognose commented · Jun 16 at 11:47 AM

Yeah, it looks like it calculates a target soc per hour, but if there is less Solar than expected, it pulls from grid.

That would make sence, if you manually setup target SoCs to be reached, for instance because you're in a ship and will sail away at X.

However for a Home System, this is pretty strange. Especially when there is enough solar and/or cheaper grid prices later the day...

0 ·

dognose commented · Jun 16 at 11:53 AM

Yeah, most likely that's the issue here, from the docs:

Also keep in mind that, when doing a consumption forecast, the system does not known when during the hour that consumption will be done. If the forecast does not match the reality, Dynamic ESS does keep the planned battery usage stable while punishing the forecast inaccuracies on the grid (selling the excess to grid, buy the additional need from the grid). This can be less ideal, but it is an issue of the forecasts being inaccurate, nothing that the Dynamic ESS decided.

I have a total of upto 18kW "sinks" which I orcestrate to consume solar overhead, while having a battery reservation.

(Ev, electric water heating, pool heater, some micro consumers)

So, guess these are kind of impossible to predict for the forecast as they are dynamically turned on, when excess solar is available.

I will reconfigure DESS so the "maximum charge power" matches the reservation I've setup.

Maybe that reduces the offset and grid compensation, because DESS does no longer expect to be able to charge the battery at 14kW. (Using a reservation of 3000, this is sufficent for summer time)

---

But anyhow: offloading the "missing soc level" to grid-pull should at least undergo another recalculation of soc levels, taking estimated solar and grid prices into account.

0 ·

dognose dognose commented · Jun 17 at 12:13 PM

I will reconfigure DESS so the "maximum charge power" matches the reservation I've setup.

Maybe that reduces the offset and grid compensation, because DESS does no longer expect to be able to charge the battery at 14kW. (Using a reservation of 3000, this is sufficent for summer time)

Yeah, it reduced the amount drawn from grid in the morning... But never the less, pretty annoying to have DESS compensate the soc level on a per-hour basis.

Renders it pretty useless, if the prediction is a bit off, it will either pull or feed to the grid rather than working "efficent"...

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ dognose commented · Jun 17 at 12:57 PM

That is not entirely true. During quite a lot of hours we ignore the target SOC. It depends on which strategy it works with during that hour. If the dbus value of com.victronenergy.settings, path `Settings/DynamicEss/Schedule/0/Strategy` value is set to 1, the SOC is being ignored.

Setting that strategy depends on a few parameters, mainly the buy price being in the high region of the day.

0 ·

dognose Dirk-Jan Faber (Victron Energy) ♦♦ commented · Jun 18 at 08:08 PM

@Dirk-Jan Faber (Victron Energy) thx for some insights on that. But didn't apply in my situation, cause the buy price was "medium".

So, despite any strategy that might be selected:
between 10 am and evening, there is a lot of PV coming in. Strategy "Uh, I need to buy at 10am for 19 ct, cause I only have 76% instead of expected 85% Soc, that estimated 71 kWh solar can't fix that - and the later energy price of 9 cent is also to be ignored" - doesn't just seem all to strategic overall.

I think that has room for optimization: Basically the schedule already calculated the next (estimated) discharge start, say according to the graph at about 6p.m. - so it wouldn't be too complicated to do another what-if check, before attempting to charge from grid: what-if I don't charge now - do I reach TargetSoc @ 18pm? If yes, abortCharge(), if no, startCharge() - and absolute premium would be a second check in startCharge() and may be calculate a more ideal time for the grid-punishment.

The later one would in this case (10 to 18) be 8 more "what-if" checks, sorted by "SocReached at DischargeStart" as primary condition and "total costs" as second.

Something like:
- Charging (now) at 10: SocTargetReached True, total costs 38ct
- Charging at 11: SocTarget Reached True, total costs 34ct
- Charging at 12: SocTarget Reached True, total costs 28ct
- Charging at 1 pm: SocTargetReached True, total costs 24ct
- Charging at 2 pm: SocTargetReached True, total costs 20ct
- Charging at 3 pm: SocTargetReached True, total costs 18ct
- Charging at 4 pm: SocTargetReached True, total costs 24ct
- Charging at 5 pm: SocTargetReached False, total costs 30ct

0 ·

Answer 3 · 2024-07-17T18:41:22Z

marcmanusch answered · Jul 17 at 06:41 PM

I have exactly the same issue! The system load the battery at 10:00 from grid. The SOC is around 80% and many solar is left on this day. The energy price is not low at the moment.

The system buy energy and waste my money.

It need to be fixed, I want to use DESS, but this is not a feature, it’s a BUG.

img-8217.jpeg (516.6 KiB)

img-8216.jpeg (273.2 KiB)

1

2 |3000

Attachments: Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

dognose commented · Jul 19 at 02:31 PM

It need to be fixed, I want to use DESS, but this is not a feature, it’s a BUG.

From a Software-Developer Point-Of-View: I just can agree.

Same for me, I have a dynamic tarif, so i'd love to use DESS - but if it buys energy during "sunny days" just because "it sticks to a plan" - it's none-sence, unusable.

1 ·

Answer 4 · 2024-07-20T07:06:59Z

marcmanusch answered · Jul 20 at 07:06 AM

@Dirk-Jan Faber (Victron Energy) please fix, it makes no sence.

img-8270.png (232.7 KiB)

2 |3000

Attachments: Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

question