Modbus

Modbus is a request-response protocol published by the Modbus Organization. A client (called the master on serial lines) sends a request with a function code and an address, and the server (the slave) answers. A server never sends data on its own, so every value the software sees is the answer to a question it asked.

The data model has four tables: discrete inputs (single bits, read only), coils (single bits, read and write), input registers (16-bit words, read only) and holding registers (16-bit words, read and write). Each table is addressed from 0 to 65535, and multi-byte values travel big-endian. One request carries at most 253 bytes of protocol data, which limits a single Read Holding Registers call (function 03) to 125 registers and a Write Multiple Registers call (function 16) to 123.

Modbus RTU runs on a serial line, most often two-wire RS-485. Only one master talks on the bus at a time, slaves have addresses from 1 to 247, and address 0 is a broadcast that nobody answers. Frames are separated by a silence of at least 3.5 character times and end with a CRC. The default setting is RTU mode with even parity, and 19,200 bit/s is the required default speed. The serial specification guarantees 32 devices on one RS-485 segment without a repeater; more is possible only when the devices are documented for it.

Modbus TCP wraps the same request in a 7-byte MBAP header and sends it over TCP to port 502, giving a frame of at most 260 bytes. It has no CRC of its own and relies on TCP and Ethernet checks. A one-byte unit identifier routes the request through a gateway to a serial device behind it.

Modbus defines how to move registers, not what they mean. Which address holds active power, its scale factor, units, sign and the word order of a 32-bit value are all in the manufacturer's register map. SunSpec Alliance publishes standard information models carried over Modbus, for example model 1 (common block, mandatory first), 701 (DER AC measurement), 802 (battery) and 203 (three-phase meter). Its reference client looks for the marker "SunS" at base addresses 40000, 0 and 50000.

A system that reads or controls hardware over Modbus needs the following:

• Register maps are versioned configuration per device model and firmware. A new model or firmware means a new map and a test; the application stays unchanged.
• The polling plan respects the bus. On one RS-485 line requests go one at a time, so the number of devices, requests per device and response time set the shortest possible control cycle. Contiguous registers are read in one request, up to 125.
• Values are decoded per map: scale factors, signed and unsigned types, word order of 32-bit values, and rounding to the resolution the device declares.
• Writes use the unit ID (slave ID) just as reads do. Gateways that serve several devices make this mistake expensive.
• Writes are confirmed. The software reads back the register after writing and alerts when the value differs; a fire-and-forget write path leaves the system guessing what the device does.
• A failed read is marked as failed. Publishing the last good value as fresh hides an outage from the control logic.
• Access is restricted on the network. The base protocol has no user or password field, so any client that reaches port 502 can write a holding register. Keep Modbus on a local network or behind a gateway; the Modbus Organization also publishes a separate Modbus Security Protocol specification.

For Zeronest each installation gets a Bzyk D200 device wired directly into the inverter over RS-485/Modbus and reporting over LTE, independent of the manufacturer's cloud and the home Wi-Fi. The platform integrates 16 inverter brands this way. Configuration registers are checked by a daily read-write-read cycle per inverter model: the system reads the values, compares them with the target, writes them, reads them again and raises an alert when the read-back differs. Failed writes can be filtered in the admin panel.

The EMS we built for Skyfri includes Modbus communication modules next to battery and PV control, and the work started with communication workshops with the battery supplier in February 2024.

For Global Green's battery storage sites we designed and built the Modbus module of the EMS in 2026 and mapped the registers of battery systems from two manufacturers. Testing in July 2026 found three defects that are typical for Modbus code: failed batch reads published stale values as fresh, writes ignored the configured device ID, and the write path was fire-and-forget. All three are fixed, and rounding of read values to each channel's declared resolution is in progress.