I’ve been noticing sometimes DESS is not doing the right thing. e.g. when the price is highest, it does not discharge with maximum capacity.
I’m currently monitoring 6 systems and I’m seeing this behavior on 4 of them. All are Multi RS solar 3-phase systems, their firmware is mixed: 2 are on beta 3.80~39 and 2 on 3.75 official. All are on trade mode with 0.02 cents battery cost.
First I thought I was missing something or misunderstanding the algorithm, but just now, there’s been a very clear example of it.
The price hit the all-day high during 19:45-20:00 (tomorrow is all lower as well), but the batteries did not discharge with maximum performance. In some cases, only with ±50% of the maximum capacity.
system 1: 15 kW discharge capacity, only did 8 kW.
I’ve send you a PN, if you could give me the 3 system IDs I could have a look at them.
3 Systems of quite equal types showing the same issue either is the same configuration-issue for all - or a general issue with dess for this certain usecases. (Either case would be helpfull to figure out the cause)
So, I have checked all systems, and they indeed have a common configuration issue. Not something you did wrong, just something you probably are not aware of / didn’t think about the relevance for dynamic ess:
The systems are configured to VRM Log-Intervals of 5, 10 and 15 minutes, with the behaviour being worse the longer the interval is.
The scheduler does a recalculation every 15 minutes - and if the most recent available soc-value is “5 minutes old”, the system has already discharged 33% more within that window than the scheduler now is using as basis to recalculate the plan.
This causes the scheduler to assume the system is falling behind plan and calculating a new target for the next window, that is about 30% higher than initially planned. But the system in fact DID achieve the initial target, it just didn’t report it by the time the scheduler runs a calculation. So, the next target will be bellow what the system could achieve, basically just a “70% utilization” window.
(And for the 10/15 minute systems, this is even worse)
For now (there are plans to improve/decouple that from regular reporting), when using DESS, you should set the systems to a 1 minute reporting interval to make sure the scheduler has most recent data, when doing its 15min-rescheduling.
Here’s an example graph of that: Initially the chargerate is as expected, but then - due to outdated soc-values available - the scheduler starts correcting targets up (blue dotted line) and the system therefore applies a way lower discharge rate. And then it’s continuously becoming better, as the lower chargerate causes “less” deviation (“better target again”) - and then worse again and so on.
Dang, I’d have never suspected that setting to impact anything other than… the reporting
Thanks a lot. That is incredibly valuable information!
Is this anywhere in the documentation by any chance? I thought I was pretty thorough in my research for setting up the systems.
