I created PR #3444, which introduces new PV single-string chargers from 4 to 8. This allows all single PV strings from the 4 MPPTs to be handled separately.
Because the power registers from 5 onwards are missing, I changed the implementation to calculate the power from current and voltage instead.
In my setup, PV2 and PV4 also reported incorrect values with the previous implementation on my GoodWe ETK 30.
I’m not a big fan of this large number of classes, but I chose this approach to stay compatible with existing production environments.
in the scope of OpenEMS, this could be resolved in this way, as there will be no customer complaints.
I tried to explain it in your previous PR.
We actually had exactly the same approach. However, technical tests revealed that the current values per PV input could not be used reliably.
This meant that extremely different current values occurred at the inverter for identical PV strings.
e.g. PV5: 4A, PV6: 0.2A.
I have also two identical string connected to one MPPT. But in my opinion it’s ok if they have different currents, because in my installation one is an east string and the other one is the west string. And in my tests both together calculated reflects the same value as the current in the mppt register. What is your PR?
our PR was only in the internal Repo. @stefan.feilmeier
Internally we could still use the existing MPPT components but having these components integrated in OpenEMS, so a OpenEMS user could decide by its own.
I would like to propose a hybrid approach instead of globally replacing the PV power reading with a calculated value (U * I) for all GoodWe chargers.
With the current change, all users of the upstream GoodWe implementation are affected, including those where a reliable PV power register is already available (e.g. PV1–PV3). As a GoodWe user myself, this is problematic, because readable and previously working values are no longer used, although they can still be obtained directly from the inverter.
In my opinion, replacing readable register values with calculated ones is not ideal, especially since current values per PV input are known to be unstable or inconsistent in some installations. This means the change may reduce data quality for existing setups, even if it solves limitations for PV inputs >3.
A better approach could be:
Use the native PV power register whenever it is available and reliable (e.g. PV1–PV3).
Only fall back to calculated power (voltage * current) for PV inputs where no power register exists (e.g. PV4–PV8).
This avoids regressions for existing installations while still enabling support for additional PV inputs.
This hybrid strategy would preserve backward compatibility, minimize unexpected behavior changes for existing users, and still solve the technical limitation that triggered this change in the first place.