SunSpec SunSpec Model 14 — Proxy Server Modbus TCP template

SunSpec Model 14 — Proxy Server

SunSpec Model 14 is a network-configuration model defined by the SunSpec Alliance that stores proxy server connection parameters on a compliant Modbus TCP device. The template reads the model identifier and length registers, and reads or writes the proxy name, capability flags, configuration word, connection type, target address, port, username, and password. It does not measure energy or power; its purpose is to let integrators inspect and configure the outbound proxy endpoint through which a DER device communicates with a monitoring back-end. Importing the SunSpec Model 14 Proxy Server template into ModbusCloud lets you track and audit these settings in one place.

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

Registers (10)

10 read, 8 write

NameUnitAccessAddress (Hidden until you enter your email)Function (hidden)Type (hidden)
idRead
lRead
namRead and write
capRead and write
cfgRead and write
typRead and write
addrRead and write
portRead and write
userRead and write
pwRead 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.

Number of installations (optional)

Use cases

  • Verify that the proxy server address and port stored on a DER device match your network configuration after firmware updates.
  • Alert on unexpected changes to the proxy capability flags that could indicate unauthorized configuration modifications.
  • Compare proxy configuration words across multiple sites to confirm a consistent deployment baseline.
  • Track the proxy name register over time to detect accidental overwrites during maintenance windows.
  • Report the configured proxy port to your network team to confirm firewall rules are aligned with device settings.

Installation

  1. Enable Modbus TCP access on the target DER device under its communication or network settings menu, and note the device IP address and unit ID.

  2. Connect the ModbusCloud Gateway to the same LAN segment as the DER device, ensuring TCP port 502 is reachable between the Gateway and the device.

  3. In the ModbusCloud portal, add a new device, import the SunSpec Model 14 Proxy Server template, and assign the correct unit ID and base address offset matching your device's SunSpec map start.

  4. Trigger a manual poll and spot-check the id register (address 0): a returned value of 14 confirms the correct model block is being read.

Things to watch for

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

The SunSpec model map on your device may start at address 40000 or 50000 rather than 0. Adjust the base address offset in the ModbusCloud portal to match the actual SunSpec map start for your device. Scan the holding register space at offsets 0, 40000, and 50000 to locate the correct starting point.

Reads succeed but the addr string register shows garbage characters.

SunSpec string registers are packed as ASCII in consecutive 16-bit registers, big-endian byte order. If your gateway or polling tool applies a different byte swap, the string will appear garbled. Confirm your Modbus TCP client reads string registers without byte-swapping individual register pairs, as SunSpec mandates big-endian ordering.

The gateway connects but no values appear for any register.

Check that the unit ID assigned in the portal matches the device's configured Modbus unit ID. SunSpec devices often respond only on a specific unit ID. Also verify the TCP idle timeout: some devices close inactive connections after 60 to 120 seconds, causing silent poll failures. Reduce the polling interval or keep-alive settings in the portal.

Is it safe to write to nam, addr, port, user, or pw registers remotely?

Use caution. Writing proxy credentials or the target address remotely can redirect the device's outbound communication to an unintended endpoint, breaking monitoring or voiding support agreements. Always back up current register values before any write operation, test on one device first, and coordinate with the site owner before modifying authentication registers.

Want to see how it works?

Electrician working in an open distribution board