Proposal: upstream SRNE ASP48120SH3 hybrid ESS driver

English Forum Software-Development
1

Hello OpenEMS maintainers and community,

We are developing an OpenEMS Edge integration for the SRNE ASP48120SH3 hybrid inverter and would appreciate architectural feedback before preparing the upstream pull request.

Hardware and protocol validation

The inverter is connected over Modbus RTU using RS485 at 9600 baud, 8N1, slave address 1, with holding-register reads via FC03. We have validated the register map on a live installation in Nansana, Uganda.

Some results differ from the generic SRNE V1.7 document. In particular, machine-state register 0x0210 = 2 represents a running mains/bypass state on this model, not initialization. Power factor must be derived from active/apparent power, and the usable temperatures are the heat-sink registers 0x0220 to 0x0222.

Current read-only implementation

The work is contained in a new bundle, io.openems.edge.ess.srne, and is decomposed by OpenEMS nature:

  • SrneEss: SymmetricEss and HybridEss telemetry
  • SrneGridMeter: grid-input meter channels
  • SrneBackupMeter: backup-output meter channels
  • SrneBatteryInverter: OffGridBatteryInverter machine-state and grid-mode lifecycle
  • shared SRNE constants and enums

All components use declarative defineModbusProtocol() mappings. Deterministic Modbus tests, Checkstyle, the complete Edge build and Antora documentation build pass locally. The implementation is being reviewed in our fork through these stacked PRs:

Only machine-state code 2 has been validated live so far. Other state labels remain explicitly documented as unverified, and transition/fault states do not claim a stable OpenEMS grid mode.

Proposed upstream split

We propose two independent upstream contributions:

  1. Read-only support first: bundle scaffold, ESS telemetry, grid/backup meters, state mapping, tests and documentation.
  2. Control support later: bounded active/reactive-power commands and other writes, after separate safety review and live hardware validation.

The dangerous 0xDF00 power/reset/restore area is intentionally excluded from the first PR. Although FC06 and FC16 support has been verified at protocol level, we do not want control-safety review to delay useful telemetry support.

Questions for maintainers

  1. Is the single-bundle decomposition above appropriate, or would you prefer the battery-inverter component in a separate bundle?
  2. Is exposing the observed grid/off-grid lifecycle through OffGridBatteryInverter the preferred architecture for this hybrid device?
  3. Do you agree with splitting read-only support and control support into separate upstream PRs?
  4. Are there additional tests or documentation you would want before the read-only PR targets OpenEMS/openems:develop?

Nearly Free Energy intends to maintain this integration and continue validation on the installed inverter. Thank you for any guidance before we consolidate the internal commits into a clean upstream branch.