Dess is unnecessarily optimistic in its planning for SOC level. It has no margin for any unplanned consumption or if there is not as much sun as it planned. I have had my system in Dess mode for over 6 months constantly. 30kwh battery.
I assume this is to have a lot of space left to charge if there is a very low electricity price or excess sun.
I usually have “Minimum SOC” at 25%. When there are sometimes several hours left of expensive electricity prices and it has reached the lower limit, I can then manually go in and give it 20% more battery to discharge. But the idea should not be that you should have to go in manually and change it every night.
A separate SOC low target that Dess can go below if necessary could be a solution.
Or a setting for how aggressive Dess should do its calculations could be another.
Or is there some way to get it to charge enough so that it is enough to the next lower price period, that I have not thought of?
As far as I know, this is by design. There have been many discussions, requests, arguments and proposals for possible solutions. My preferred solution is to port the targetSoC @ targetHour option still to be found in Node-RED DESS to VRM DESS but I’m not holding my breath on that one.
I came here to discuss exactly this issue. My SOC is set at 40% for blackout reserve. DESS seems determined to not buy any more energy at low prices than absolutely necessary, which often means reaching minimum SOC just before price is highest, and having to pay full price at that time.
It would be great if DESS could introduce a second setpoint for ‘desired SOC’ during normal operation, based on 100% SOC minus the absolute maximum solar yield for the day. Or even just centered somewhere around the free capacity. For me that would be 40% minimum SOC for blackouts and 70% SOC as target for normal operations.
Search for “b_goal” on this forum to find many posts references requests for a secondary SoC setpoint. You will find there is one still present in the Node-RED DESS implementation that allows to instruct the scheduler to target a variable SoC at a specified hour (in the near future). That feature is flexible enough to work with for many use cases.
Unfortunately any and all requests to port this function to VRM DESS (or better said enable it) have met with nonsensical arguments that it has been deemed unnecessary, or with promises of better functionality sometime in an undisclosed future.
I gave up on it and created a hybrid DESS system where Node-RED DESS runs parallel VRM DESS, for this function only, the resulting schedule is then used to override VRM DESS with when Node-RED DESS indicates it wants to charge/buy. An elaborate hack really just to be able to add a secondary SoC target to the scheduler but so be it. Until such time somebody somehow convinced someone of the need for it.
I have an automation in Homeassistant that does exactly that: altering MinSoC depending on current price but it’s not easy to tune for perfection.
If prices get too high, it releases all reserve (MinSoC 10%). If prices recover, it either insta-charges to 50% or 75% (for low and very low prices) or it just keeps setting MinSoC equal to SoC until it reaches a certain target (35%, aka blackout reserve). This is to make sure it stores excess PV without extra charge from grid in that case.
But in winter there is not too much excess PV, so it barely reaches the target and DESS keeps planning on a tight budget so the strategy needs to be slightly different than in summer and this is where I lost my motivation.
I think most if not all attempts to make dess trade behave post schedule , no matter the higher level trade logic goals, could be buy low / sell high or otherwise, are doomed to fail to run longterm reliably.
My key argument is that there need to be pre schedule future target SoC parameter as input to the scheduler to bias the scheduler itself towards an outcome at the end of the known price window (or earlier if so needed) that is different from Minimum SoC.
The current core assumption that the battery / system Minimum SoC is a suitable ‘end of schedule’ target is based on two other assumptions that are simply wrong: 1) everybody runs solar and 2) solar power capacity is relatively large to battery storage capacity. Remove those two assumptions and it becomes clear that there is no justification to hard code the scheduler to target Minimum SoC at the end of the known price window. The indisputable argument being: nobody knows the price trend after the known price schedule, if price beyond the known schedule trends up, you want to pre-bias towards a higher SoC to sell from, if price trends down you want to pre-bias to a lower SoC to have room to buy.
The uncertainty make it necessary to set a ‘compromise’ target SoC at the end of the known price schedule, that allows both to buy low as well as to sell high after the new price schedule comes in. The only valid exception being the use case with a large installed solar capacity (delivering ‘free’ energy) relative to the battery capacity, which is unironically feeding the ‘but it works well’ fallacy.
It is utmost disappointing that the developers are unwilling to engage with this argument at all based on their perceived knowledge that dess runs great on almost all professional systems . This is a well known mental bias in engineering called not invented here syndrome that is understandable at first (because historically those systems fit their assumption) but not after year(s) long discussions pointing out that a) new use cases require re-evaluation of core assumptions and b) Node-RED DESS already has the required feature: b_goal_SoC and b_goal_hour that strongly suggests this doesn’t need be developed from scratch, just ported from Node-RED DESS to VRM DESS, access by VRM API will do. (Not to mention I tested a hybrid hack that does precisely that with good results).
