I’m a facility manager, not an engineer, but we had exactly this with meters in our hotel’s annex, and our electrician explained it to me. Two buildings with separate supplies don’t sit at the same ground potential. Your RS485 signal is measured against the gateway’s ground, and the MAX485 only tolerates the bus being about -7 to +12 V away from its own ground. When something big switches in building B, the difference jumps past that and the chip dies. Shield grounded at both ends also lets current flow along the shield between the two grounds, which makes it worse. He measured several volts AC between the two grounds with a meter.

What fixed ours, per the electrician:

• An isolated RS485 transceiver on the gateway (ADM2587E or ISO3082 type, or a ready isolated module). The bus side floats with the bus, the Pi side stays on the Pi’s ground.
• Shield grounded at one end only, and a third wire as signal reference between the transceivers.
• Surge protection (TVS diodes made for RS485, like the SM712) at the building entry, which also covers Michael’s lightning point.

Since the change, two years without a dead chip.

And for «nobody notices»: our gateway script sends v1/gw/disconnect for a meter that stops answering three polls in a row, so the child goes offline in Hermetry, and the profile of the meters has an offline alarm. We get a message within 15 minutes.

I’m not an engineer, but I fought this exact error for a week with a Pi 3 and a heat meter in our hotel’s boiler room, and it was two things together.

On a Pi 3 the proper UART (PL011) is wired to Bluetooth and the GPIO pins get the mini UART, ttyS0. The mini UART’s baud rate follows the core clock, so when the CPU changes speed the 9600 isn’t 9600 any more. The mini UART also has no parity, and your meter is on 8E1. So the meter hears your request, answers, and the Pi can’t make sense of the reply.

Second one got me: the serial login console. If cmdline.txt still has console=serial0,115200, the Pi writes its login prompt onto the RS-485 bus at boot and keeps a getty on the port.

What fixed it for me:

# /boot/firmware/config.txt  (or /boot/config.txt on older images)
enable_uart=1
dtoverlay=disable-bt
sudo systemctl disable hciuart
# raspi-config: Interface Options > Serial Port
#   login shell over serial: No, serial port hardware: Yes

Reboot, then use /dev/serial0 (it points to ttyAMA0 after this) in pymodbus. Also check whether your meter counts registers from 0 or 1. Schneider manuals list them 1-based, so 3028 in the book is 3027 on the wire, and you had that right.