SunSpec is an information model layered on top of Modbus, not a replacement for it. A SunSpec-compliant device still speaks ordinary Modbus TCP or RTU; what SunSpec adds is agreement about which registers hold what.
A device exposes a chain of numbered models starting at a well-known base address, each with a fixed layout. Model 1 is common identity — manufacturer, model, serial, version. Model 101/102/103 are single-phase, split-phase and three-phase inverters. Models 201 to 204 are meters. Model 124 is storage and 802 is a battery. You read the chain, learn what the device is, and know the register layout without a vendor PDF. For a fleet of mixed inverters that is a genuine improvement.
The sharp edge is the scale factor. SunSpec stores values as integers and puts the decimal exponent in a separate register — so W might read 4120 with W_SF reading -1, meaning 412.0 W. Code that reads the value and ignores the factor is wrong by a power of ten, and critically the wrong number still looks like a plausible reading, so nothing alerts and nobody notices until a monthly total is compared against an invoice.
This is worth knowing even if you never write a SunSpec client: it is the clearest example in industrial data of a correctness problem that produces no error. Forge applies the scale factors in the kernel and validates the result against physics bounds — grid_frequency_hz is bounded 45 to 65 Hz precisely because anything outside that band is a scaling mistake rather than a grid event.
No. SunSpec devices speak ordinary Modbus TCP or RTU. SunSpec specifies which registers mean what, so it is an information model rather than a transport.
You get a value wrong by a power of ten that still looks plausible. This is the single most common SunSpec integration bug and it does not raise an error anywhere.
Model 1 for identity, 101/103 for inverters, 201-204 for meters, and 124/802 for storage and batteries. Reading the model chain from the base address tells you which are present.