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. 19 verticals 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: 2,086 curated mappings across 13 protocol adapters, resolving to 985 canonical fields defined 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.