The solar and storage question. SunSpec is not an alternative to Modbus — it runs on top of it — but the choice of whether to implement it is real.
| SunSpec | Modbus TCP | |
|---|---|---|
| Specification | SunSpec Alliance information models, carried on Modbus | Modicon Modbus, TCP encapsulation (Modbus-TCP) |
| First published | 2009 | 1979 (serial), 1999 (TCP) |
| Transport | Modbus TCP or Modbus RTU | TCP, port 502 |
| Data model | Standard register blocks by model number — 101/103 inverter, 201-204 meter, 124 storage, 802 battery — with an explicit scale-factor register per quantity. | Flat 16-bit registers and single-bit coils. No types, no names, no metadata — a register is a number at an address. |
| Discovery | Yes, within Modbus: read the model chain from the well-known base address. | None. You need the vendor's register map, usually a PDF. |
| Security | Inherits Modbus, which is to say none. | None in the base specification. Whatever the network gives you. |
| Polling or subscription | Polling, inherited from Modbus. | Polling only. The client asks; the device answers. |
| Implementation complexity | Low on top of Modbus, with one sharp edge: scale factors. | Lowest of any protocol here. A working client is ~200 lines. |
| Typical industries | Solar inverters, revenue meters, battery storage. | Everything. Drives, meters, inverters, sensors, PLCs, BESS. |
| Forge support | Supported. Scale-factor handling and SunSpec model packs ship in the kernel. | Adapter shipped. 14 OEM families mapped. |
Strength. The only widely adopted attempt to put a standard information model on top of Modbus.
What it costs you. The scale factor is a separate register. Read the value and forget the factor and you are wrong by a power of ten, silently.
SunSpec adapter →Strength. Universal, trivial to implement, works on hardware from 1985.
What it costs you. Carries no semantics whatsoever. Scaling, byte order and register meaning all live outside the protocol.
Modbus TCP adapter →Plain Modbus on an inverter means a vendor PDF and a register map per model. SunSpec means a standard model chain you can discover. The catch is the scale factor: SunSpec stores the exponent in its own register, and code that reads the value without applying it is wrong by a power of ten in a way that looks like a plausible reading.
Forge is not an argument for a protocol. It is the layer that makes the choice stop mattering downstream: 16,908 curated mappings across 14 protocol adapters, resolving to 366 canonical fields with enforced units and physics bounds.
Two devices, two protocols, two vendors, two entirely different tag names — and one canonical field out. Both of these are real mappings from the corpus, not illustrations.
Same field: active_power_kw. Same unit contract, same physics
bounds, same shape. Your query does not need to know which protocol the reading
arrived on.