DynamicESS & Tempo not working as expected

Q&A and troubleshooting DESS
, , ,
1

Hello,

I have a mulitplus II with a Cerbo GX and I live in France. I have an EDF Tempo contract so I activated the Dynamic ESS feature (with BatteryLife activated) in Green mode.

Unfortunately it doesn’t work as I expected. I did an analysis over the “red” days of January (see attached files) and among the 6 red days of January, I’ve been able to avoid using the grid during the costly hours only once ! While with the batteries I could have avoided completely that usage I think.

Here are the two problems I observed:

  1. During the night I would expect the system to charge fully the batteries, but usually it charges them a bit towards the end of the night, but not completely at all ! Consequence is that during the day there is not enough in the batteries and I have to consume from the grid. The only reason I see for the multiplus to not charge completely the batteries is if he thinks that he’ll have enough with let’s say 50% batteries + the solar production for the day. But as you will see in the files, we are far off ! As my consumption is fairly stable over the days, my only guess is that he is way overestimating the solar production. Unfortunately I don’t see how to access the production estimates in the past (to compare them with the actual). But I doubt it’s that because usually when I check towards the end of the day, the estimated production is close to the actual. Any idea ?
  2. It seems that often, instead of starting by using the batteries, he keeps the battery usage for the end of the day. Consequence is that if the PV production is higher than expected or if the consumption is lower than expected, we will consume grid while we could have used battery. The only explanation I see for this behavior is to “keep the batteries at a high level of charge as long as possible, while still aiming at the optimum in terms of cost”. I could understand this design choice, but can someone confirm me it’s a design choice ?

2

3

No one to help me with this ?

4

Does this have a dynamic pricing? Or is it fixed windows where it is cheaper?

If it is fixed windows then disable dynamic charging and use ESS scheduled charging.
There you can set up times and sources for the power you want to use such as pv or pv and battery and also set different levels for state of charge in different windows.

5

Yes it’s a dynamic price.

Some days are blue, some are white and some are red. Then there is a price depending on the hour (fixed ours). The low and high price depend on the color of the day. The color of the day is published the day before.

Victron recognize that type of contract and get the color and the prices automatically. It works fine according to the graphs. The prices displayed are correct.

6

Hi,

had some time to look at your system and the days reported. Let’s first a bit recap the situations you are seeing on these days, what is supposed to happen - and what happens:

You have quite expensive purchasing from 6 to 22 during red days. Your sunrise (solar wise) seems to be around 10 and the day yield varies.

So, in the morning, before 6, the scheduler however concludes that your days solar yield will be sufficient energy to cover sunset to 22.

Thus, the only energy that needs to be purchased for your system is to cover 6~10.

on 5th January DESS scheduled 1h 15 min to charge at (start rate) 3570Watts, so roughly 4.5 kWh. That would have been a quite matching amount for your 6-10h - but your system didn’t charge as expected. It only charged with ~ 390 Watts which wasn’t enough to gather the energy required.

Why did that happen? I can see, that short before the charging should have started, your active soc limit raised from 25% to 30%, while your battery was at 26%. This immediately caused your system to fall into #1:ESS-LOW-SOC, where ESS-Mechanics are taking over the wheel.

So, that was probably the ESS-Battery-Life feature adding another 5% to your minimum soc, and causing that “slow charging” bellow minimum soc, ignoring instructions send by DESS.

On 26 Feb, that 5% hit you as well - but at 13:00 during noon:

  • The amount purchased from the grid before 6:00 would have been quite precicesly be enough until 14:00, when solar > consumption (as forecasted); but at 13:00 your min soc raised from 20% to 25% making the system unable to discharge any further.
  • Your consumption on that day was higher than expected, and you just lost 5% usable soc; So, there wasn’t enough battery to make it till 22:00.

To avoid this happening again, you should not use ESS-BatteryLife along with DESS, use the scheduled battery balancing of DESS instead. That 5% of suddenly unavailable Battery-Capacity will ALWAYS mess with the DESS schedule, not just in very special cases like this. Especially during winter, when it is almost certain to not reach 100% - your DESS Schedule is basically short that 5% every day.

I’m not part of the scheduling team, but have a quite good understanding of it, so to also answer your general questions about the scheduler:

Yes, that is absolutely how the scheduler plans: Purchase operations are always moved to the very end of equal-price-periods - because then most time has passed, and the amount that is concluded to be charged depends on “less far away” predicted targets and better known “current values”. (Hence most the time is more accurate to conclude the amount that really needs to be purchased)

And the same is basically true for discharging, IF you would also discharge to grid. Later discharge gives you the “most recent values” to conclude how much really can be discharged. And that logic just seems to remain the same, even if you don’t want / cannot discharge to grid.

This seems to stick out for price-characteristics like your system has. With a more dynamic (15 minute pricing) the battery usage is quite well allocated according to alternative sourcing costs and you don’t notice the “at the end of same-price-periods phenomena” at all.

I’ll discuss this with the scheduler team, as I can see that discharging early in that periods may eventually be better (but there may be other reasons i’m not yet seeing)

7

Thanks a lot for the investigation and the explanation. I’ll disable the BatteryLife to confirm that this solves the issue. I’ll keep you posted.

1 Like
8

I forgot to say: you should probably add in the doc somewhere that BatteryLife should NOT be activated along with Dynamic ESS.

Regards

1 Like