I ran Z-Wave in a council building pilot, so here’s how I’d split it.

“Mandatory” is about certification: since April 2017 every new device that gets Z-Wave certified has to support S2, and controllers too. Your stick does. That doesn’t force you to include every node with S2.

The classes are S2 Access Control (locks, garage doors, anything that opens a door), S2 Authenticated (needs the PIN, which is the first 5 digits of the DSK on the device label or QR code) and S2 Unauthenticated (encrypted, but no proof it’s the device you think).

• Door locks: S2 Access Control, no discussion. Most locks won’t even accept lock/unlock commands without secure inclusion.
• Door sensors: if they only support S0 or nothing, that’s what they get. S0 is chatty (three frames per command), so I’d rather run old sensors non-secure than S0, unless they’re security-relevant.
• Plugs: S2 Authenticated. S2 adds a few bytes per frame, nothing like S0’s overhead. The traffic problem is the reporting interval, set the plugs to report on a 5 % change or every 60 s instead of every few seconds.

Keep the PIN sheet with the labels, you need it again if you ever re-include.

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.