Problem with DESS

I’m starting a new topic now, because the old one became a bit confusing.

First of all: I have installed the smartshunt in the meantime, it has been running for 6 days, nothing has changed.
I also work in green mode, the way this mode works should be familiar.

Almost every morning, energy is drawn from the grid as the system tries by all means to meet the SOC target.

See the following example from just now:

Screenshot 2024-09-17 101404

At 10:00 a.m., the target SOC of the forecast jumps to 86%, the battery SOC is 61%. Now the battery starts charging with 2 kWh, the missing energy that the PV system does not supply is drawn from the grid. I turned on the stove for testing, nothing changes, the missing energy is drawn from the grid, the battery is charged in any case with 2 kW, from the grid.

I just want to know from Victron whether this is intentional or whether this could be a faulty configuration on my system.

In my opinion, in this case, the energy should come from the battery and the forecast should be postponed. It really doesn’t matter whether the battery SOC of 100% is reached at 11, 12 or 13 o’clock.

And that is the result from 10 to 11 a.m.

image

Mains to battery 0.37
Net consumption 0.47

If the battery charge had been reduced in the hour, I would have no purchase from the grid at all.

That is a commonly appearing behaviour. Either it is a (ongoing) Issue, or DESS is smarter than we are :wink:

Today, I was having the same Issue as well - but when looking at the current values, WHEN this is happening, it starts to make certain sence - just the DESS Graph does not outline the detail behind:

What DESS in Fact is doing in my case: Using the DC-Connected Charger to already charge the battery, using the AC-tied inverter + grid to sustain the loads.

The graph in VRM however considers this a “Grid2Bat” as in your case.
VRM is basically thinking: Consumption = PV, so we have that 479 from grid going in the battery.

With regards to current grid prices, it may indeed be “optimal” to use a certain amount from Grid NOW to directly power AC-loads, over having additional DC-AC conversion losses and later on add another round of losses, when doing Grid2Bat / AC-DC again to charge the battery later.

So, even if DESS is showing Grid2Bat in the graph - it is in Fact Solar2Bat and Grid2Consumption that is going on.

image


However, there is a second, older issue, that DESS is working with a “hourly target-soc” - and if that soc is not reached by the hour, it will do “something” to achieve the soc, like charging from grid. Thought this was resolved, but in the past days, there have been many posts, starting to report exactly this behaviour again, see for example:

I understood your explanation, but I don’t agree with it. In my case, PV was easily enough to supply the load, but the battery was still charged to reach the target Soc. I don’t really care whether it’s a mains to the battery or a mains to the load. That’s just for statistics.

It would have been right to have no supply from the grid at all, that would have been quite simple, simply charging less battery, lowering the forecast and thus the SOC target.

But using your available DC-PV to supply the AC Loads over charging the battery would have “lowered” the absolute gain by probably 15-20% due to required DC-AC conversion.

And at the end of the day you still need a certain amount of energy IN the battery. If you then have to compensate that (later) through a lossy AC-DC conversion, you are spending 30-40% more energy throughout the day compared to minimizing conversion losses and utilizing the Grid for “AC” loads earlier.

But this all stands and falls with proper “forecasts”. If you have enough solar later that you would even need to feed in - then the plan/schedule/forecast wasn’t accurate.

I absolutely agree that my first thought also was: “Why is it pulling from grid, over stopping charging and 100% covering the loads?”

Thats the point!

Even if I have 5% more conversion losses from DC to AC, it is still better in this case to empty the battery first instead of drawing power from the grid.

To see who is right (DESS or you) we would have to await the end of the day.

  • If you reach 100% SoC and feedin - DESS more likely made the wrong decission.
  • If you don’t reach 100% SoC - DESS made the right thing by minimizing the overall required amount of Energy during the day by keeping conversion losses to a minimum.

It’s more than 5% losses, for sure. If you have MQTT / SSH Access, you can lookup the value DESS is assuming for your system, under: settings/0/DynamicEss/SystemEfficency For me, it is assuming 10% losses currently.

image

And this value would be off “twice” when doing DC-AC and AC-DC conversions that could be avoided.

I currently have 100% SOC at 12 o’clock every day and the battery almost always lasts through the night. Therefore, the forecast could have been easily postponed.

When you reach 100%, then you are right. Then the system should have concluded that it “is not necessary to grid-pull” by now. (Which I was discussing a few times with victron officials, but without receiving a proper statement if this would be fixed).

As it stands DESS has the possibility to postpone it’s soc-schedule - but it is unclear (to me) when and why it will do that - and when it will stick to plan. (Also there is no way to configurative take influence on this)

What do you think about reducing the maximum charging power of the battery, so the next planned SOC would automatically be lower.

There are also user-topics that DESS will feedin available pv-power, when the target soc is reached to early - which is also irrational. So, lowering the DESS-forecast values (if that takes impact at all) would most likely result in this behaviour taking place.

Yes, I’ve had that case several times, but better than pulling it out of the grid, I’ll give it a try.

@dfaber

And once again the same problem, DESS charges the battery from the grid, although the forecast says that 100% SOC will be achieved. This is now the 6th day in a row where this happens.

I can’t understand that and switch off DESS except for an explanation from Victron.


image

Hi @BuBu . Together with a colleague we’ve been looking into this. While knowing what the cause is, it wasn’t easy to come up with a solution that doesn’t just work for systems like yours, but won’t hurt other systems out there.
We are quite sure that we found a solution that covers that. At the moment we are working on implementing it, which should be ready later today. We will initially deploy the fix on a limit set of systems (including yours), before releasing it for the other users.

Thank you for your patience and I’ll post here as soon as it has been deployed.

1 Like

Hello Dirk-Jan,
Will you post here on which limit set of systems Victron initially deployd the fix?

Yes, I can do that. And I can include yours if you want to.

You can do that, but I turned of DESS…

Hi Dirk-Jan, I am having the same problem and had to switch DESS off. Can you also deploy it for my system?

At the moment it has been deployed for the sites:

  • Bubu 202328
  • VictorB 236213
  • Tom Gans 333216

I know you will, but please keep an eye on it and provide feedback. I will be away from the keyboard most of tomorrow, but will also check.

Can you provide some details about what the change is to understand if it would help with issues I see? Is the fix in a github branch for example?

1 Like