To summarize, my personal approach is to consider the efficiency with e.g. 77%, but battery costs 0.00 EUR
If Iâm not mistaken, DESS already takes into account some efficiency and conversion loss factor.
But yeah, in order for discharging from battery to grid to be worth it, injection price should be way up.
My simplified strategy would be to charge battery from excess solar, use that power during grid outages and when grid prices are high (according to above formula) and after that, inject any leftover solar surplus to the grid, if injection prices arenât negative.
Yes, I think 80%. But thatâs too optimistic, so I set it to 77 %
I never do this, I disabled discharging battery to grid in the DESS-settings. I only charge it with solar or at cheap buy prices let it charge from grid by DESS. But never discharge to grid.
1 Like
Quick reply on this topic: for my 15.4kWh BYD B-Box Premium LVL, BYD warrants that after (up to) 10 years it will still have 60% of its capacity (warranty v1.1).
In v1.2 it states â10 years or 47.46 MWh of energy throughputâ.
In the end both cases pretty much come down to ~3000 cycles, so thatâs what I use 
If I can squeeze an extra 3000 cycles out of them, the better for me.
But for my cost calculations Iâm using 3000.
1 Like
Just encountered a NEW, wild situation:
- Battery charge was scheduled to reach target soc
- during that time, pv spiked.
- so the scheduled charge rate was lower than the pv surplus, leading to solar beeing feedin
Will think about, if that can be addressed somehow.
2 Likes
Hm, is it expected to have no Target SoC sometimes ?
I notice Iâm running the hack version from 28/09, maybe I should patch to the latest version.
Maybe youâre doing it already, but versioning could start to be useful.
<file>-dognose_v3.2 or something along those line ?
Does any of you how if this hack will have any effect on this bad schedule? Bad as in it should not start charging the battery just because there is PV power⌠when the price is high.
Or maybe the small hack of setting the battery cost to 0.00 might help? Think Iâll try it tomorrow if it actually keeps on charging during the early hours of PV.
From my schedule of tomorrow, it should not charge before 11:00⌠maybe even 12:00
I also often see âââ as target SOC in the remote console, but this was also before installing the hack. It is therefore not caused by dognose
1 Like
Yes, VRM has two base Strategies: TargetSoc and SelfConsume. When it schedules for âSelfConsumeâ, there is no target soc.
No, the hack is not modifiing the schedule. It just tries to catch some unlogical behaviour (within a single schedule-window) by looking at the actual pv power and consumption.
1 Like
looked at this, indeed the system is - on a scheduled charge - only calculating the chargerate out of the capacity and the desired soc-change. (i.e. +5% on a 30 kWh battery would be a chargerate of 1500 required).
This charge rate than is set, any missing power is pulled from grid - and any excess solar will be feed in.
Made a local adjustment, to check if - in the example - current solar overhead is greater than 1500, and if it is, forcing the system into regular ESS-Mode to charge with whatever is available, instead of the calculated 1500.
If the available solar overhead is < 1500, THEN the system will use the precalculated charge rate and charge missing energy from grid.
have applied these changes to my system, and will see if that situation occurs again - and if itâs fixed.
3 Likes
@dognose do you have a PayPal account to which we could donate something for your efforts?
1 Like
Thx for your kindness, but positive feedback is payment enough 
Iâm improving this for my own use - sharing it is just a little click more, almost no additional effort.
7 Likes
Installing it and testing, seems promising.
I only have a concern about a situation that regularly happens during summer time.
Here an example:
Energy feed in price is almost 0 around midday, but higher early in the morning, DESS in green mode rightfully prefers to keep the soc frozen early in the morning, selling the excess PV energy, and then charge the battery from excess pv at midday when selling would be worthless.
This is only useful during summertime, when you know from the forecast that you can reach 100% SOC at a later time. But it is something that this hack will probably break.
Without the forecast data I donât think this can be solved on the Venus OS side.
We have 8 months to think of a solution.
Yes, that is right, that behaviour would be killed by avoiding that âbattery-idleâ situation in the morning. (When the system detects surplus beeing feed in)
In itâs current shape, the gx is only receiving a roadmap from vrm with a certain target soc - without knowing all to mutch about it. So pretty much impossible to look âforwardâ in time and identify this idle as âdesiredâ idle.
If vrm would at least âjustifyâ each slot, the local system could make a better guess on that idling requested. (target_soc_prefer_sell, target_soc_keep_minimum, and therefore also a target_soc_battery_health would allow to distinguish that better)
Another solution that I can think of is for vrm to send 4 SOC targets:
minSOC
softMinSOC
softMaxSOC
maxSOC
Under minSOC a charge will be scheduled to reach the minSOC.
between minSOC and softMinSOC, only charge from excess PV is allowed.
between the softMinSOC and softMaxSOC normal ESS operation.
between softMaxSOC maxSOC, only self consume discharge is allowed.
over maxSOC a discharge will be scheduled to reach the maxSOC.
I think that with these four parameters VRM can handle all possible situations, trade mode and green mode, discharge or charge from grid disabled etc.
The only issue would be that the VRM software will need to be smart enough to correctly calculate these four targets, maybe this is exactly why we are dealing with this problem in the first place, the actual planning algorithm is already impressive as is.
Adding flags is an easier solution, and will keep back compatibility, but in the long run I donât know if they are the best solution.
The schedule is generally smart with regards to forecasts - ultimately itâs inaccurate forecasts causing issues like idling batteries, even if there is plenty of solar - because the forecast had a lower solar or higher consumption, therefore planned for idling.
If the local system would have more details on the schedule, it could better override / adapt the local behaviour with regards to actual local values âper secondâ.
I.e. if idling was just planed to achieve a certain soc level end of day, the system would know that it could easily soak up any excess pv as well. If the soc target has the intension to achieve a higher profit on feedin, it could accordingly decide to follow that idea - or ultimately let the user configure, that in this situation, it should store 25% of excess to the battery and sell 75% for increased earnings or sth.
Im germany, it is relatively easy: Feedin is of such a small value with constant prices throughout the day - so preference to fill up the battery first is just âalwaysâ right.
3 Likes
Dito for Belgium. Injecting excess solar into the grid, even in winter times when injection prices are âhighâ, is rarely worth it. And youâd need to have a large PV install to even have surplus.
During summer, when thereâs excess PV, injection prices are often even negative so totally not worth it.
So yeah, any excess PV not used for self consumption can be stored in the battery for later use.
Injection to the grid when battery is not at >90% SoC, just because the battery is âfull enoughâ, isnât really worth it in my book.
âSome day, when I have timeâ Iâll try to script something myself.
So far @dognose not only seems to have more time than me but also superior programming skills, so Iâm following his examples and trying to bring in data so he can improve his scripts.
Tiny update on this issue. Had the situation today, and observed everything. The generel result was as expected, when there is more solar than the scheduled charge-charge rate requires, the system switched to SCHEDULED_CHARGE_PLUS and charged that extra amount as well, rather than feeding-in:
Without additional modifications:
With additional modifications:
However, switching between Scheduled_charge and Scheduled_charge_plus is not running very smooth in this first attempt, it always causes in between spikes for upto 10kW grid-pull (or falling down to 0 temporary).
So, to resolve this in a nicer way, I have to modify the chargerate directly, so it can smooth transition from 7200 to 7800 rather than switching the system in self-consume mode, when pv+ > 7200 and back when pv+ < 7200.
(I basically wanted to avoid to feed the system with âexact numbersâ, but let ESS handle it - but in this case, itâs not satisfying to do so)
But for this, I have to dig a bit deeper, victron is only adjusting the charge-rate, when the soc changes by at least 1% - so, have to see if that has reasons or can be done more often (as solar changes) or if this will cause undesired side effects.
2 Likes
Small feedback after 4 days of use, the first 3 days there wasnât any situation for the new logic to kick in and everything worked as expected, today there was low solar with random spikes and the new âselfconsume_accept_chargeâ helped harvesting every bit of solar excess.
For the spikes of 10KW grid pull, I see the exact same behaviour when I switch from ESS mode 3 to ESS mode 1 with DESS enabled. When I switch from ESS mode 3 to 1 without DESS this spikes doesnât occur.
They are just 3-5 seconds, so nothings too concerning.
I keep mode 3 when the multiplus is idling to keep idle power at 7 watts instead of 30-40 Im doing it via modbus commands, would be nice if the GX can do it on its own.
Iâve explained the behaviour here.
1 Like
Running Hack version of DESS in Green mode.
Yesterday later in the afternoon battery was at 100%
Solar available approximately 600W, exporting
Final strategy was Scheduled charge.
Turned on Oven 2.5Kw load.
Approximately 2Kw was taken from the grid, not from the battery at peak time. I didnât notice this for around an hour.
Iâm almost sure the Target SOS 100% (should have took a screen shot)
Max Target SOC for idle 100%
I turned DESS off and then on again and it went to
Scheduled Selfconsume
All loads were then supplied from the battery.
As the system was showing Scheduled charge it reacted as it would to a normal Scheduled charge and while charging loads are supplied from the grid.
In DESS setup I have charge restrictions set so that the battery is only charged in the cheap rate overnight period.
The system has been running well for a week. Only charging from Solar and predicting correctly that no overnight charge would be required.
Hope this is useful.