The request leaves Python through /dev/tty.usbserial-1130, crosses the USB-to-RS485 converter, reaches a selected meter, and returns two 16-bit registers. The returned words decode into plausible FLOAT32 values. That puts device selection and register mapping ahead of float conversion in the diagnostic order.
Which approaches fit the mismatch?
For the running-hour read, the meter displays 1695 while registers [17619, 10624]For Total Net kWh, the display shows 642720 while[18716, 53600] decodes to 642326.0, a difference of 394. Another meter reverses the running-hour error and returns a value 21 hours above its display. A fixed scale-factor or rounding error does not explain errors that change direction between devices.
| Approach | What it would produce | Fit to the observations | Priority |
|---|---|---|---|
Change FLOAT32 decoding |
Large or structurally repeatable changes when byte or word order is wrong | The current words already produce realistic engineering values close to the displays | Low until identity and mapping pass |
| Apply a scale factor | A proportional error across meters | One meter reads low and another reads high; the values already have the expected magnitude | Low |
| Correct the register offset | A different adjacent pair of words |
30083 - 30000 assumes a particular map convention |
High |
| Poll the configured device address | Values belonging to the intended physical meter | The request uses slave=255; device-specific addressing must be verified |
Highest |
| Match display and Modbus counter definitions | Persistent differences despite a verified path | Possible if the display and register represent different accumulators or reset domains | After path checks |
Where can the data path stop being trustworthy?
Layer one comes first. A valid Python return proves that bytes arrived, but it does not by itself prove which meter drove the bus or whether more than one transmitter responded. Test with one meter connected to the converter. Check RS485 polarity, the reference conductor where required by the installation, and the termination and bias arrangement. Inspect the receive path for intermittent framing errors or changing raw words.
| Path field | Configured value | Check |
|---|---|---|
| Serial port | /dev/tty.usbserial-1130 |
Confirm this operating-system device belongs to the intended converter |
| Baud rate | 9600 |
Match the meter communication setting |
| Parity | E |
Match the meter communication setting |
| Data bits | 8 |
Match the meter communication setting |
| Stop bits | 1 |
Match the meter communication setting |
| Client timeout |
3 seconds |
Treat this as a client wait limit, not proof of correct device selection |
| Requested device | slave=255 |
Read the configured address from the meter and use that exact value |
Repeat the same request several times while the displayed quantity is stable. Identical raw words indicate a repeatable reply. Alternating or corrupted words point back toward wiring, contention, serial settings, or converter behavior before any decoding changes are justified.
Is the register reference off by one?
The expression 30083 - 30000 produces address 83. That is correct only if the meter documentation defines reference 30000 as protocol offset zero. If its table starts with reference 30001 at offset zero, reference 30083 maps to offset 82.
| Document convention | Offset formula | Offset for 30083
|
Offset for 30059
|
|---|---|---|---|
30000 means offset zero |
Reference minus 30000
|
83 |
59 |
30001 means offset zero |
Reference minus 30001
|
82 |
58 |
Resolve the convention from the MFM384 register table rather than choosing the candidate that looks closest to the display. Confirm that Running Hour occupies two consecutive input registers beginning at the stated reference and perform the same check for Total Net kWh. Reading an adjacent pair may still produce a legal float, so plausibility alone cannot validate the address.
Why is FLOAT32 not the first correction?
The running-hour words are 17619 and 10624, or and . In their present order they decode to the reported 1689.296875. The Total Net kWh words 18716 and 53600, or and , likewise decode to 642326.0. These coherent values show that the conversion is processing a viable two-register float.
Wrong byte or word order commonly changes the exponent and magnitude, producing an implausible value rather than a nearby counter reading. Test alternate ordering only after confirming the selected meter, register type, starting offset, data type, and documented word order. Do not introduce an unexplained multiplier merely to force one reading to equal one display; it will not account for the opposite-signed error on another meter.
What procedure isolates the fault?
- Connect only one MFM384 to the RS485 converter. Record its displayed Running Hour and Total Net kWh values at the same instant as the poll.
- Read the communication configuration from that meter. Replace
slave=255with its configured device address. - Retain the serial settings
9600, even parity, eight data bits, and one stop bit only when they match the meter. - Check the register table's zero-based convention. For Running Hour, test the documented interpretation of
30083; for Total Net kWh, do the same for30059. - Read exactly two input registers from the confirmed starting offset. Log the requested device address, starting offset, two decimal words, two hexadecimal words, decoded float, and display snapshot.
- Keep the present word order when it matches the documented format. If the documented word order differs, change only that dimension and log the resulting raw-to-float mapping.
- Reconnect additional meters one at a time. Give each transaction the address configured in the physical meter and repeat the same capture.
How is the correction verified?
Verification requires identity, repeatability, and movement—not merely a close number. With one meter connected, poll the confirmed address and offset repeatedly. The raw words must remain stable while the displayed counter is stable. Then wait for the underlying quantity to change and confirm that the display and Modbus value move in the same direction by a compatible amount.
For running hours, compare the fractional Modbus value with the display's presentation resolution; rounding can explain less than one displayed unit, but it cannot explain the observed 5.703125-hour or 21-hour differences. For Total Net kWh, compare like-for-like counter labels and reset domains. If identity and mapping are correct but the difference persists, read the meter documentation for whether the displayed total and the mapped Total Net kWh register use the same accumulator.
FAQ
Why does MFM384 Running Hour read lower than the display?
First verify the meter selected by slave=255 and the offset derived from 30083. The observed 5.703125-hour difference is too large to classify as display rounding.
Why does another MFM384 read 21 hours too high?
An error that reverses direction between meters points toward device identity, register mapping, or different counter states rather than one universal scale factor. Isolate each meter and poll its configured address.
Why can an incorrect register address still return a believable float?
Any two adjacent 16-bit words can form a legal FLOAT32 bit pattern. Validate the starting offset from the register table instead of accepting a value because its magnitude looks reasonable.
Why should I keep the current FLOAT32 word order initially?
The words [17619, 10624] and [18716, 53600] already decode into coherent values of 1689.296875 and 642326.0. Check device selection and offset conventions before changing byte or word order.
How do I verify the MFM384 register mismatch is fixed?
Poll one addressed meter, record the raw two-word reply beside a simultaneous display reading, repeat while stable, and perform the final check after the counter advances: both values must move together.