Yes, it’s the GPIO timing, and the missing bias doesn’t help. I had almost the same line on six pump controllers.

Driving DE/RE from Python is too slow and too jittery. After the write, your code switches back to receive only when Linux gets round to it. At 38400 a slave can start answering within a couple of milliseconds, so the start of the reply is lost or you’re still driving the line while the slave talks. Fix it in hardware: a USB-RS485 adapter with automatic direction control (FTDI-based ones are good), or let the kernel do it on the UART with rs485 mode. The adapter is the five-minute fix.

Then the line itself:

• Bias: one pull-up on A and one pull-down on B, only once on the bus (560 R to 1 k is typical), so the idle line is defined.
• Common ground wire between all nodes.
• Give pymodbus a sane timeout and a pause between slaves, some old firmware needs a breather.

client = ModbusSerialClient(port="/dev/ttyUSB0", baudrate=38400, parity="N",
                            stopbits=1, bytesize=8, timeout=0.3, retries=2)
for unit in range(11, 17):
    rr = client.read_holding_registers(0, count=4, slave=unit)
    time.sleep(0.02)

Then report all six as children of the Pi on v1/gw/telemetry, keyed by name («mixer-11» and so on). Each one gets its own device in Hermetry, and you can put a Device offline rule on their profile.

CRC order is right, Modbus sends the low byte first and 0x71 0xCB is correct for that frame. The problem is print.

Serial.print(0x01) sends the text «1», the byte 0x31. Serial.print(0x71) sends «113», three bytes. So the meter receives something like «1400021137…» in ASCII, which isn’t a Modbus frame at all, and it stays quiet. Serial.write sends the raw byte, which is what Modbus RTU needs.

Second problem: you drop DE the moment the loop ends, but at 2400 baud the bytes are still going out of the UART for another ~30 ms. Switching to receive cuts the end of the frame. Wait for the transmit to finish:

digitalWrite(2, HIGH);
Serial.write(frame, sizeof frame);
Serial.flush();            // returns when the last byte has left the UART
digitalWrite(2, LOW);

The answer is 9 bytes: address, 0x04, byte count 0x04, four data bytes, CRC. The SDM120 voltage is a 32-bit float, big-endian, high word first:

union { uint32_t u; float f; } v;
v.u = ((uint32_t)r[3] << 24) | ((uint32_t)r[4] << 16) | (r[5] << 8) | r[6];
// v.f is the voltage

Since the Nano’s only hardware UART is now on the RS485 side, debug through a SoftwareSerial pin or a blink, not the USB serial monitor. When you send it on, send {"voltage": 231.4} as a number so the chart works.