pymodbus is the go-to open-source Python library for Modbus (BSD-3-Clause) — it even shows up in roundups of free Modbus Poll alternatives as the “build your own” option (see the ranaliz.com 2026 list). So: script it in Python, or point-and-click in QModMaster? The honest answer is not either/or. Probe with your eyes first, automate with code second.

When each one wins

• QModMaster wins at first contact with an unknown device: trying slave IDs, flipping between function codes, watching values update live, and opening the Bus Monitor when the bytes look wrong. Ten minutes in the GUI beats an hour of print-debugging.
• pymodbus wins the moment the setup works and needs to keep working: scheduled polling, logging to CSV or a database, threshold alerts, and CI tests that verify a device still answers after a firmware update.

The workflow: probe in QModMaster, freeze in pymodbus

• 1. Probe interactively in QModMaster. Find the slave ID, the right function code and start address, and confirm the values look sane. If floats come back as astronomical numbers, fix the byte order first — see our float byte-order guide.
• 2. Copy those exact parameters into a pymodbus script. Same host, same port, same slave ID, same addresses — the script below is the direct translation of a working QModMaster session.
• 3. When the script misbehaves at 3 a.m., reopen QModMaster and its Bus Monitor to see the raw frames again. GUI for diagnosis, script for the daily grind.

Minimal pymodbus script (Modbus TCP)

The direct translation of “read 10 holding registers from slave 1” into pymodbus 3.x:

from pymodbus.client import ModbusTcpClient

client = ModbusTcpClient("192.168.1.100", port=502)
if not client.connect():
    raise SystemExit("TCP connect failed")

# holding registers (FC03), start address 0, 10 registers, slave id 1
rr = client.read_holding_registers(address=0, count=10, device_id=1)
if rr.isError():
    raise SystemExit(f"read failed: {rr}")

print(rr.registers)  # e.g. [9997, 10034, ...]
client.close()

Version note: current pymodbus (3.10+) names the slave parameter device_id. On older 3.x releases it was called slave, and on the 2.x line unit — if you copy examples from the internet, check which name your installed version expects.

For a serial RTU link, the equivalent client is ModbusSerialClient (same pymodbus.client module):

from pymodbus.client import ModbusSerialClient

client = ModbusSerialClient("/dev/ttyUSB0", baudrate=9600,
                            parity="N", stopbits=1, bytesize=8)
client.connect()
rr = client.read_holding_registers(address=0, count=10, device_id=1)
print(rr.registers if not rr.isError() else rr)
client.close()

What to automate first

• Logging: poll every N seconds, append timestamped rows to CSV. This is the script every solar and energy-meter owner ends up writing.
• Alerting: read a status register in a loop and send a notification when a fault bit flips.
• Regression checks: a CI job that reads a known register map and fails the build when a firmware update moves something.

And keep QModMaster installed next to your scripts. The day a device stops answering, the fastest path back to green is still: open the GUI, read one register by hand, and look at the raw frame.

Related Guides

• Build a Qt Modbus Master with libmodbus (QModMaster-style)
• QModMaster vs mbpoll: GUI or Command Line?
• Test Modbus with QModMaster Before Writing Your Home Assistant Config
• Modbus Float Shows Wrong Value? Fix the Byte Order
• Download QModMaster

This is a real scenario from qtcentre.org (thread 61749, “QT and Libmodbus”): a developer read QModMaster’s source code and wanted to build their own Qt GUI Modbus master application on top of libmodbus — targeting a Raspberry Pi. This page sketches the same architecture QModMaster uses, with a minimal but complete example: connect, read holding registers, and deliver the values to the GUI thread.

The architecture: GUI thread + blocking worker

libmodbus calls such as modbus_read_registers() are synchronous — they block until the reply arrives or the timeout fires. QModMaster-style applications therefore do all Modbus I/O in a worker thread and push results to the GUI through signals and slots. The one rule that matters: never call libmodbus from the GUI thread, or your interface will freeze on every poll.

Minimal example: connect → read → emit

One file, Qt5, C++17. The poller lives in a QThread; a QTimer in that same thread triggers each poll; results travel back via signals:

// Build with:  QT += widgets   and   LIBS += -lmodbus
// Debian / Raspberry Pi OS:  sudo apt install qtbase5-dev libmodbus-dev

#include <QCoreApplication>
#include <QThread>
#include <QTimer>
#include <QVector>
#include <QDebug>
#include <cerrno>
#include <modbus/modbus.h>

class ModbusPoller : public QObject {
    Q_OBJECT
public:
    explicit ModbusPoller(QObject *parent = nullptr) : QObject(parent) {}
    ~ModbusPoller() override {
        if (ctx) { modbus_close(ctx); modbus_free(ctx); }
    }

    bool openRtu(const char *device, int slaveId) {
        ctx = modbus_new_rtu(device, 9600, 'N', 8, 1);
        if (!ctx) return false;
        modbus_set_slave(ctx, slaveId);
        struct timeval timeout{2, 0};               // 2 s response timeout
        modbus_set_response_timeout(ctx, &timeout);
        if (modbus_connect(ctx) == -1) {
            qWarning() << "connect failed:" << modbus_strerror(errno);
            modbus_free(ctx);
            ctx = nullptr;
            return false;
        }
        return true;
    }

public slots:
    void poll() {                                   // runs in the worker thread
        uint16_t regs[10] = {};
        int rc = modbus_read_registers(ctx, 0, 10, regs); // 0-based PDU address
        if (rc == -1) {
            emit failed(QString::fromUtf8(modbus_strerror(errno)));
            return;
        }
        QVector<quint16> out;
        out.reserve(rc);
        for (int i = 0; i < rc; ++i) out.append(regs[i]);
        emit valuesReady(out);
    }

signals:
    void valuesReady(const QVector<quint16> &values);
    void failed(const QString &message);

private:
    modbus_t *ctx = nullptr;
};

int main(int argc, char *argv[]) {
    QCoreApplication app(argc, argv);

    auto *thread = new QThread;
    auto *poller = new ModbusPoller;
    poller->moveToThread(thread);

    auto *timer = new QTimer;          // no parent yet: move it before wiring
    timer->setInterval(1000);
    timer->moveToThread(thread);

    QObject::connect(thread, &QThread::started, [=]() {
        if (!poller->openRtu("/dev/ttyUSB0", 1)) {
            qWarning() << "could not open Modbus link";
            app.quit();
        }
    });
    QObject::connect(timer, &QTimer::timeout, poller, &ModbusPoller::poll);
    QObject::connect(thread, &QThread::started,
                     timer, static_cast<void (QTimer::*)()>(&QTimer::start));
    QObject::connect(poller, &ModbusPoller::valuesReady,
                     [](const QVector<quint16> &v) { qDebug() << "registers:" << v; });
    QObject::connect(poller, &ModbusPoller::failed,
                     [](const QString &m) { qWarning() << "poll failed:" << m; });
    QObject::connect(&app, &QCoreApplication::aboutToQuit, thread, &QThread::quit);
    QObject::connect(thread, &QThread::finished, poller, &QObject::deleteLater);
    QObject::connect(thread, &QThread::finished, timer, &QObject::deleteLater);
    QObject::connect(thread, &QThread::finished, thread, &QObject::deleteLater);

    thread->start();
    return app.exec();
}

// If everything lives in one .cpp file, add at the end:
// #include "main.moc"

For a TCP device instead of serial, swap modbus_new_rtu() for modbus_new_tcp("192.168.1.100", 502) — everything else stays identical.

Build notes

• Debian / Raspberry Pi OS / Ubuntu: sudo apt install qtbase5-dev libmodbus-dev
• .pro file: add QT += widgets and LIBS += -lmodbus
• Qt6: the same code works; install the Qt6 base dev package instead of qtbase5-dev and adjust the QT += line for your Qt6 setup
• Windows: build libmodbus first (see the libmodbus documentation), then link your Qt project against it the same way

Gotchas QModMaster already solved for you

• Timeouts: always set a response timeout (modbus_set_response_timeout) — without one, a dead slave hangs your worker thread.
• Slave ID: call modbus_set_slave() before modbus_connect(); the default unit ID is not always what your device expects.
• Address base: libmodbus uses 0-based PDU addresses — the “40001” in a device manual is address 0 here. See our register address offset guide for the full story.
• Error messages: modbus_strerror(errno) turns a failed call into a human-readable reason — log it, don’t swallow it.

Related Guides

• pymodbus vs QModMaster: Script or GUI?
• QModMaster vs mbpoll: GUI or Command Line?
• Modbus Register Address Offset Guide
• Download QModMaster

QModMaster gives you a Qt graphical interface with live register tables and a Bus Monitor for watching raw frames. mbpoll, by Pascal JEAN, is a command-line utility that talks to Modbus slaves over RTU or TCP, built on libmodbus and released under the GPL-3.0 license. Both are free, both read and write Modbus registers — so which one should you reach for? It depends on where you sit: at a desktop, or on a headless box.

The short answer

Desktop, interactive debugging, first contact with an unknown device → QModMaster. Fill in the connection dialog, see values update live, flip the display between hex, integer and float, and open the Bus Monitor when something looks wrong.

Raspberry Pi, headless server, cron job, automated test script → mbpoll. It is a single tiny binary (Debian and Ubuntu ship it as the mbpoll package; macOS users can brew install mbpoll), it runs fine with no display attached, and its output pipes straight into your scripts.

Side by side

• Interface: QModMaster — graphical register tables and dialogs. mbpoll — one-liners in the terminal.
• Best for: QModMaster — exploring an unknown device, watching values change, teaching. mbpoll — scheduled polling, logging, CI checks, remote SSH sessions.
• Frame-level debugging: QModMaster’s Bus Monitor shows raw request/response frames in the GUI. mbpoll prints poll statistics when you stop it with Ctrl-C, and you can capture its traffic with standard network tools.
• Footprint: QModMaster is a full Qt GUI application. mbpoll is a single small command-line binary that runs on Linux (x86, x86_64, armhf, arm64 — including Armbian/Raspbian on the Pi), Windows and macOS.
• What it can do: both read discrete inputs, read and write coils, read input registers, and read and write holding registers, with values shown in decimal, hexadecimal or single-precision float.
• License: QModMaster — LGPLv3 (upstream project). mbpoll — GPL-3.0.

The same read, two ways

Reading 10 holding registers from slave 1 over a serial link at 9600 baud. In QModMaster: open the connection dialog, pick the serial port, set the unit ID to 1, choose “Read Holding Registers”, start address and count — the values appear in the table. In mbpoll, the equivalent is one command (flags follow the documented mbpoll -h help):

# Read 10 holding registers (-t 4) of slave 1 (-a 1),
# start reference 1 (-r 1), count 10 (-c 10), 9600 baud RTU:
mbpoll -a 1 -b 9600 -t 4 -r 1 -c 10 /dev/ttyUSB0

# Same idea over Modbus TCP (TCP is mbpoll's default mode):
mbpoll -m tcp -a 1 -t 4 -r 1 -c 10 -p 502 192.168.1.100

# Poll just once instead of looping, quieter output:
mbpoll -1 -a 1 -t 4 -r 1 -c 10 192.168.1.100

Handy flags worth knowing: -t 4:float reads a 32-bit float pair, -B switches 32-bit values to big-endian word order, -l sets the poll interval in milliseconds, and -o sets the timeout. Run mbpoll -h (or man mbpoll on Linux) for the complete list — the syntax deliberately resembles the classic proconX modpoll tool, though mbpoll is an independent codebase.

Use them together: the practical workflow

• 1. Probe interactively in QModMaster. Find the right slave ID, the right function code and addresses, and confirm the byte order of multi-register values (see our float byte-order guide if numbers look insane).
• 2. Freeze the working parameters into an mbpoll one-liner for cron, logging scripts or a Pi that has no monitor.
• 3. When the script misbehaves, go back to QModMaster’s Bus Monitor to see the raw frames again. GUI for diagnosis, CLI for automation — they complement each other.

Related Guides

• Build a Qt Modbus Master with libmodbus (QModMaster-style)
• pymodbus vs QModMaster: Script or GUI?
• Test Modbus with QModMaster Before Writing Your Home Assistant Config
• Modbus Float Shows Wrong Value? Fix the Byte Order
• USB-to-RS485 Adapter Buying Guide

You wired up a Modbus device — say, an Aqotec controller behind a Waveshare RS485-to-Ethernet gateway — and QModMaster reads its registers without a hitch. Then Home Assistant logs No response received from the remote unit or Unable to decode response, and nothing updates. This exact “QModMaster works, HA doesn’t” situation comes up regularly in the Home Assistant community. The good news: QModMaster just proved your hardware chain is fine. The fault is almost certainly in the HA configuration — and there is a systematic way to find it.

The bisection rule: if QModMaster reads, the wire is fine

A successful QModMaster read proves, in one shot, that the serial parameters (baud rate, parity, stop bits) or the TCP host and port, the gateway’s operating mode, the wiring, the slave address, and the device itself all work — with exactly the settings you typed in. So stop re-crimping cables and swapping adapters. From here on, the only remaining suspect is how the Home Assistant modbus integration is configured. Keep the working QModMaster session open next to your HA config; you will compare the two value by value.

Step 1 — Write down the four values that worked in QModMaster

• Connection mode: RTU on a serial port, or TCP to the gateway’s IP and port (e.g. 192.168.1.100:8899 for a transparent bridge, :502 for a Modbus-TCP gateway).
• Unit identifier / slave address: the slave ID the read succeeded with.
• Function code and start address: e.g. Read Input Registers (FC04) starting at address 0, or Read Holding Registers (FC03).
• Register count and display format: how many registers you read, and whether the value was 16-bit, 32-bit float, etc.

Step 2 — Match each value to an HA config key

These five mismatches cause nearly every “QModMaster works, HA doesn’t” case:

• Wrong slave / unit ID → “No response received from the remote unit”. The HA slave: key must equal the Unit Identifier that worked in QModMaster. If a TCP gateway serves several slaves, every sensor entry needs its own slave: — one shared value silently breaks the rest.
• Wrong count → “Unable to decode response”. HA’s count: must equal the number of registers the device actually returns. If QModMaster read 10 registers, the sensor needs count: 10; a 32-bit float needs count: 2.
• Wrong data_type → decode errors or garbage values. Match data_type: (int16, uint16, int32, uint32, float32, string…) to the device manual. If floats come back as astronomical numbers, check the byte order too — see our float byte-order fix guide.
• Holding vs. input mix-up. QModMaster’s “Read Holding Registers” (FC03) maps to HA input_type: holding; “Read Input Registers” (FC04) maps to input_type: input. Reading the wrong table produces exception responses the decoder cannot handle.
• Polling too fast. Some devices drop off the bus if polled aggressively. Start with scan_interval: 30 and only speed up once the device proves it tolerates it.

Minimal working HA modbus config to compare against

Use this as a reference skeleton, then replace every value with what worked in your QModMaster session and your device’s manual:

modbus:
  - name: hub1
    type: rtuovertcp   # tcp, rtuovertcp, or serial — must match QModMaster's mode
    host: 192.168.1.100
    port: 8899
    sensors:
      - name: "Voltage"
        slave: 1              # = the Unit Identifier that worked in QModMaster
        address: 0
        input_type: input     # input = FC04, holding = FC03
        data_type: float32
        count: 2
        scan_interval: 30
        unit_of_measurement: "V"

Key names follow the Home Assistant modbus integration documentation; always double-check them against the HA version you run, since integration options evolve.

If it still fails after the config matches

• Open Settings → System → Logs in HA and read the exact frame-level error — it usually names the register or the slave that failed.
• Some gateways need a small delay between requests, and some devices need a longer response timeout than HA’s default.
• Capture both directions: compare a Wireshark capture of QModMaster’s request frame against HA’s request frame. The first byte that differs is your bug.

And if you haven’t done the probe-first workflow yet, start here: test your Modbus link with QModMaster before writing the Home Assistant config — five minutes with the GUI saves hours of YAML guessing.

Related Guides

• Test Modbus with QModMaster Before Writing Your Home Assistant Config
• Modbus Float Shows Wrong Value? Fix the Byte Order
• USB-to-RS485 Adapter Buying Guide
• QModMaster Tutorial: Your First Modbus Read
• Download QModMaster

The View menu in QModMaster does not change what your device sends — it changes how the same raw bytes are interpreted and displayed. Pick the wrong format and a perfectly healthy reading looks broken; pick the right one and half of all “wrong value” mysteries solve themselves. This page is the hub: what each format means, when to use it, and the exact switching sequence to run when a reading looks wrong.

What the formats actually do

Every Modbus register is 16 bits. The View menu decides how those bits (and groups of them) are decoded for display:

• Hex (16-bit): shows each register exactly as it arrived, e.g. 0x04D2. This is the ground truth — no interpretation, no surprises. Always start here when something looks wrong.
• Binary (16-bit): the same bits as 0s and 1s. Useful when you are debugging individual status flags / bit fields packed into one register.
• INT16 / signed 16-bit: interprets one register as −32,768…32,767. Right for counters and small signed quantities — wrong for anything that exceeds 32,767 (it will flip negative).
• UINT16 / unsigned 16-bit: interprets one register as 0…65,535. Right for raw ADC counts, status words, and protocol fields.
• INT32 / UINT32 (32-bit): combines two consecutive registers into one 32-bit integer. Right for energy totals and large counters — but sensitive to word order (ABCD vs CDAB).
• Float (32-bit): combines two consecutive registers and decodes them as an IEEE-754 floating-point number. Right for voltages, temperatures, and power with decimals — but sensitive to byte order (four possible orders).

Which format, when: the cheat sheet

• Debugging anything and unsure → Hex. Read raw first, interpret second.
• Status flags, alarms, bit-packed coil images → Binary or Hex.
• Small counters, setpoints, temperatures as integers → INT16/UINT16.
• Energy totals (kWh), large counters → INT32/UINT32, then check word order.
• Voltage, current, power, temperature with decimals → Float, then check byte order.

The “reading looks wrong” switching drill

Run this sequence top to bottom. Stop at the first step that explains the value — most cases resolve at step 2 or 3.

• Step 1 — Hex. Switch to Hex and read the raw register(s). If the raw words already look wrong (all 0xFFFF, all zeros, unchanging), the problem is upstream: wiring, address, or slave — not the format.
• Step 2 — match the documented type. Check the device’s register map: does it say this address is INT16, UINT32, or Float? Set the View format to match exactly. A UINT32 read as INT32 flips negative past 2,147,483,647; a Float read as INT32 is garbage.
• Step 3 — test word/byte order. If a 32-bit integer is ~65,536× off, the words are swapped → word-swap fix. If a float shows astronomical values, try the other byte orders → float byte-order fix.
• Step 4 — apply scale and offset. If the value is off by 10×/100×/1000× or a round constant, it is scaling or an offset → scale factor & offset guide.
• Step 5 — verify the address. If the value is plausible but belongs to a different measurement, you are reading the wrong register: check 0-based vs 1-based addressing in your device’s manual.

Common mistakes

• Reading a Float register as INT32 (or vice versa) — the two decodings of the same bytes look nothing alike, and both look “broken.”
• Reading an unsigned quantity as signed INT16 — values over 32,767 wrap negative.
• Forgetting that 32-bit formats consume two registers — if you request only one register and display INT32, the second half is missing.
• “Fixing” the format when the real problem is the address — always confirm raw Hex values against the device’s own display first.

Deep dives

• Modbus Float Shows a Wrong Value? Byte-Order Fix — four byte orders, Schneider’s official guidance, QModMaster workflow.
• Modbus 32-bit Integer Wrong? Word Swap (CDAB) Fix — the 65,536× signature and the EM24 little-endian trap.
• Modbus Values Off by 10x? Scale Factor & Offset — the Deye temperature offset-1000 example and 60-second mental-math check.

FAQ

Does changing the View menu change what QModMaster requests from the device?

No. The View menu only changes how received bytes are decoded for display. The Modbus request (function code, address, register count) is unaffected.

Which View format should I start with when debugging?

Hex. It shows the raw register contents with zero interpretation, so you can tell whether the problem is the data on the wire or merely how it is decoded.

Why does my float show a huge wrong number in QModMaster?

Almost always a byte-order mismatch: the device sends the four bytes in a different order than the Float decoder expects. See the float byte-order fix for the four orders and how to identify yours.

Related Guides

• Modbus Float Shows a Wrong Value? Byte-Order Fix
• Modbus 32-bit Integer Wrong? Word Swap (CDAB) Fix
• Modbus Values Off by 10x? Scale Factor & Offset
• Download QModMaster — free, open-source (LGPLv3) Modbus master.

Learning Modbus data encoding properly pays off on every device you touch: recommended Modbus protocol book.

QModMaster shows 2355 but your inverter’s display says 235.5 V. Or a temperature reads 1025 when the room is clearly 25 °C. Before you blame the wiring, the address, or the byte order — check the two most boring explanations in Modbus: scale factors and offsets. They account for a huge share of “wrong value” reports, and they are verified with mental math in under a minute.

Scale factor: the register holds an integer, the value has decimals

Modbus registers are 16-bit integers — they cannot store a decimal point. So device makers store 235.5 V as the integer 2355 and document a scale factor of 0.1 (or “divide by 10”). Common variants:

• ÷ 10 — voltages, currents with one decimal (2355 → 235.5 V).
• ÷ 100 — two decimals (23550 → 235.50 V).
• ÷ 1000 — power/energy with three decimals, or millivolt-native sensors.
• × 10 / × 100 — the reverse: some devices store a multiplied value (rare, but documented in a few meter maps).

The scale factor is always in the device’s register map / protocol document — look for columns labeled “scale,” “factor,” “multiplier,” “gain,” or a unit like “0.1 V”. If your reading is off by exactly 10×, 100×, or 1000×, scaling is guilty until proven innocent.

Offset: the register value is shifted by a constant

Some devices add a fixed offset so that an unsigned register can represent a signed quantity. The documented real-world example is Deye inverters: certain temperature registers carry an offset of 1000, i.e.

actual temperature = raw register value − 1000

So a raw reading of 1025 means 25 °C, and a raw reading of 985 means −15 °C — the offset lets the unsigned register express temperatures below zero. If your temperature is off by a suspiciously round constant (not a round multiple), look for an “offset” column in the register map.

The 60-second verification in QModMaster

• Step 1 — read raw. In QModMaster, read the register with a plain integer View format (no float interpretation yet). Write down the raw integer.
• Step 2 — divide first. Divide the raw value by 10, 100, and 1000 in your head. Does one of the results exactly match the device’s own display? Then you have found the scale factor.
• Step 3 — subtract second. If division does not fit but the value is off by a round constant, subtract candidate offsets (1000 is the classic for temperatures). A raw 1025 → 25 °C after −1000 confirms the offset.
• Step 4 — confirm in the manual. Find the scale/offset columns in the official register map and note them next to the address in your own notes. Always let the device manual win over any rule of thumb on this page.

Telling scaling apart from byte-order problems

• Off by 10× / 100× / 1000× → scale factor (this page).
• Off by a round constant (e.g. always 1000 too high) → offset (this page).
• Off by 65,536× → word swap: Modbus 32-bit Integer Wrong? Word Swap (CDAB) Fix.
• Float showing astronomical garbage → byte order: Modbus Float Shows a Wrong Value? Byte-Order Fix.
• Reading a completely different register’s value → address off-by-one: check your device’s 0-based vs 1-based addressing.

FAQ

Why does my Modbus reading show 2355 instead of 235.5?

Modbus registers hold integers only, so the device stores 235.5 V as 2355 with a documented scale factor of 0.1. Divide the raw value by 10. The scale factor is listed in the device’s register map.

What is the Deye temperature offset of 1000?

Certain Deye inverter temperature registers add an offset of 1000 so an unsigned register can represent negative temperatures: actual °C = raw value − 1000. A raw reading of 1025 means 25 °C.

How do I know whether it’s scale, offset, or byte order?

Divide the raw value by 10/100/1000 — an exact match means scaling. If it is off by a round constant, suspect an offset. If it is off by 65,536× or shows garbage floats, it is a word/byte-order problem instead.

Related Guides

• Modbus 32-bit Integer Wrong? Word Swap (CDAB) Fix — when the error is 65,536×, not 10×.
• Modbus Float Shows a Wrong Value? Byte-Order Fix — garbage floats, four byte orders.
• QModMaster View Menu: Float/Int/Hex/Binary Explained — pick the right display format first.
• Download QModMaster — free, open-source (LGPLv3) Modbus master.

Want the full encoding story? The Modbus protocol book covers scaling, offsets, and data representation in one place.

Here’s the classic maker trap: your Arduino Modbus slave sketch answers perfectly when the PC talks to it over a USB-to-TTL cable — every read in QModMaster succeeds. Then you swap in a MAX485 module for real RS485, and QModMaster just says timeout, no response. The sketch didn’t change. The slave ID didn’t change. What changed is the physics of the bus — and the fix is two wires. This exact failure was reported on the Arduino Forum (a user’s slave worked via USB but timed out over a MAX485 module), and the diagnosis there is still the right one: it’s the MAX485 transceiver direction control — the DE/RE pins.

Why USB works and MAX485 doesn’t

A USB-to-TTL cable is full-duplex: transmit and receive have their own wires, so the Arduino can listen and talk at the same time. RS485 is half-duplex: the A/B pair is shared, and the MAX485 chip needs to be told which direction it’s going. That’s what the DE (Driver Enable, transmit) and RE (Receiver Enable, receive) pins do:

• DE = HIGH: the MAX485 drives the bus — the Arduino is transmitting.
• DE = LOW (RE = LOW): the MAX485 listens — the Arduino is receiving.

If DE/RE are left floating, tied to the wrong level, or toggled by a library that doesn’t wait for transmission to finish, the Arduino’s reply never actually makes it onto the bus — and QModMaster sees a timeout. Per the forum diagnosis, the library must hold the MAX485 in transmit mode for the whole time the reply is being sent; simply pushing bytes into the serial buffer and flipping back to receive too early is enough to break it.

The wiring (text diagram)

Wire DE and RE together to one Arduino digital pin (D2 is the common choice). One pin then controls the direction: HIGH = transmit, LOW = receive.

MAX485 module          Arduino
-----------          -------
  VCC        ----    5V
  GND        ----    GND
  DI         ----    TX  (Arduino transmit → MAX485 data in)
  RO         ----    RX  (MAX485 data out → Arduino receive)
  DE + RE    ----    D2  (tied together; direction control pin)
  A          ----    RS485 bus A
  B          ----    RS485 bus B

  120 Ω resistor across A–B at EACH END of the bus (termination)

Two practical notes: on an Arduino Uno the hardware serial port is shared with USB, so use a software serial port for the MAX485 side and keep hardware serial free for USB debugging. And A/B are differential — if everything is wired right but you still get timeouts, try swapping A and B once (a reversed pair fails silently).

The code fix: drive the direction pin properly

Your Modbus library must know about the direction pin and hold it HIGH for the entire reply transmission — including waiting for the last byte to physically leave the UART — before dropping back to receive. Libraries built for RS485 expose this as a “TX enable pin” setting or pre/post-transmission callbacks. If your current library has no direction-pin support at all, that’s your answer: switch to one that does, set the TX enable pin to D2 (or whichever pin you wired), and retest. Don’t try to toggle the pin manually around library calls — the timing (waiting for the transmit buffer to fully drain) is exactly what goes wrong.

QModMaster-side checklist

Once DE/RE is wired and the library handles it, verify from the PC side:

• Slave ID in QModMaster must match the ID in the sketch.
• 9600 8N1 on both ends — QModMaster’s serial options and the sketch’s baud rate must agree.
• Read one register first. A single-register read is the smallest possible transaction; get that working before scanning ranges.
• No duplicate slave IDs on the bus — two devices answering the same ID produces intermittent garbage, not clean timeouts, but rule it out anyway.
• Termination: 120 Ω across A–B at both bus ends. Missing termination mostly bites on longer runs.

The adapter for the PC side

USB-to-RS485 adapter (Amazon) — your PC needs one to join the RS485 bus at all. Pick an FTDI-based adapter; this is the page where a flaky adapter will waste the most of your time, because its symptoms look exactly like the DE/RE problem above.

FAQ

My Arduino Modbus slave works over USB-to-TTL but times out with MAX485. What’s wrong?
The DE/RE direction pins. USB-to-TTL is full-duplex and needs no direction control; RS485 is half-duplex, and if the MAX485 isn’t held in transmit mode for the whole reply, the response never reaches the bus.

Can I just tie DE high and RE low permanently?
No — then the module transmits constantly and can never receive the master’s request. DE and RE must be tied together to a GPIO and driven HIGH only while transmitting, LOW while receiving.

I fixed DE/RE and still get timeouts. What next?
Verify the slave ID matches the sketch, 9600 8N1 on both sides, try swapping A/B once, and confirm the library waits for the UART transmit buffer to drain before dropping DE back to receive. Then try a single-register read in QModMaster.

Related Guides

• QModMaster tutorial: your first register read
• USB-to-RS485 adapter buying guide

The USB-works/MAX485-times-out symptom and the transceiver-control diagnosis come from a real Arduino Forum thread (“MODBUS Slaves with Arduino”). Pin choices (D2) and wiring conventions are standard maker practice — adapt to your board and library. qmodmaster.com is an independent community resource for the upstream QModMaster project (LGPLv3) and is not affiliated with Arduino.

You’ve got your Solis inverter wired to a USB-to-RS485 adapter, QModMaster is talking to it (wrong slave address gives timeouts, the right one answers) — but every register read comes back Exception Code 02: Illegal Address. The wiring is fine, the baud rate is fine, and the slave ID is right. The trap is in the register address itself, and it’s documented by a real Solis owner’s debugging session on the DIY Solar Forum: Solis’s official documentation lists register addresses like 33025 with the note “no further offset or other conversion is required” — and it means it literally. Type the full address.

The trap: 33025 means 33025, not 3025

Most Modbus tools and tutorials teach you to strip the leading digit off 3xxxx/4xxxx addresses: “input register 33025” becomes protocol address 3024 (or 3025, depending on the tool’s convention). For Solis inverters, that habit breaks everything. The forum poster (RHI-5K-48ES-5G) got Illegal Address errors on every read until he typed the complete address: a 3-register read of 33025–33027 immediately returned a live hh:mm:ss clock value from the inverter.

So in QModMaster: enter 33025 in the address field — don’t subtract 1, don’t strip the leading 3, don’t convert. If the manual’s address table says 33000, you read 33000. Trust the manual’s literal numbers.

Baseline settings that must be right first

From the same real-world session, the working baseline for talking to a Solis inverter over its COM connector:

• Mode: Modbus RTU over RS485 (2-core cable to the COM connector’s A/B pins).
• Serial: 9600 bps, 8 data bits, 1 stop bit, no parity (8N1).
• Slave address: must match the address set on the inverter itself. A wrong slave ID gives timeouts; the right ID with a wrong register gives Illegal Address — that difference is actually a useful diagnostic.
• Function code: 0x04 (Read Input Registers) for the 3xxxx measurement registers.

Always confirm these against your own Solis manual — settings and pinouts can vary between models and firmware generations.

Watch the byte order on multi-register values

The forum session also surfaced a second quirk: some multi-byte values came back looking byte-swapped until interpreted the other way round (the poster saw an unfeasibly large decimal where a small value was expected, and the swap theory led to the breakthrough). If your single-register reads are fine but 32-bit values look wrong, try the swapped byte/word interpretation in QModMaster’s View menu before assuming the address is wrong — and cross-check the expected byte order in your Solis documentation.

The hardware you need

USB-to-RS485 adapter (Amazon) — the forum poster’s setup used a USB-RS485 serial adapter straight to a laptop. A dependable FTDI-based adapter is the safest first purchase; unstable adapters mimic the exact “timeout vs Illegal Address” confusion this page helps you avoid.

FAQ

QModMaster says “Illegal Address” on my Solis inverter but the wiring seems fine. What’s wrong?
Almost certainly the address format: type the full address from the Solis manual (e.g. 33025), not a stripped or minus-1 variant. The official Solis documentation states no offset or conversion is required — take it literally.

How do I tell a wiring problem from an addressing problem?
Change the slave address to a wrong value: timeouts mean the wiring/serial settings are wrong; the correct slave ID with wrong register addresses gives Illegal Address (exception 02). That distinction tells you which half of the setup to fix.

My 32-bit Solis values are huge nonsense numbers. Offset problem?
Probably not an offset — single registers reading fine points to byte/word order instead. Try the swapped interpretation in QModMaster’s View menu and verify against your manual.

Related Guides

• QModMaster tutorial: your first register read
• USB-to-RS485 adapter buying guide

The full-address finding (33025–33027 returning live data) comes from a real owner’s debugging thread on the DIY Solar Forum (Solis/Ginlong Modbus Comms). Solis register tables, serial settings, and pinouts vary by model — always confirm against your own inverter’s manual. qmodmaster.com is an independent community resource for the upstream QModMaster project (LGPLv3) and is not affiliated with Solis.

You’ve got the Carlo Gavazzi EM24 energy meter wired up, QModMaster returns registers without errors — and the numbers are nonsense. Voltage reads as millions of volts, or the power figure is off by a factor of 65,536. Before you rewire anything: the EM24 uses little-endian word order (low word at the lower address), the opposite of what most Modbus devices use. That single reversed assumption is the #1 cause of wrong EM24 readings, and it’s documented in the EM24 register-map reference used by the victron-grid-meter-esphome project, which emulates an EM24 over Modbus TCP: “All multi-register values use little-endian word order (low word at lower address)”.

What “little-endian word order” means in practice

A 32-bit value spans two 16-bit registers. On most devices the high word sits at the lower address (big-endian words: high word first). On the EM24 it’s flipped — the low word comes first:

Registers at 0x0000, 0x0001 hold a 32-bit voltage value
  0x0000 = LOW word    (EM24: low word at lower address)
  0x0001 = HIGH word

  value = LOW + HIGH × 65536        (then apply the scale)

Wrong assumption (big-endian words):
  value = HIGH + LOW × 65536        → garbage / millions

So if you decode EM24 registers the “normal” way, every 32-bit reading — voltage, current, power, energy — comes out wrong. It’s not a wiring problem and it’s not a bad meter. It’s the word order.

Step 1: Prove your link with the Model ID register

Before touching multi-register values, read a single 16-bit register that has a known answer. The EM24 register map lists address 0x000B as the Model ID, which should read 1648 (EM24DINAV23XE1X). In QModMaster:

• Function code 0x03 or 0x04 (the EM24 map supports both for reads), Unit ID matching your meter’s slave address.
• Read 1 register at address 0x000B.
• Expect 1648. If you get it, your link, baud rate, and addressing are all correct — anything weird after this point is data interpretation, not communication.

Step 2: Read voltage and test both word orders

Now read 2 registers starting at 0x0000 (Voltage L1, int32, scale ÷10 V) and display them as raw hex (QModMaster’s View menu lets you switch the display format). Then decode both ways by hand:

Example: registers read back as 0x0000 = 0x08FC, 0x0001 = 0x0000

Little-endian words (correct for EM24):
  value = 0x08FC + 0x0000 × 65536 = 2300  →  2300 ÷ 10 = 230.0 V  ✓

Big-endian words (wrong for EM24):
  value = 0x0000 + 0x08FC × 65536 = 587,202,560  → garbage  ✗

Whichever decoding matches your multimeter / the meter display is your answer. For the EM24, it will be the little-endian one. Apply the same low-word-first rule to every 32-bit register.

EM24 register map (Ethernet model, excerpt)

From the community-documented EM24 register map — confirm every address against your own Carlo Gavazzi manual, as variants differ:

Per-phase registers step by 2 per phase: L1 at the base address, L2 at base+2, L3 at base+4. Power is signed (negative = exporting); current is always a positive magnitude with direction taken from the power sign.

Wiring the meter to your PC

USB-to-RS485 adapter (Amazon) — to read an EM24 over its serial port you’ll need a USB-to-RS485 adapter on the PC side. Get an FTDI-based one; flaky adapters are the classic source of intermittent Modbus timeouts.

FAQ

My EM24 voltage reads in the millions. Is the meter broken?
No — you’re decoding with big-endian word order. The EM24 puts the low word first. Re-decode as low + high × 65536 and the value will snap to something sensible.

How do I confirm my communication settings are right before worrying about word order?
Read address 0x000B (Model ID). It should return 1648 on an EM24DINAV23XE1X. If it does, your link is fine and any wrong values are an interpretation problem.

Does the word order apply to energy registers too?
Yes — every multi-register (32-bit) value on the EM24 uses little-endian word order, including power and energy. Single 16-bit registers (like 0x000B and 0x0033) are unaffected.

Related Guides

• QModMaster tutorial: your first register read
• USB-to-RS485 adapter buying guide

The little-endian word order and register map above are documented in the remcom/victron-grid-meter-esphome project (an EM24 Modbus TCP emulation whose register table mirrors the meter). Register addresses, scales, and word order can vary between EM24 variants — always confirm against your Carlo Gavazzi manual. qmodmaster.com is an independent community resource for the upstream QModMaster project (LGPLv3) and is not affiliated with Carlo Gavazzi.

Your energy meter says it exported 1,234 kWh, but QModMaster shows 80,889,344. Or a counter reads fine until it crosses 32,767 and suddenly goes negative. If the raw registers look plausible but the 32-bit value is exactly 65,536× too big (or the sign flips), you are looking at a word-swap problem: your device sends the two 16-bit words in the opposite order from what your display format expects.

ABCD vs CDAB: what “word order” means

A 32-bit integer occupies two consecutive 16-bit Modbus registers. Call the register at the lower address the high word (AB) and the next one the low word (CD). Two conventions exist:

• Big-endian words (ABCD): high word first, then low word. This is the Modbus “default” most devices and software assume. Value = high × 65536 + low.
• Little-endian words (CDAB): low word first, then high word. Some devices — the Carlo Gavazzi EM24 energy meter is a well-documented example — transmit multi-register values this way.

Worked example. Suppose the true value is 1,234, stored as high word = 0, low word = 1234:

• Read as ABCD (correct): 0 × 65536 + 1234 = 1,234 ✓
• Read as CDAB-interpreted-as-ABCD (wrong): 1234 × 65536 + 0 = 80,889,344 ✗ — exactly 65,536× too large.

That 65,536× signature is the giveaway. (And if the value only goes wrong past 32,767 — flipping negative — you are likely reading an unsigned 32-bit value as signed INT32, which is the signed/unsigned half of the same family of problems.)

Diagnose it in QModMaster (2 minutes)

• Step 1 — read the raw words. Set QModMaster’s View menu to a plain 16-bit format (Hex or INT16) and read the two registers. Write down both words, e.g. 0x0000 and 0x04D2.
• Step 2 — switch to 32-bit. Change the View menu format to INT32 / unsigned 32-bit and read the same pair. If the displayed value is ~65,536× your expected value, the words are swapped relative to what the format expects.
• Step 3 — verify by swapping. Reconstruct it by hand: treat the second word as the high word. In the example: high = 0x0000, low = 0x04D2 → 0 × 65536 + 1234 = 1234. If the hand-swapped value matches your meter’s display, you have confirmed CDAB word order.
• Step 4 — check the manual. Look for “word order,” “byte order,” “little-endian,” or “low word first” in your device’s Modbus register map. EM24 documentation, for instance, explicitly states little-endian word order for multi-register values.

The EM24 counter-example (little-endian in the wild)

The Carlo Gavazzi EM24 is the classic trap: most of the Modbus world defaults to big-endian words, but the EM24 transmits multi-register values low word first. Community integrations (e.g. ESPHome-based EM24 grid-meter projects) document this explicitly — you must swap the words before interpreting. If your EM24 energy totals are exactly 65,536× off in QModMaster, do not touch your wiring: it is the word order, and the device manual agrees with the “wrong” reading.

Word swap vs byte swap vs float problems

• Word swap (this page): 32-bit integers off by exactly 65,536×, or sign flips. Fix = swap the two 16-bit words.
• Byte swap: 16-bit values that look like garbage (e.g. 0x1234 read as 0x3412). Fix = swap bytes within each word. Different problem, different fix.
• Float byte order: 32-bit floats showing astronomical or garbage values. Same family, but floats have four possible byte orders (ABCD, BADC, CDAB, DCBA) — covered in Modbus Float Shows a Wrong Value? Byte-Order Fix.

FAQ

Why is my Modbus 32-bit value exactly 65536 times too big?

Because the device sends the two 16-bit words low-word-first (CDAB) while your software interprets them high-word-first (ABCD). The low word gets multiplied by 65,536 instead of the high word. Swap the words and the value will be correct.

How do I swap words in QModMaster?

Read the two registers in a 16-bit View format (Hex), note both words, then reconstruct the value treating the second word as the high word. Alternatively switch the View format between 32-bit variants and compare against the device’s own display to identify which interpretation matches.

Is the EM24 really little-endian?

Yes — the Carlo Gavazzi EM24 transmits multi-register values low word first, contrary to the Modbus big-endian default. This is documented in the EM24 register documentation and in community integration projects. A 65,536× error on an EM24 is expected behavior, not a fault.

Related Guides

• Modbus Float Shows a Wrong Value? Byte-Order Fix — the floating-point sibling of this problem (four byte orders, not two).
• QModMaster View Menu: Float/Int/Hex/Binary Explained — which display format to use when.
• Modbus Values Off by 10x? Scale Factor & Offset — when the value is wrong by 10× instead of 65,536×.
• Download QModMaster — free, open-source (LGPLv3) Modbus master.

Debugging a meter or inverter? A protocol reference helps: Modbus protocol book covers data encoding in depth.