[Feature]: Is the change from steering from Gridpoint to SOC the best choice?

[MichaKersloot]

Contact Details

No response

Description

I'm not sure if i'm disrupting the current process, but I want to bring my opinions about the change from setpoint to SOC steering.

It looks like this change makes the system less flexible to real-life changes. For example if on an hour there is more sun as forecasted the system will stop charging the battery when it reaches the configured soc. It even could be it will be charging from the grid the next hour, when the prices have gone up. It good be the 'disable battery' was technically a problem, but the system as a whole worked quite good and maybe more important predictable.

In general I've seen the system feeding to the grid and charging from the grid more than in the previous versions. I'm not sure if this is a bad, or good thing as I don't have detailed insights in the system loses. I assume are higher when charging from the grid than when you charge from the MPPT solar. Looking at the sell and buy prices I've configured it doesn't have much sense to sell during the day as the sell price is lower than cheapest buy price for an extended period.

Last comment. I still use your system with a positive vibe. Even if it is not squeezing the last cent of profit I do see it getting better and better and not having to worry is a great plus for me also.

Suggested Solution

Just to express some thoughts from a user perspective.

Alternatives

I have been looking to https://github.com/corneel27/day-ahead but implementation is complicated and depended on extra hard and software.

Additional Context

No response

[pokeplayer2]

Please never stop charging the battery before 100% is reached from solar if the sun is shining ... the price of the energy from solar is in 95 % of the cases cheaper as from grid for most of the people!

[pokeplayer2]

loading battery is limited and solar power goes to grid :-/ linear changing

[pokeplayer2]

selling to grid and battery is not full only 62% :-/

[MichaKersloot]

Please never stop charging the battery before 100% is reached from solar if the sun is shining ... the price of the energy from solar is in 95 % of the cases cheaper as from grid for most of the people!

Don't think this is the case. It could be better to sell the electricity now directly via the grid and charge the battery later when the prices are lower. If you base your calculations all on predictions, this really makes sense. The problem is when reality is (a lot) different from the forecasts.

[MichaKersloot]

I'm more concerned about the consequences as seen at 9 o'clock in this graph:

buy: 2,803 0,317 = 0,889 sell: 2,661 0,38 = 1,011 profit = 0,122 extra costs = 0,205 * 0,439 = 0,09

This is more than 60% of the profit lost, just by overshooting at 9 to charge the battery from the grid.

[pokeplayer2]

moments where we have to switch off dynamic ESS .... it's not dynamic ;-)

[pokeplayer2]

I'm more concerned about the consequences as seen at 9 o'clock in this graph:

buy: 2,803 0,317 = 0,889 sell: 2,661 0,38 = 1,011 profit = 0,122 extra costs = 0,205 * 0,439 = 0,09

This is more than 60% of the profit lost, just by overshooting at 9 to charge the battery from the grid.

Same for me today ... ignore the best time to load the battery

[dirkjanfaber]

What was the vrm id of that site again?

[pokeplayer2]

and my is I think using of SOC value is OK if the SOC value is only a minimum value to block discharging if battery is already on <= value .

[dirkjanfaber]

@pokeplayer2: Quite sure that your issue is not the same as the one of @MichaKersloot. In his case the system is not ignoring the best time to load the battery, but blaming the grid for not reaching the target SOC (and thus charging from the grid at the worst time possible). With the current system, which is blaming the grid, this is not optimal. The plan is to add extra controls soon to prevent that. So at the moment it is unwanted, but expected behavior.

Then for your problem, @pokeplayer2. First of all I'd like to ask you to create a new issue if the current issue does not match the issue you are posting the "me too" in. Sorry to be a bit pedantic about that, but it makes it a lot easier for us to keep things separated and traceable. Luckily, in this case, the solution does match the problem of Micha. The soon to be added controls should allow you to prevent discharging to the grid. So here too the behavior is unwanted, but expected.

In both cases please wait a few more days until the solution will be rolled out. It will definitely require a Venus firmware update (just checked if the feature is in 3.12, but it is not).

The new control will probably be called/Settings/DynamicEss/Restrictions under com.victronenergy.settings and gets three possible values:

• 0 = No restrictions
• 1 = No exporting from battery to grid
• 2 = No importing from grid to battery

[MichaKersloot]

Hi Dirkjan,

I've noticed our problems are not the same ;-) Is this new setting dynamically used by DESS, or a global setting that the user has to set?

[dirkjanfaber]

The idea is that the first implementation is global, and afterwards it will be schedule based over rulable as well. Which is not to say that the public implementation can't end up differently. We are still testing and tweaking.

[pokeplayer2]

Thx! I will wait for the new version which sounds like a bigger change.