Venus 3.79
DESS in Green mode enabled 3 days ago
UK based with time of day tariff:
23.30 - 05.30 7p / unit
Rest of time 30p / unit
(Why can’t you select and change the first time when configuring ?)
On the 3rd day SOC was down to 6% and would have been pulling from the grid soon after
I have turned DESS off (again!)
None of this is controlled or affected by the version of the GX OS, it is VRM functionality.
Nick is right that the scheduling is determined in the VRM cloud.
But am I right that your complaint is that you can’t change the From time on the first row and have to fill out a third line? Seems a bit far fetched. Configuring only needs to be done once and it isn’t that hard.
You have set your system to a min Soc of 0%, which really is way too low. Basically you told your system that it is allowed to be flattened out. So at that 6% the system wasn’t preparing to pull from grid yet.
So I’d advice you to raise that to about 10-15%.
Considering ESS also has a hysteresis, it should never be set to 0. That is just not a great idea if the system is expected to behave in a consistent and predictable manner 
I strongly disagree about not setting SOC to 0%
If I changed it to 10% all that would happen is I would pull from the grid sooner. It’s a hard limit
What is required is a separate soft limit for Dess
This woul account for times when solar production or electric consumption does not meet the forecast
This has already been discussed at length on this forum
Not asking for agreement.
ESS has a ± 3% hysteresis, the battery can never reach -3% so a 0% soc is a zone it is not intended to be in, bad practice for fully discharging a battery notwithstanding.
If you configure a system in the way it was intended to operate it is less likely to behave unexpectedly, so until you do then you will continue to be disappointed.
Regardless, not a venus issue, its configuration.
Apart from Nicks remarks being right here:
If I changed it to 10% all that would happen is I would pull from the grid sooner. It’s a hard limit
The algorithm also uses the min SOC to calculate how full it needs to charge the battery in the expensive hours to cover your forecasted usage (+plus some margin). So it will try to fill it up more during the cheap hours.
I’m sorry but this is nonsene for Lifepo4
I’m sorry but I just don’t see the logic behind looking at the minimum SOC - how would the system use anything below that ?
Depending on how large your battery bank is and if you are using the system for power assist etc it is needed to have that little bit there.
The system uses a little for self consumption from the battery at the min soc when it is idle, it makes sense to have a little at the bottom.
Also you aren’t factoring in the fact that there could be cells that are lower than others so 0% may not even be reachable so is not really great for stability. Maybe not leave 10% but 5% for the little extras and unexpecteds depends on your battery.
0% is an off state. Not one you want to hover around.
Also assumes SOC is accurate. It isn’t always.
Don’t recall many manufacturers encouraging 100% DOD, typically 5 to 20% to avoid issues and improve lifespan.
Way too easy to hit a voltage threshold and then have real problems restarting.
If best practice isn’t followed, bad experiences follow.
Fortunately a niche example.
Reminds me when people used to set 100% min soc and that became an issue on the opposite end of the scale.
You seem to lack a full comprehension of the ESS mechanics.
The min soc is to keep the battery in the optimal DOD zone for the manufacturer - this varies from one to another. 0% is uncommon even for lithium.
It is also to guarantee a reserve to cater for grid loss - min soc is ignored when in inverter only mode.
Given the margin for error in soc calcs, choosing one that has zero tolerance for error isn’t a good idea.
It works well until it doesn’t.
Let’s keep this on topic for Dess
Any talk of grid failure is irrelevant especially as there will be no output
I also have a simple peak / off peak schedule like yours, and also use green mode. To bake in a buffer, I have a node-red automation that sets my min SOC to 10% at the beginning of the peak schedule, and then to 30% at the beginning of the off peak schedule.
This allows DESS to plan during the off peak hours, as if it could only use 70% of the pack in peak hours. But when peak hours come and if consumption / production stray from the forecast, the extra 20% is available to consume (to avoid any peak consumption).
Additionally, I have a node-red automation which injects a “fake” calculated forecasted load in the last hour of the peak schedule to force DESS to target 100% SOC every day (via combination of off peak grid charge and on peak forecasted PV production). That is more complicated and requires the latest 3.80 beta, but there are ways to work around the lack of a separate DESS min SOC, and ensure no peak consumption.
I use a simple home assistant animation that turns off DESS if SOC falls below Minimum SOC +5%. Dess is re-enabled at the end each day by the same animation, works well to stop any unwanted grid import but I agree that the best solution would be a separate DESS setting for minimum SOC
One thing worth noting alongside the min SOC advice: DESS plans against price and PV/consumption forecasts, so when either forecast is off the battery can land deeper than the schedule intended — a conservative min SOC is really your buffer against forecast error, not a workaround. For a time-of-day tariff it’s also worth checking the DESS schedule preview in VRM to confirm it actually planned an overnight grid-charge window, since Green mode otherwise relies on solar. And if you use node-red to inject a calculated load forecast like A-P does, keep an eye on double-counting consumption — an inflated forecast can push the schedule the other way and hold the battery too high.
