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

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.

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.

Everything works for a while — then the device stops answering, the link drops, and only a restart brings it back. If that pattern sounds familiar, you may not have a wiring problem at all. You may be polling a slow device faster than it can cope with, and it’s collapsing under the load. This page explains why it happens and how to fix it at the system level.

This is the theory companion to QModMaster Scan Rate: Fix Timeouts on Slow Devices, which covers the hands-on QModMaster settings (scan control, bus-load estimates, chunking your reads). Read that one to tune the client; read this one to understand the failure — and to fix it permanently.

A real case: the Sungrow inverter that dropped its link

This isn’t hypothetical. The Sungrow SHX inverter Home Assistant FAQ documents exactly this failure: the Modbus connection works, then drops after running for a while. The documented fixes are adding a Modbus proxy and reducing the poll frequency — in other words, the inverter’s Modbus stack couldn’t sustain the request rate, and slowing down the interrogation fixed it. The same thread is why a SourceForge user asked QModMaster for a “Changeable scan rate from 10ms up to minutes”: aggressive polling is a known device-killer across vendors.

Why slow slaves collapse under fast polling

• Modbus is a background task. On an inverter, meter, or PLC-adjacent controller, the CPU’s real job is power conversion or metering. The Modbus server gets leftover cycles. Hammer it and responses get slower — which makes the master retry sooner — which makes it worse. It’s a feedback loop.
• Tiny buffers overflow. Cheap slaves have small UART buffers. A new request arriving before the old reply finished transmitting overwrites or interleaves data — the device locks up or starts answering with garbage until rebooted.
• Watchdogs bite. Some devices run a communication watchdog: sustained abnormal traffic patterns trigger a protective reset of the comms stack, which looks exactly like a “link drop”.
• Half-duplex collisions. On RS-485, if the master transmits while the slave is still answering, both frames are destroyed. Faster polling shrinks the safety margin to zero.

The fixes, from easiest to most robust

1. Lower the poll rate. The obvious one, and the Sungrow FAQ’s first recommendation. Poll every few seconds instead of several times per second — most process values (temperature, power, energy totals) don’t change fast enough to justify aggressive polling anyway.

2. Stagger polling across devices. Don’t poll all slaves in a tight burst. Spread requests evenly across the cycle so each device gets idle recovery time between its turns.

3. Poll fewer registers. A 100-register block read keeps a slow slave busy far longer than the wire time suggests — it has to gather every value. Split big blocks; skip registers you don’t actually use.

4. Add a Modbus proxy. The Sungrow FAQ’s structural fix: one proxy polls the fragile device at a gentle, fixed rate and caches the results; QModMaster, Home Assistant, and your SCADA all read from the proxy’s cache as fast as they like. The slow device sees exactly one polite client. This is the correct architecture once more than one master needs the same data.

5. Separate fast and slow devices. If one sluggish inverter shares a bus with snappy sensors, give the slow device its own poll loop (or its own bus segment) so it never holds up — or gets trampled by — the fast traffic.

Your bus works fine most of the time — then readings jump, CRC errors appear out of nowhere, and one device only misbehaves when another is powered on. Before you blame the cable, check the simplest cause with the weirdest symptoms: two devices on the same bus configured with the same slave ID. Both answer the same request, their replies collide on the wire, and you get garbage that looks like everything except an addressing mistake.

Symptoms of a slave ID collision

• Intermittent CRC errors — sometimes the read is clean, sometimes it fails, with no pattern. Two overlapping replies corrupt each other’s frames.
• Readings that jump between two values — whichever device’s reply wins the collision this time decides what you see.
• Works with one device disconnected. The single most diagnostic symptom: unplug device B and device A is suddenly rock solid.
• Wrong device responds. You poll ID 5 expecting the energy meter and get the temperature sensor’s registers — because both are ID 5.

Duplicate responses causing bus collisions are a documented classic in Modbus troubleshooting write-ups (e.g. IoTStudioz’s 2025 field notes list duplicate IDs among the top causes of “mystery” CRC errors). The insidious part is that a single-device test always passes — the collision only exists when both twins are on the bus.

How to find the duplicate

Method 1 — disconnect one by one (small buses). Power down everything. Bring devices up one at a time, polling each from QModMaster as you go. The moment the errors start, the last device you added shares its ID with one already on the bus.

Method 2 — binary search (large buses). Split the bus in half (disconnect the middle). If the errors persist, the duplicate pair is in the connected half; if they stop, it’s in the disconnected half. Repeat until two devices remain.

Method 3 — watch the bus monitor. QModMaster’s Bus Monitor shows raw traffic. Poll the suspect ID once: if you see two replies (or one reply with doubled/corrupted bytes), you’ve caught the twins red-handed.

Once found, change one device’s address — via DIP switches, its configuration menu, or vendor software — then power-cycle it (many devices only read their address at boot). Re-poll from QModMaster to confirm each ID now answers exactly once.

Prevent it: plan the ID table before power-up

• Write down every device and its slave ID before wiring — a simple table on paper beats debugging later.
• Don’t trust factory defaults: many devices ship as ID 1. Two “fresh out of the box” devices on one bus are already a collision.
• Label each device with its ID (tape + marker is fine).
• Reserve a block per device type (e.g. meters 1–9, inverters 11–19) so future additions don’t collide.
• After any change, do a full-bus poll from QModMaster and confirm every ID responds exactly once.

If QModMaster looks fine on an old 1080p monitor but turns into a blurry, cramped mess on your 4K laptop screen, you are not alone. A SourceForge reviewer put it bluntly: “Windows GUI is unusable on a high-dpi display… controls are scaled properly but positioned with hardcoded pixel counts.” QModMaster is built on the older Qt5 toolkit, and this class of high-DPI problem is common to Qt5-era desktop apps. The good news: Windows gives you several per-app levers that usually make it usable again.

Honest expectation up front: the fixes below mitigate the problem — they do not guarantee a pixel-perfect UI. QModMaster is a community-maintained open-source project (LGPLv3, built on libmodbus and Qt), and as far as publicly documented releases go, no version has been announced with a rewritten high-DPI layout. If you came here hoping for an “official fix in version X,” that does not exist — what exists are workarounds, ranked below from most to least effective.

Why it happens

Qt5 applications ask Windows how much to scale text and controls, but some dialog layouts inside QModMaster position widgets with fixed pixel coordinates. When Windows applies 150% or 200% display scaling, the text grows but the boxes it sits in do not — labels overlap buttons, the register table squeezes into a corner, and everything renders through a blurry bitmap-scale fallback. The ugliness is worst when:

• Windows display scaling is set above 100% (125%, 150%, 175%, 200%).
• You use multiple monitors with different scaling (e.g. a 4K laptop at 200% plus an external 1080p monitor at 100%). Dragging the window across screens can re-trigger the bad layout.
• You run QModMaster over Remote Desktop, where the remote session’s DPI rarely matches your local screen.

Fix 1: Override the high-DPI scaling behavior (most reliable)

This is the single most effective workaround, and it works per-application so it will not change how the rest of your system looks:

• Find QModMaster.exe in File Explorer, right-click it, and choose Properties.
• Open the Compatibility tab and click Change high DPI settings.
• Check “Override high DPI scaling behavior” and try the two modes in order:
  • System (Enhanced) — Windows scales the app’s text crisply using its own renderer. This usually gives the sharpest result for Qt5 apps.
  • System — Windows bitmap-scales the whole window. It may look slightly soft, but layouts stop overlapping.
• Click OK, restart QModMaster, and re-check the dialogs that were broken (Modbus settings, register table, Bus Monitor).

There is no universally “best” choice between the two — it depends on your GPU driver and Windows build. Try System (Enhanced) first; if dialogs still misbehave, fall back to System.

Fix 2: Match the monitor setup

If you run a mixed-DPI desk (e.g. laptop 200% + external monitor 100%):

• Keep QModMaster on one monitor and do not drag it across screens mid-session. The bad layout is typically re-triggered on monitor switches.
• As a test, temporarily set the monitor you work on to 100% scaling (Settings → System → Display). If QModMaster snaps back to normal, you have confirmed this is purely a scaling issue and not a corrupted install.
• On Remote Desktop, set the remote session to the same scaling as your local display before connecting.

Fix 3: Lower the resolution you ask of the app

If the override in Fix 1 does not help on your machine, a blunt but effective option is to run your display at its native 100% scaling with a lower resolution while debugging Modbus (you can switch back afterwards). QModMaster is a troubleshooting tool you open for minutes at a time — a slightly chunkier desktop for one session is a fair trade for readable registers.

What NOT to expect

• No registry hack or manifest edit is required — the Compatibility-tab override is the supported path.
• Do not expect font-size settings inside QModMaster to fix layout overlaps; the app has no built-in DPI controls.
• If someone on a forum claims “version X fixed high-DPI,” treat it as unverified unless the upstream project’s SourceForge page release notes say so.

FAQ

Why is QModMaster blurry only on my 4K monitor?

Because Windows applies display scaling (150–200%) on high-resolution screens, and QModMaster’s Qt5-era layouts position some controls with fixed pixel coordinates. Text scales, boxes don’t — the result is overlapping, blurry widgets.

Which “Override high DPI scaling” mode should I pick?

Start with System (Enhanced) for the sharpest text. If dialogs still overlap or crash into each other, switch to System, which bitmap-scales the whole window and is the most layout-safe option.

Does this affect my Modbus data or readings?

No. High-DPI scaling is purely cosmetic — it changes how the window is drawn, never the bytes on the wire. Your register values, timeouts, and bus traffic are unaffected.

Is there an official fixed version?

Not that has been publicly announced. QModMaster is community-maintained open source (LGPLv3); the workarounds on this page are the current practical answer.

Related Guides

• Download QModMaster — get the latest Windows build.
• QModMaster View Menu: Float/Int/Hex/Binary Explained — once the UI is readable, make sure your values are too.
• Modbus Float Shows a Wrong Value? Byte-Order Fix — the other classic “the numbers look broken” problem.

Your device answers every manual read in QModMaster, but the moment you enable Scan mode — continuous polling — it starts timing out, drops off the bus, or needs a power cycle to come back. The device isn’t broken. You’re just asking it questions faster than it can answer. This guide covers where the scan control lives in QModMaster, what “slave response time” actually means, and how to estimate whether your RS-485 bus is overloaded.

This is the practical, QModMaster-settings companion to our deeper dive Modbus Polling Too Fast? Slow Slave Overload Fix, which explains the physics of why slow devices collapse under fast polling (with a real Sungrow inverter case).

Where the scan control lives in QModMaster

In the QModMaster main window, the Scan checkbox (near the read controls) switches from single-shot reads to continuous polling — QModMaster re-issues your read request over and over, updating the values live. That’s the feature timing out your slow device.

An honest caveat before you go hunting for a dial: QModMaster’s built-in scan control is basic, and users have been asking for more. A SourceForge feature request literally asks for a “Changeable scan rate from 10ms up to minutes” — because the stock behavior can be too aggressive for slow hardware. If you can’t slow the scan enough inside QModMaster, the workarounds below are the real fix, not a different checkbox.

Understand slave response time

Every Modbus slave needs a moment between receiving your request and having an answer ready. Cheap microcontrollers, solar inverters, and energy meters often need tens to hundreds of milliseconds to service a Modbus request — they’re busy running their actual job (inverting power, metering energy) and Modbus is a background task.

If QModMaster fires the next request before the slave finished the previous one, three bad things happen: the slave ignores the new request (timeout on your side), it answers late and the reply collides with your next request (CRC errors), or its tiny receive buffer overflows and the device locks up until rebooted. All three look like “the device is flaky” when the real problem is your poll rate.

Rough RS-485 bus load estimate

You don’t need lab equipment to sanity-check your bus — a back-of-the-envelope estimate is enough to see if you’re asking the impossible. The rough math:

• Every serial byte costs 10 bits on the wire (8 data bits + start + stop, at 8N1).
• A Modbus RTU request for N registers is about 8 bytes; the response is about 5 + 2×N bytes.
• Wire time per poll ≈ (request bytes + response bytes) × 10 ÷ baud rate, plus the slave’s response time, plus the mandatory 3.5-character silent gap between frames.
• Multiply by your number of slaves to get the minimum time for one full scan cycle.

Example of the shape of the problem (do your own numbers for your setup): five slaves, 20 registers each, at 9600 baud, with each slave taking 100 ms to respond — the wire time alone is well over half a second per cycle, and with response times it’s closer to a full second. If your scan is set (or defaults) to something much faster than that, you’re permanently behind: requests pile up, collide, and time out. Rule of thumb: your scan interval must be longer than one full cycle through every slave, with margin.

Practical fixes in QModMaster

• Turn Scan mode off and poll manually while debugging — confirm the device is healthy before blaming the poll rate.
• Read fewer registers per poll. Two small reads that succeed beat one big read that times out. Split a 50-register block into chunks.
• Poll fewer slaves per cycle, or poll the slow device less often than the fast ones (stagger them).
• Slow the baud rate down if the line is long or noisy — counterintuitively, a slower, clean bus beats a fast, error-prone one.
• Check the hardware first. Timeouts that look like “slow device” are often a marginal RS-485 adapter. Rule out the cable before redesigning your poll strategy — see our USB-to-RS485 adapter notes.
• For a permanent multi-client setup, put a Modbus proxy between QModMaster and the bus (covered in the companion theory page).

Your Modbus TCP gateway answers on its IP address, QModMaster reads slave 1 just fine, but slaves 2, 3 and 4 all time out. Or worse — every slave you query returns slave 1’s data. This is the single most common gateway problem in the Modbus world, and it comes down to one byte in the TCP frame: the Unit ID.

Real-world evidence this is a live problem: a SourceForge review of QModMaster states it plainly — “TCP messages do not include the slave address, so this cannot work with modbus TCP gateway that had several slaves attached.” The review is half right: Modbus TCP frames do carry a slave address, but in a different place than RTU users expect. Once you know where it lives, the fix is usually a one-field change in QModMaster.

Where the slave address hides in Modbus TCP: the MBAP Unit ID

In Modbus RTU, the slave address is the first byte of the serial frame — every device on the RS-485 bus sees every frame and only the addressed one answers. In Modbus TCP, the serial frame is wrapped in a 7-byte MBAP header (Modbus Application Protocol header):

Transaction ID (2 bytes) | Protocol ID (2 bytes) | Length (2 bytes) | Unit ID (1 byte)

That final Unit ID byte is the Modbus TCP equivalent of the RTU slave address. A gateway sitting between your Ethernet network and the RS-485 bus reads the Unit ID from each incoming TCP request, rebuilds an RTU frame addressed to that slave number, waits for the reply, wraps it back in an MBAP header, and sends it to you. The whole multi-slave trick lives or dies on this one byte.

Setting the Slave ID in QModMaster (TCP mode)

QModMaster’s TCP connection mode has a Slave ID field in the connection dialog. In TCP mode this field is written into the MBAP Unit ID byte — it is the exact same setting RTU users know, just transported differently. To poll several slaves through one gateway:

• Connect QModMaster in TCP mode to the gateway’s IP address and port (usually 502).
• Set Slave ID = 1 and read your registers. Confirm the first slave responds.
• Duplicate your register list (or your QModMaster session setup) with Slave ID = 2, 3, 4… — one Unit ID per physical slave on the RS-485 side.
• Make sure the Unit IDs match the slave addresses configured on the devices themselves (DIP switches, device menus, or vendor software), not the order you plugged them in.

If slave 1 reads and the others time out even though you’re sure the Unit IDs are right, the gateway — not QModMaster — is almost always the culprit. Read on.

The common pitfall: gateways that only forward Unit ID 1

Not all gateways forward the Unit ID faithfully. The most reported failure mode:

• The gateway ignores the MBAP Unit ID and always talks to the RTU slave wired as address 1 (or to a fixed, pre-configured address). Result: Unit ID 2/3/4 time out, or — sneakier — every Unit ID returns slave 1’s data.
• The gateway has a “unit ID mapping” table in its web interface that must be filled in: which incoming TCP Unit ID maps to which RTU slave address. If the table is empty or only has row 1, the other slaves are unreachable no matter what QModMaster sends.
• The gateway is in transparent/bridge mode instead of protocol-conversion mode. In transparent mode the gateway is a dumb pipe — there is no MBAP parsing at all. (See our Waveshare gateway modes guide for how the two modes differ and what QModMaster supports.)

Fix order: (1) open the gateway’s web UI and look for “Modbus gateway”, “unit mapping”, “slave mapping” or “protocol conversion” settings; (2) confirm the gateway is in Modbus TCP ↔ RTU conversion mode (not transparent); (3) verify each Unit ID maps to the correct RTU slave address; (4) re-test from QModMaster with Slave ID set per device. Also confirm all slaves share the same serial settings (baud rate, parity, data bits) — the gateway talks to every one of them on the same RS-485 line.

Quick troubleshooting checklist

• Ping the gateway IP — is the Ethernet side even reachable?
• Slave ID 1 reads OK? Then QModMaster’s TCP setup is fine; the problem is Unit ID forwarding.
• All Unit IDs return the same data? The gateway is pinning everything to one RTU address.
• Some slaves read, others time out? Check DIP-switch addresses on the silent devices, and the gateway’s mapping table.
• Nothing reads? Verify the gateway’s serial settings match the slaves (one mismatched baud rate silences the whole bus), and check A/B wiring.

You read a floating-point value from your device and get 2.40e-41 instead of 123.0. Or a negative number with 33 digits. The connection is fine, the registers respond — the value is just garbage. Nine times out of ten, this is a byte order problem, and it takes two minutes to diagnose once you know where to look.

Modbus registers are 16 bits wide, but a 32-bit float needs two registers. The Modbus specification never dictated which register comes first — so device vendors picked all four possible orders. Pick the wrong one in your software and the same raw bytes decode to a completely different number.

The Four Byte Orders, With Real Numbers

Take a concrete example. A device holds 123.0 in two consecutive registers. In hex, the raw register contents are 0x42F6 and 0x0000 (four bytes: 42 F6 00 00). Watch what each byte order makes of the identical raw bytes:

The values in the “garbage” rows are computed, not guessed — feed the byte sequences above into any IEEE-754 decoder and you will get exactly these numbers. The pattern is worth memorizing: a word-swapped device (CDAB/DCBA) gives you absurdly tiny values near zero, while a byte-swapped one (BADC) tends to give absurdly large ones. That signature tells you which direction to swap.

What the Vendors Say: The “Swapped Float” Rule

This is not a fringe problem — major vendors document it. Schneider Electric’s official FAQ on reading swapped floating-point values states the rule plainly: swapped floating-point registers are read the same as regular floating-point registers, except the most significant word and least significant word are switched. In their worked example, a device holding the known value 230.1 was read with the registers in the order they appeared, produced the wrong result, and swapping Register 1 and Register 2 gave the correct floating-point value (Schneider Electric FAQ FA401500).

That is the CDAB case in our table: the register order is flipped while the bytes inside each register stay put. It is the single most common variant you will meet in the field.

Diagnose It in QModMaster

QModMaster (free, open-source LGPLv3 Modbus master simulator from the upstream project) gives you everything you need to confirm a byte-order problem without leaving the app:

Step 1: Look at the Raw Hex

Use the View menu to switch the register display between Hex, Int, and Float. In Hex view you see the actual bytes the device sent — no interpretation. If Hex shows 42F6 0000 but Float shows garbage, your connection is healthy and the interpretation is wrong. That is a byte-order problem, full stop.

Step 2: The Register-Swap Test

Suspect CDAB/word-swap? Mentally (or on paper) exchange the two registers and re-read:

• Registers read as [0x0000, 0x42F6] decode to garbage → swap to [0x42F6, 0x0000] → 123.0. Word-swap confirmed.
• If swapping does not fix it, the device may use BADC or DCBA — try those permutations against the raw hex from Step 1.

Many Modbus client libraries and SCADA packages let you set the float byte order per device once you know it. QModMaster itself displays values with its built-in interpretation, so the practical workflow is: read raw hex in QModMaster, confirm the correct permutation here, then configure the matching byte order in your production software.

The Two Usual Suspects: Wrong Address or Wrong Byte Order?

When a reading is wrong, there are exactly two common causes — and they look different:

• Wrong address / off-by-one: you get a plausible but wrong value (e.g. 124.7 instead of 123.0, or a value that changes when it should not). See our register address offset guide.
• Wrong byte order: you get absurd values — near-zero like 2.4e-41, or astronomically large like −9.8e+32. That is this page.

Check the address first (it is the cheaper mistake to rule out), then the byte order. Together they cover nearly every “my Modbus reading is wrong” support ticket.

Related Guides

• Modbus Register Address Offset Guide
• Read Holding Registers, Step by Step
• QModMaster User Manual