SunSpec Modbus: one register map for many inverters

SunSpec Modbus is an open register map that many solar inverter brands share, so one polling logic reads an SMA, a Fronius and a SolarEdge alike. Instead of learning a different proprietary address list per manufacturer, you learn one layout: a fixed "SunS" marker, a Common Model that names the device, then one or more device models with the measured values. For an installer running a mixed inverter fleet, SunSpec Modbus is what makes brand-neutral monitoring practical. This guide explains what SunSpec is, how the register map is laid out, the difference between int+SF and float, which brands use which TCP port, and how to turn all of that into one dashboard.

Updated: August 2026.

Key takeaways

• SunSpec is one open register map that SMA, Fronius, SolarEdge, Kostal and others expose over Modbus, discovered by the ASCII marker "SunS".
• Most brands listen on Modbus TCP port 502, but SolarEdge uses 1502, and a gateway defaulting to 502 fails silently there.
• On the int+SF profile every value is an integer scaled by a separate scale factor register; forget the scale factor and your numbers are wrong by a power of ten.

What is SunSpec over Modbus?

SunSpec over Modbus is an open information model, published by the SunSpec Alliance, that standardises how a solar inverter or meter exposes its data in Modbus holding registers. Rather than each manufacturer inventing its own address list, a SunSpec device presents a predictable chain of "models", starting with a marker and a Common Model and followed by device-specific models such as an inverter or a meter. A Modbus client reads that chain with function code 03 (read holding registers) over Modbus TCP or RS485 RTU.

The map does not sit at a random address. A SunSpec device map begins at one of three holding-register base addresses, 0, 40000 (0x9C40) or 50000 (0xC350), and the first two registers hold the ASCII text "SunS" (0x53756E53) as a magic marker, according to the SunSpec Device Information Model Specification. A client confirms it is talking to a SunSpec device by reading the base and checking for that marker before it walks the rest of the chain.

Why SunSpec matters for a mixed inverter fleet

The value of SunSpec is that it collapses many brand-specific integrations into one. An installer who monitors a portfolio of sites rarely has a single inverter brand across all of them. Without a shared model, every brand means a separate register map, a separate parser and a separate maintenance burden. SunSpec turns that into one register logic that works across compliant devices.

That shared model is also why SunSpec appears in grid-code work. SunSpec Modbus is used as a communication profile for IEEE 1547-2018 interconnection certification, and EPRI has documented applying SunSpec Modbus to meet California Rule 21 for distributed energy resources. For the installer, the takeaway is simpler: the same open map that utilities lean on for grid support is the one your monitoring reads for production data. The pillar guide, solar inverter Modbus monitoring, sets the wider context; this article is the protocol layer underneath it.

How the SunSpec register map is laid out

The SunSpec map is a chain of blocks, not a flat list, and it is the same shape on every compliant device. It starts at register 40001 (logical) with the SunS marker, then the Common Model (Model 1), then one or more device models, then an end marker. Model 1 is mandatory and carries the manufacturer, model, serial number and firmware version, per the SunSpec Information Model Specification, so you can identify any device before you read a single measurement.

Each model in the chain begins with a two-register header: a model ID and a length. The device models that matter for solar are the inverter models, 101 (single phase), 102 (split phase) and 103 (three phase), plus the meter models 201, 202 and 203. Because every model announces its own length, a correct client walks the chain, reads each header, and jumps forward by the stated length until it hits the end marker (model ID 0xFFFF). That is why exact addresses shift between devices: the offset of an inverter model depends on which models precede it.

int+SF versus float: two flavours of the same map

SunSpec ships the inverter measurements in two encodings, and picking the wrong one is a common source of nonsense values. The int+SF profile uses models 101, 102 and 103: every value is a 16-bit integer paired with a separate scale factor register. The float profile uses models 111, 112 and 113: every value is an IEEE 754 32-bit float across two registers, with no scale factor.

On int+SF, a scale factor (sunssf) is a signed 16-bit integer that acts as an exponent of ten. The real value is the raw register value times ten to the power of the scale factor, as defined in the SunSpec specification and in the SMA SunSpec Modbus Technical Information. If AC power reads 550 and its scale factor W_SF reads 1, the real value is 550 times ten to the power of one, which is 5,500 W. Miss the multiplication and you report 550 W on a 5.5 kW string.

40083

raw value (AC power)

40084

scale factor (W_SF)

5500 W

real value

int+SF is compact and widely supported, which is why it is the default choice for a mixed fleet. float is easier to process in software because there is no scale factor to apply, but it uses two registers per value and slightly fewer clients support it. Choose one profile and apply it consistently across the fleet.

The SunSpec inverter registers you actually read

The registers below are the typical int+SF inverter model (Model 103, three phase). Treat the addresses as the standard layout after the Common Model, and confirm them with a test poll or the manufacturer register map, because the exact offset depends on the model chain on that specific device. Read them with function code 03.

For a usable monitoring set, four values suffice: AC power for real-time output, total energy for yield, the operating state for fault detection and grid frequency for basic power-quality context. If you also need export and consumption, read the SunSpec meter model (201 to 203) from the connected meter, which follows the same register logic.

Which brands speak SunSpec, and on which port

Most inverter brands expose SunSpec over Modbus TCP on port 502, the IANA standard port, but they do not all agree. The single most common field mistake is pointing a gateway at port 502 for a brand that listens elsewhere. SolarEdge is the classic exception: it serves SunSpec on port 1502, so a client hard-set to 502 gets no connection and no error that explains why.

Coverage also varies by model and firmware. SMA (Sunny Boy, Sunny Tripower) exposes its own profile alongside SunSpec, Fronius GEN24 is pure SunSpec in int+SF or float, and Kostal Plenticore offers SunSpec Modbus TCP. For the brand-specific enable steps, the Fronius Modbus guide, the SMA Modbus guide and the SolarEdge Modbus guide cover each device in detail.

Spotting a not-implemented register

A SunSpec device does not leave unsupported values blank. It returns a defined sentinel, and reading a sentinel as a real number is another way graphs go wrong. Per the SMA SunSpec Modbus Technical Information, a not-implemented int16 returns 0x8000, a uint16 returns 0xFFFF, an acc32 that has not accumulated returns 0x00000000, a float32 returns NaN (0x7FC00000), and a scale factor that is not implemented returns 0x8000.

The practical rule is to test each value against its sentinel first, treat it as missing if it matches, and only then apply the scale factor and store it. This keeps a partly-populated device (common on smaller single-phase units) from polluting the dataset.

From SunSpec to one dashboard

For a single inverter, a Modbus client on a laptop or a Home Assistant Modbus integration is enough, and generic SunSpec integrations are widely used by prosumers. The register logic is the same one described above: find the SunS marker, walk the model chain, apply scale factors, filter sentinels.

For a growing fleet across multiple sites and brands, a fixed gateway per site becomes more practical than a laptop. A ModbusCloud Gateway (see the Gateway page) sits on the local network, opens a Modbus TCP session to each inverter on its correct port, walks the SunSpec chain, applies the scale factors and sends the values encrypted to one dashboard. Because the map is shared, a mixed fleet of SMA, Fronius, SolarEdge and Kostal consolidates into a single overview instead of four manufacturer portals.

The business case is the open standard itself. One register logic reads every SunSpec-compliant inverter, so onboarding a new brand is a port change, not a new integration. Local, real-time production data is also the basis for battery control, dynamic tariffs and export limiting under grid constraints, all of which need data the manufacturer portal will not give you at the interval you want.

Frequently asked questions

SunSpec Modbus is the layer that makes cross-brand solar monitoring realistic. Learn the map once, the SunS marker, the Common Model, the inverter models, the scale factors, the sentinels and the port per brand, and you can read almost any string inverter without a manufacturer account. The ModbusCloud Gateway turns that shared map into one dashboard, so a mixed fleet of SMA, Fronius, SolarEdge and Kostal becomes a single overview instead of four portals.