Hi everyone,
In our large-scale energy storage projects (20 MWh+) we had an SoC related problem: the precision of the SOC channel in Battery/SymmetricEss is too low, as 1% increase/decrease relates to 200kWh. The channel is currently an Integer (0-100), so the keep all near equals power solver starts to oscillate slightly (not critical for 20MWh, but will become more critical with increasing capacities), and external interfaces used for trading don’t work correctly because of the large jumps between the reported integer percentage values.
We have already applied a fix: we introduced a seperate SOC_DECIMAL channel as a decimal type using float, so the general approach is already tested and works well in practice. After further analysis, however, we concluded that double is the better choice, for higher precision and better compatibility with Java streams and the keep all near equals power solver, who both use double.
For this reason we would like to change the channel to a double value in the long run. We are aware that this is a breaking change and cannot be implemented easily in the short term. However, since we depend on this change, we would like to introduce a deprecation period to manage the transition. As a first step, we would add a new channel:
SOC_DECIMAL(Doc.of(OpenemsType.DOUBLE) //
.unit(Unit.PERCENT) //
.persistencePriority(PersistencePriority.HIGH)); //
which would initially live in a new interface:
public interface SocDecimalBattery extends OpenemsComponent
Once all Battery/SymmetricEss implementations and controllers have been migrated to the double-based functionality, the SOC_DECIMAL channel would be refactored into the SOC channel and the now-redundant channel would be removed.
For the migration in InfluxDB we can utilize the io.openems.backend.timedata.influx/src/io/openems/backend/timedata/influx/FieldTypeConflictHandler.java to drive the migration and ensure the same data type is written per shard into InfluxDB.
Of course, there are also a few points where we see room for discussion:
-
Should the channel be a double or a float? We lean towards double, but are open
to arguments for float. -
How long should the deprecation period be?
- We felt 6 months would be appropriate, but we are open to suggestions, as we are aware of how significant this transition is.
As mentioned, we know this is a breaking change, so we are of course open to discussion. What do you think of the change in general? Are there alternative proposals, or are the resulting problems too severe?