DESS System Efficiency (/Settings/DynamicEss/SystemEfficiency) Is one way only to the battery. So grid-to-battery and pv-to-battery .
You can either lower this efficiency to the round trip, let’s say 83%.
Or you can set this efficiency to 100% and increase the buy price with let’s say 11% and decrease the sell price with let’s say 8%.
Both methods work well. I tested this in my system.
Agreed. But let’s make the most out of it while we still can.
How about the losses when discharging, is this efficiency factor also used for calculation?
Update: After calculating and raising the efficiency to 87% I see that it matches loss in the dess planning so the factor is for charging and for discharging. I lowered it to 85% so charging from and discharging to grid is only done when it is more profitable.
Seems an old discussion for which many have at mentioned Dirk Jan but I have never seen a response. You posted a link to the other topic and my test results confirm that (and I have done many…). It’s round trip. So if:
buy is 20, efficiency is 80% and battery costs at 4 cents, sell has to be 20+4+4 before DESS says it’s profitable.
I don’t like this round trip approach very much as I have a mix of MPPT chargers and Solar Inverters. Basically the inverters have to use the efficiency value just like buying from grid. But the MPPT charger has to pass an inverter at least once (unless you have DC loads) no matter if stored in battery first or inverted directly. In other words, the 10% inverting losses are inherent to having MPPT chargers. So there’s something to be said to ignore inverting efficiency for MPPT DESS calculations.
But this would mean there are a lot of moments in which PV inverters will sell to grid whereas MPPT PV will charge the battery due to being 20% less expensive (in the above example 20 cents would only need a 24 cent or more sell price to become profitable.
I think you’re right, the battery cost in my case is 0.03 euro per kWh, and it does discharge now while it’s not profitable. So that proofs it’s round trip efficiency.
Please note that it seems to happen more often. Today is a day with no apparent trading opportunity for the first time in months but my system is storing PV in battery due to scheduler instructions: PROBATTERY / SELFCONSUME_ACCEPT_CHARGE.
The system of a friend experiences the same behavior right as I’m typing this.
Can the scheduler team please look at this?
Dess did a pretty nice job today, only some dischargings to grid during the ac pv charging period, probably because the bat2grid restriction was not activated I think in combination with a target soc lower than the actual soc in the beginning of the hour.
I think when bat2grid restriction should only be deactivated when battery energy is sold to grid.
Now in Autumn less solar power is generated so it’s better to keep some extra in the battery for own usage after selling electricity to grid.
So as mentioned earlier a minium soc for selling power under which the electric energy will be kept for own usage would be a good addition to dess.
Can this be implemented?
[Dynamic ESS] Add SOC level, below which NOT TO SELL energy to grid, but only support AC loads
I know of something better than a minimum SoC. A price forecast for future days. Even if these prices would be speculation and not 100% accurate. The forecast could work further into the future and identify upcoming PV shortfalls (rainy days) and target those times. Nevertheless, it could lead to selling energy at a high price if high PV production is expected in the future. Even if this forecast has a certain margin of error, the advantage would be a significantly longer forecast period.
Good idea, I think both are interesting.
The minium sell soc would also keep some extra in the battery for unexpected usage.
Maybe also a margin could be in implemented that’s added to the target soc planned to keep some extra’s above the predicted usage.
For example when the airconditioning is on in summer or a terras heather in autumn the usage prediction is to low causing grid usage.
I don’t know if the current dess already takes some margin for unexpected usage. Maybe someone from the victron team can tell if this is the case.
What I’m observing is that the problem is diminishing with the 15-minute implementation. The shorter time intervals often create opportunities to cover any shortfalls in the short term with moderate prices. But let’s wait and see.
In the dess settings you can choose to use the 60 or 15min res. You can find it on the pages where you setup your prices
However, the resolution of the graph in the VRM doesn’t change. Therefore, if you don’t compare precisely, you could assume that electricity was being consumed at high prices. You can’t determine when the consumption occurred—whether from 12:00 p.m. to 12:15 p.m. or from 12:15 p.m. to 12:30 p.m. In the new reality, however, these prices can be completely different.
I also think it would be difficult to display consumption in 15-minute graphs, especially on a smartphone. However, one should be aware of the fact that a price is assigned to each consumption.
I have still hourly tarrifs, not 15 minute (zonneplan).
