Add support for SolarEdge ESS PV hybrid inverters

[timo-schlegel]

Adds compatibility for SolarEdge ESS PV hybrid inverters (single-phase and three-phase models).
E.g. SolarEdge SE4000 with SESTI interface or SolarEdge SE10K-RWS.

[codecov]

Codecov Report

❌ Patch coverage is 55.68182% with 351 lines in your changes missing coverage. Please review.

❌ Your patch check has failed because the patch coverage (55.69%) is below the target coverage (75.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@              Coverage Diff              @@
##             develop    #3571      +/-   ##
=============================================
- Coverage      59.41%   58.54%   -0.86%     
+ Complexity       105      104       -1     
=============================================
  Files           3069     3112      +43     
  Lines         133076   134982    +1906     
  Branches        9815     9932     +117     
=============================================
- Hits           79049    79017      -32     
- Misses         51045    53022    +1977     
+ Partials        2982     2943      -39     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[timo-schlegel]

@sfeilmeier, as requested at https://community.openems.io/t/asking-for-feedback-new-modbusworker-implementation/1747/6?u=mrt, please find my SolarEdge ESS implementation here.

The Checkstyle test fails due to incorrect naming in SolarEdgeSunSpecModel, which uses the same naming as DefaultSunSpecModel. The purpose of SolarEdgeSunSpecModel is to provide the DefaultSunSpecModel without events, as these cause warnings when using the SunSpec model with SolarEdge (either with my implementation or with the included SolarEdge PV inverter implementation). Would it make sense to remove the events from the DefaultSunSpecModel instead of defining a modified model?

[sfeilmeier]

The Checkstyle test fails due to incorrect naming in SolarEdgeSunSpecModel, which uses the same naming as DefaultSunSpecModel. The purpose of SolarEdgeSunSpecModel is to provide the DefaultSunSpecModel without events, as these cause warnings when using the SunSpec model with SolarEdge (either with my implementation or with the included SolarEdge PV inverter implementation). Would it make sense to remove the events from the DefaultSunSpecModel instead of defining a modified model?

Thank you!

1. We already have a bundle for SolarEdge - please move your code there: https://github.com/OpenEMS/openems/tree/develop/io.openems.edge.solaredge

2. Yes, I see this also with SolarEdge PV inverters, that all Events are active. Can you find out if the Events are just inverted (i.e. set to 0 if Event is active) or are they just not supported by SolarEdge? I would definitely not just copy the file, but instead add a parameter that disables or inverts the Events.

[sfeilmeier]

See above

[timo-schlegel]

@sfeilmeier
According to the SolarEdge SunSpec Technical Note:
https://knowledge-center.solaredge.com/sites/kc/files/sunspec-implementation-technical-note.pdf

Events are only supported for the meter models (e.g. SunSpec models 201–204).

For the Multiple MPPT Inverter Extension Model (160), events are explicitly marked as not supported.
For the standard inverter models (which we use for SolarEdge inverters — models 101, 102, 103), events are not listed at all in the Modbus register mapping.

Based on this documentation, I assume that events are simply not supported for the inverter models (101–103), rather than being inverted.

I agree that copying the file is not the best approach. Adding a parameter to disable event handling makes sense. However, I am currently not sure at which level this parameter should be introduced.

[timo-schlegel]

@sfeilmeier
I updated the implementation and pushed a new commit.

The code was moved to the existing SolarEdge bundle as suggested. Instead of copying or modifying DefaultSunSpecModel, I introduced a small wrapper (FilteredSunSpecModel) that allows excluding specific SunSpecPoints from an existing model. This way the generic DefaultSunSpecModel can still be reused unchanged, while the SolarEdge implementation can disable the unsupported event registers.

In the same change, I also fixed the existing SolarEdgePvInverter implementation to use the filtered model so that the unsupported event registers no longer cause warnings.

Could you please have another look and let me know if this approach fits better with the intended design?

Thank you!