Thank you for the technical insights.
Although I agree with most of your assertions, there is one that I believe is a real logical fallacy:
This defies all logic, reducing precision simply cannot increase accuracy, no matter how you look at it.
The use case where we are experiencing the negative effects of a lack of precision of the ‘target SoC for current time slot’ concerns a dedicated DESS Trade system consisting of a 88kWh battery, a MultiPlus II 5000, an additional 8000W HF Boost Charger all on a single phase 40A mains connection.
This system is setup to charge at AC 40A flat by means of the MPII’s capability to adhere to the ‘grid current limit’ setting and the Boost Charger located on the MPII’s AC-out.
As simple Node-RED flow detects when the MPII is set to charge at full rate and simply switches on the Boost Charger bank (~95% efficiency), at which point the MPII downregulates itself to only charge a few percent extra upto that 40A limit. The only significant variable influencing the actual DC charge power is the mains AC voltage, which stays within a range of 224 to 234 Vac for prolonged periods of time, a power variation of ~5% at most.
Discharging is done at full capacity of the MPII where special precausions have been taken to keep the toroid transformer cool enough to sustain full power for hours on row, only on very hot days and after 4 or more hours do we ever experience thermal throttling but generally speaking it simply outputs a flat 4400 Watt AC (of which it somehow attributes ~50 Watts to AC-out even without any load attached and only ~4350 Watts to feed-in to the grid but alas, the power curve is as flat as can be.
There are no other significant loads, only a Cerbo, the MP itself and an internet modem all in all maybe 100W at most, all on the DC side.
We have been measuring, calibrating and tuning this system for a year now, please accept at face value that all the common settings are very well known and tuned. We tried all kinds of tweaks such as nudging a little higher charge or discharge rate but in the end getting the settings as close as possible to actual measurred values provides the best overall result.
But still we cannot rely on the DESS execution process not to overshoot or undershoot the target SoC on an hourly, and now 15 minute basis.
I argue with certainty that the root cause for this is the lack of precision of the ‘target SoC for current time slot’. The most compelling argument I can make towards that end is that a 1% delta SoC corresponds with 0.88kWh of energy, which is awfully close to the 1.1kWh of energy the MPII feeds in the the grid per 15 minutes (even closer when taking conversion losses into account). For practical purposes it is a 1:1 relation. This means that even the smallest variation in the actual power flow (that 5% in AC voltage for instance) will always lead to undershoot overshoot situations. An analogy that comes to mind is that of digital audio: to represent a 22kHz analog audio signal in the digital domain, the bitstream rate needs to be 44 kilo bits per second (kbps) at least. The overshoot and undershoot behaviour is directly comparable to aliasing artifacts when attempting to capture 22kHz audio with a 22kbps digital stream (and comparable to aliasing artifacts in digital photography just same). There is no post-processing solution possible to compensate for missing precision of the key control variable. The information required to do so, no matter how smart and/or complicated the method, is just not available within the bounds of the official DESS execution process implementation.
PS, our workaround is based on a virtual higher precision ‘target SoC for current time slot’ in Node-RED that synchronizes the actual ‘target SoC for current time slot’ to corrected nearest integer values, based on additional information taken from all other information sources such as the full scheduling object arrays. Unfortunately we now first need to rebuild this workaround to take the 15 minute pricing schedule into account to make it work as required again. And it is by no means a solution, just another hack.