ESP32 + 7 PZEM-004T v4 on RS485 bus causes crashes, 6 devices work fine

Hi everyone,

I'm working on a power monitoring project using an ESP32 and multiple PZEM-004T v4 modules connected on the same RS485 bus.

The system works reliably with up to 6 PZEM devices. However, when I connect the 7th PZEM, the system eventually becomes unresponsive and then resets automatically.

Configuration:

  • ESP32 (ESP-IDF)
  • UART2 for RS485 communication
  • 9600 baud
  • 7 PZEM-004T v4 modules
  • Each PZEM has a unique Modbus address
  • Polling devices sequentially
  • Each TX line is connected through a diode

What I've observed:

  • 1–6 PZEMs: stable operation
  • Adding the 7th PZEM immediately causes instability
  • Removing the 7th PZEM restores normal operation

Has anyone successfully used 7 or more PZEM-004T v4 modules on a single ESP32? Could this be related to RS485 bus loading, termination/biasing, Modbus timing, UART buffering, or some limitation in handling multiple Modbus devices? I'm not using a PZEM library; I'm sending Modbus requests directly and parsing the raw hex responses myself.

Any suggestions or similar experiences would be greatly appreciated.

Thank you.
I (826) wifi:pm start, type: 1 I (826) wifi:dp: 1, bi: 102400, li: 3, scale listen interval from 307200 us to 307200 us I (866) wifi:idx:0 (ifx:0, 30:fc:68:2b:ff:d6), tid:0, ssn:0, winSize:64 I (886) wifi:AP's beacon interval = 102400 us, DTIM period = 1 ets Jul 29 2019 12:21:46 rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:6384 load:0x40078000,len:15916 load:0x40080400,len:3920 --- 0x40080400: _invalid_pc_placeholder at /home/phong/esp/esp-idf/components/xtensa/xtensa_vectors.S:2235 entry 0x40080644 --- 0x40080644: call_start_cpu0 at /home/phong/esp/esp-idf/components/bootloader/subproject/main/bootloader_start.c:25 I (54) boot: ESP-IDF v5.5.2-1-gd4371b6406-dirty 2nd stage bootloader I (54) boot: compile time Jun 1 2026 10:44:32 I (54) boot: Multicore bootloader I (58) boot: chip revision: v3.1 I (61) boot.esp32: SPI Speed : 40MHz

Welcome to the community @bui-nguyen-phong !

The watchdog reset means comms break when you add device 7 and your firmware blocks instead of logging a bad read.

Prime suspects: the TX diodes (a TTL multidrop hack that doesn't scale) or, on a real RS485 bus, weak fail-safe biasing/termination.

Fix the bus, and harden the poll loop so one bad device can't reboot the system.

Quick test: with the 7th connected, scope the A-B idle voltage and watch the bus during the failing poll. Idle differential under ~200mV, or visible framing errors, points straight at biasing.