Inverter data over Modbus: how to integrate it into the platform

Almost every PV inverter speaks Modbus. It is a protocol dating from the 1970s, simple and open, and that is why it is still the most reliable way to get data out of a device without depending on the manufacturer’s cloud. A gateway reads the inverter over Modbus, builds the message and sends it to the platform over the cellular network.

This article explains the whole path: what Modbus is, what the inverter exposes, how the gateway reads it and what to do with the data when communication fails. It is for anyone about to buy or specify the integration.

Modbus RTU and Modbus TCP

There are two ways to carry the same protocol:

• Modbus RTU runs over a twisted pair on RS-485. Several devices share the same bus, each with an address from 1 to 247, at a typical speed of 9,600 or 19,200 bps. It is common on string inverters and string combiner boxes. It needs shielded cable, termination resistors at both ends and attention to polarity.
• Modbus TCP runs over Ethernet, on port 502. Each device has an IP address. It is common on central inverters, energy meters and sites that already have a network.

The gateway we build has both interfaces. It is the master (client): it asks, the inverter answers. The inverter never sends anything on its own.

What gets read: registers

Modbus sees the device as a table of 16-bit registers. The ones that matter are the holding registers and the input registers, read with function codes 03 and 04. Values wider than 16 bits, such as cumulative energy, take two registers; values with decimals come as integers with a separate scale factor.

What practically every inverter exposes:

• Instantaneous AC power (W) and DC power per input
• AC voltage and current per phase, and grid frequency
• DC voltage and current per MPP tracker or string
• Total cumulative energy (Wh, 32 bits) and today’s energy
• Internal and heat-sink temperature
• Operating state (off, waiting, generating, fault) and an event vector with the alarm codes

Each manufacturer has its own map, published in the communication manual. The address, size and scale of each field come from there, and it is the first document we ask the client for.

SunSpec: the standard map

The SunSpec Alliance defined a common map adopted by many manufacturers. The device presents the word “SunS” at the base address (40001 in traditional notation), followed by numbered blocks: model 1 carries the manufacturer, model and serial number; models 101, 102 and 103 carry single-phase, split-phase and three-phase inverter data, with power, voltages, currents, frequency, energy, temperature, state and events, each quantity with its own scale factor.

When the inverter is SunSpec, integration is almost immediate: the gateway discovers the blocks and knows where each value is. When it isn’t, the proprietary map is configured, which takes a little longer but works just the same.

Polling interval

Reading every second floods the bus and the platform with no benefit. What usually works:

• Power, voltages and currents: read every 10 to 60 seconds, with a 1- to 5-minute average sent to the platform. The second-by-second detail stays on the gateway.
• Cumulative energy: with every upload; it is the value that closes the day and the month.
• State and events: on every read, sent immediately when they change. An alarm doesn’t wait for the average.
• String comparison and performance ratio: computed on the platform from the averages and the irradiance.

On plants with many inverters on one RS-485 bus, the scan time grows with the number of devices; that is why the devices are split across several buses or moved to TCP.

From gateway to platform

The gateway gathers the readings, stamps each one with the date and time from its own clock (synchronized over the network) and sends them to the platform over the 4G cellular network. Uploads use the platform’s API or our own protocol, DF-1 over UDP, which is lightweight and tolerant of poor connections. Where there is no cellular coverage, the same logic works over the DG satellite network, which also delivers in minutes; what changes is the message size, so the alarms and the summary go up, not every inverter register.

The platform links each inverter to its plant, string and customer, stores the series, computes the indicators and fires the alerts.

When the internet goes down

It will. A SIM with no signal, a badly placed antenna, a tower under maintenance. What separates a good integration from a bad one is what the gateway does at that moment:

1. It keeps reading the inverter at the same interval. The failure is on the way out, not on the way in.
2. It writes each reading to non-volatile memory with its original timestamp. Capacity is sized for days, not hours.
3. It resends in order when the network comes back, oldest first, without inventing a new timestamp. The platform recognizes the original time and fills the gap in the chart.
4. It flags the period as backfilled, so nobody mistakes a late reading for a fresh one.

Without a buffer, every network outage becomes a hole in the day’s energy, and the day’s energy is the number that pays for the plant.

What to do now

1. Gather the communication manual for every inverter and meter on the plant, with its Modbus map.
2. Check the available interface (RS-485 or Ethernet) and the distance to where the gateway will go.
3. Decide which alarms need to be sent immediately and what averaging interval to use for everything else.

If you’d like to discuss a project, talk to one of our engineers.

---

Sources: Modbus Application Protocol Specification V1.1b3 and Modbus over Serial Line Specification (Modbus Organization); SunSpec Inverter Models (SunSpec Alliance, document 12020); IEC 61724-1, Photovoltaic system performance, Part 1: Monitoring.