SunSpec SunSpec Model 12 — IPv4 Modbus TCP template

SunSpec Model 12 — IPv4

SunSpec Model 12 is the standard IPv4 network configuration model defined by the SunSpec Alliance, implemented across SunSpec-compliant DER devices such as inverters, energy meters, and battery storage controllers. The template reads network identity and status registers, including configuration status, change-pending flag, and capability flags, and exposes read/write registers for IP address, subnet mask, gateway, DNS servers, NTP servers, domain name, and hostname. Communication uses Modbus TCP over the device's existing Ethernet port. Using this template in the ModbusCloud portal lets you audit and document the active network settings of any SunSpec Model 12 device without opening its local web interface.

Protocol
Modbus TCP
Connection
Ethernet, Modbus TCP
Registers
17, read and write
Brand
SunSpec
Last updated

Registers (17)

17 read, 12 write

NameUnitAccessAddress (Hidden until you enter your email)Function (hidden)Type (hidden)
idRead
lRead
namRead and write
cfgstRead
chgstRead
capRead
cfgRead and write
ctlRead and write
addrRead and write
mskRead and write
gwRead and write
dns1Read and write
dns2Read and write
ntp1Read and write
ntp2Read and write
domnamRead and write
hostnamRead and write

Loading registers…

Send your device list

If a device is not in the library yet, we build the template for free as soon as we have the register data.

Use cases

  • Verify the static IP address, subnet mask, and gateway of a newly commissioned SunSpec device before handing over the site.
  • Monitor the configuration status register to detect unexpected DHCP-to-static transitions after a device firmware update.
  • Audit NTP server assignments across multiple inverter sites to confirm time synchronization sources are consistent.
  • Track the change-pending flag to confirm that a network reconfiguration was accepted and applied by the device.
  • Report the hostname and domain name of each device per site to maintain an accurate network inventory for the facility manager.

Installation

  1. Confirm that Modbus TCP is enabled on the target device via its local web interface or display panel, typically under the communication or network settings section.

  2. Connect the ModbusCloud Gateway to the same Ethernet network as the target device, ensuring the Gateway can reach the device's IP address on TCP port 502.

  3. In the ModbusCloud portal, add a new device, import the SunSpec Model 12 template, and set the Modbus unit ID to match the device configuration, commonly 1 or 126 depending on the manufacturer.

  4. Poll the id register and confirm it returns the value 12, then spot-check the addr register to verify the IP address matches the device's known network address.

Things to watch for

The id register returns a value other than 12. Why?

The Model 12 block may not start at address 0 in the device's register map. SunSpec devices can place model blocks at base addresses 0, 40000, or 50000. Check the manufacturer's Modbus documentation for the correct base address offset and adjust the template's base address in the portal accordingly.

String registers like addr or hostnam return garbled data. What is wrong?

SunSpec string registers are stored in big-endian byte order, with two ASCII characters packed per 16-bit register. If your gateway or polling tool reads them as raw integers, the output will appear garbled. Ensure the ModbusCloud Gateway is set to interpret string registers using SunSpec big-endian encoding.

The gateway connects but cfg, ctl, and addr show no change after writing. What now?

Some devices require you to write a specific commit value to the ctl register after updating cfg or addr to apply the new network settings. Check the device's Modbus manual for the required control sequence. Also verify the device is not in a read-only protection mode that blocks Modbus writes.

Is it safe to write to cfg, ctl, addr, and other RW registers remotely?

Exercise caution. Writing incorrect values to the addr, msk, or gw registers can immediately change the device's network configuration, causing it to become unreachable. Writing to ctl to commit changes is irreversible until corrected manually. Always confirm new values are correct before applying, and have local access available as a fallback.

Want to see how it works?

Electrician working in an open distribution board