Access more than 4 PZEM-004T V3 at the same time,The data will not be read

[3038922]

The problem

Access more than 4 PZEM-004T V3 at the same time,The data will not be read. I set different addresses for each pzem. No more than 4 pzem, everything is normal,Once more than 4, the data will not be read at all.

Which version of ESPHome has the issue?

ESPHome 2021.8.0

What type of installation are you using?

Docker

Which version of Home Assistant has the issue?

2021.9

What platform are you using?

ESP32 and ESP8266

Board

nodemcu

Component causing the issue

pzem-004T V3

Example YAML snippet

substitutions:
  device_name: energy-centerpcroom

esphome:
  name: ${device_name}
  platform: ESP8266
  board: nodemcuv2

logger:
  baud_rate: 0 # (UART logging interferes with pzem)
  level: DEBUG

# Enable Home Assistant API
api:
  password: "xx"
ota:
  password: "xx"

web_server:
  port: 80

wifi:
  ssid: "xx"
  password: "xx"
  fast_connect: true
  use_address: 10.253.12.253
  manual_ip:
    static_ip: 10.253.12.253
    gateway: 10.253.12.1
    subnet: 255.255.255.0
    dns1: 192.168.250.3
  ap:
    ssid: "esp32-centerpcroom"
    password: "8888888888"

captive_portal:

uart:
  - tx_pin: D1
    rx_pin: D2
    baud_rate: 9600
    stop_bits: 1

modbus:

binary_sensor:
  - platform: status
    name: "${device_name} Status"

sensor:
  - platform: pzemac
    id: pzemac1
    energy:
      name: "energy_ac1"
      id: "energy_ac1"
      filters:
        - multiply: 0.002
      unit_of_measurement: kWh
      accuracy_decimals: 1
    current:
      name: "current_ac1"
      id: "current_ac1"
      accuracy_decimals: 1
    voltage:
      name: "voltage_ac1"
      id: "voltage_ac1"
      filters:
        - multiply: 1
      accuracy_decimals: 1
    frequency:
      name: "frequency_ac1"
      id: "frequency_ac1"
      accuracy_decimals: 1
    power_factor:
      name: "factor_ac1"
      id: "factor_ac1"
      accuracy_decimals: 1
    power:
      name: "power_ac1"
      id: "power_ac1"
      filters:
        - multiply: 1
      accuracy_decimals: 0
    update_interval: never
    address: 1

  - platform: pzemac
    id: pzemac2
    energy:
      name: "energy_ac2"
      id: "energy_ac2"
      filters:
        - multiply: 0.002
      unit_of_measurement: kWh
      accuracy_decimals: 1
    current:
      name: "current_ac2"
      id: "current_ac2"
      accuracy_decimals: 1
    voltage:
      name: "voltage_ac2"
      id: "voltage_ac2"
      filters:
        - multiply: 1
      accuracy_decimals: 1
    frequency:
      name: "frequency_ac2"
      id: "frequency_ac2"
      accuracy_decimals: 1
    power_factor:
      name: "factor_ac2"
      id: "factor_ac2"
      accuracy_decimals: 1
    power:
      name: "power_ac2"
      id: "power_ac2"
      filters:
        - multiply: 1
      accuracy_decimals: 0
    update_interval: never
    address: 2

  - platform: pzemac
    id: pzemac3
    energy:
      name: "energy_ac3"
      id: "energy_ac3"
      filters:
        - multiply: 0.002
      unit_of_measurement: kWh
      accuracy_decimals: 1
    current:
      name: "current_ac3"
      id: "current_ac3"
      accuracy_decimals: 1
    voltage:
      name: "voltage_ac3"
      id: "voltage_ac3"
      filters:
        - multiply: 1
      accuracy_decimals: 1
    frequency:
      name: "frequency_ac3"
      id: "frequency_ac3"
      accuracy_decimals: 1
    power_factor:
      name: "factor_ac3"
      id: "factor_ac3"
      accuracy_decimals: 1
    power:
      name: "power_ac3"
      id: "power_ac3"
      filters:
        - multiply: 1
      accuracy_decimals: 0
    update_interval: never
    address: 3

  - platform: total_daily_energy
    name: "energy_ac1_daily"
    power_id: power_ac1
    id: energy_ac1_daily
    unit_of_measurement: kWh
    accuracy_decimals: 1
    icon: mdi:counter
    filters:
      - multiply: 0.001

  - platform: total_daily_energy
    name: "energy_ac2_daily"
    power_id: power_ac2
    id: energy_ac2_daily
    unit_of_measurement: kWh
    accuracy_decimals: 1
    icon: mdi:counter
    filters:
      - multiply: 0.001

  - platform: total_daily_energy
    name: "energy_ac3_daily"
    power_id: power_ac3
    id: energy_ac3_daily
    unit_of_measurement: kWh
    accuracy_decimals: 1
    icon: mdi:counter
    filters:
      - multiply: 0.001

  - platform: template
    name: "total_power"
    id: "total_power"
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    accuracy_decimals: 1
    lambda: |-
      return id(power_ac1).state + id(power_ac2).state + id(power_ac3).state ;

  - platform: template
    name: "energy_total_daily"
    id: "energy_total_daily"
    icon: mdi:counter
    device_class: energy
    state_class: measurement
    unit_of_measurement: kWh
    accuracy_decimals: 1
    lambda: |-
      return id(energy_ac1_daily).state + id(energy_ac2_daily).state + id(energy_ac3_daily).state ;

time:
  - platform: homeassistant
    id: homeassistant_time

switch:
  - platform: restart
    name: "${device_name}_Restart"

  - platform: uart
    name: "${device_name}_Reset"
    data: [0x01, 0x42, 0x80, 0x11]

interval:
  - interval: 5s
    then:
      - delay: 150ms
      - lambda: "id(pzemac1).update();"
      - delay: 150ms
      - lambda: "id(pzemac2).update();"
      - delay: 150ms
      - lambda: "id(pzemac3).update();"

### Anything in the logs that might be useful for us?

_No response_

### Additional information

![c1504ab8e85a0d774dc5a5573608ba6](https://user-images.githubusercontent.com/33926386/138834952-2b533466-9f6f-4905-a159-33397f29c7bc.jpg)

[randybb]

I don't have more than 3, but no issue when using 20s update interval. Is 150 ms between readings enough (9600 baud ~ 1,042 sec/byte). Btw, how do you have them connected, because on both pictures I see only two cables (on the AC side are only CT's which this should be enough for testing).

[3038922]

https://github.com/mandulaj/PZEM-004T-v30/issues/33#issuecomment-677811222%60

[3038922]

I don't think it's the current problem. I've changed to 5v2a power supply. I can load more

[3038922]

[10:05:59][W][modbus:096]: Modbus CRC Check failed! A481!=7E62
[10:05:59][W][modbus:096]: Modbus CRC Check failed! 74E8!=3C8C
[10:05:59][D][pzemac:049]: PZEM AC: V=223.4 V, I=0.000 A, P=0.0 W, E=1.0 Wh, F=50.0 Hz, PF=0.00
[10:05:59][D][sensor:113]: 'voltage_ac5': Sending state 223.39999 V with 1 decimals of accuracy
[10:05:59][D][sensor:113]: 'current_ac5': Sending state 0.00000 A with 1 decimals of accuracy
[10:05:59][D][sensor:113]: 'power_ac5': Sending state 0.00000 W with 0 decimals of accuracy
[10:05:59][D][sensor:113]: 'energy_ac5_daily': Sending state 0.00000 kWh with 1 decimals of accuracy
[10:05:59][D][sensor:113]: 'energy_ac5': Sending state 0.00200 kWh with 1 decimals of accuracy
[10:05:59][D][sensor:113]: 'frequency_ac5': Sending state 50.00000 Hz with 1 decimals of accuracy
[10:05:59][D][sensor:113]: 'factor_ac5': Sending state 0.00000  with 1 decimals of accuracy
[10:06:02][D][esp32.preferences:113]: Saving preferences to flash...
[10:06:08][D][sensor:113]: 'energy_total_daily': Sending state 0.00000 kWh with 1 decimals of accuracy
[10:06:08][D][pzemac:049]: PZEM AC: V=223.3 V, I=0.000 A, P=0.0 W, E=2.0 Wh, F=50.0 Hz, PF=0.00
[10:06:08][D][sensor:113]: 'voltage_ac2': Sending state 223.30000 V with 1 decimals of accuracy
[10:06:08][D][sensor:113]: 'current_ac2': Sending state 0.00000 A with 1 decimals of accuracy
[10:06:08][D][sensor:113]: 'power_ac2': Sending state 0.00000 W with 0 decimals of accuracy
[10:06:09][D][sensor:113]: 'energy_ac2_daily': Sending state 0.00000 kWh with 1 decimals of accuracy
[10:06:09][D][sensor:113]: 'energy_ac2': Sending state 0.00400 kWh with 1 decimals of accuracy
[10:06:09][D][sensor:113]: 'frequency_ac2': Sending state 50.00000 Hz with 1 decimals of accuracy
[10:06:09][D][sensor:113]: 'factor_ac2': Sending state 0.00000  with 1 decimals of accuracy
[10:06:09][W][modbus:096]: Modbus CRC Check failed! 6C11!=23E8
[10:06:09][W][modbus:096]: Modbus CRC Check failed! D0!=8020

[randybb]

Actually, mine are running on 3.3V (with replaced resistors) and are connected via diodes...but this is irrelevant :)

For the CRC check - just add _stopbits:

modbus:
  uart_id: uart1

uart:
  - id: uart1
    rx_pin: 23
    tx_pin: 33
    baud_rate: 9600
    stop_bits: 2

[barrenechea]

I don't think it's the current problem. I've changed to 5v2a power supply. I can load more

It's not about the amperage that your power supply can deliver, but the amps that you can deliver though GPIO lanes (20mA MAX!, no matter which power supply).

[3038922]

I don't think it's the current problem. I've changed to 5v2a power supply. I can load more

It's not about the amperage that your power supply can deliver, but the amps that you can deliver though GPIO lanes (20mA MAX!, no matter which power supply).

How can I solve this problem?

[Strixx76]

I have the same problem. I am only able to have two PZEM004T V3 parallel.

I have programmed three of the to address 1, 2 and 3. When all three are connected only 1 and 2 are working. But if I remove any one of the three, the other two works. I have tried with both pzemac and modbus_controller and the result is the same.

When all three are connected I cans see on the RX/TX-led of the pzem that all are asked for info and they are responding.

No 3.3V resistor hack or diodes used. All connected directly to hardware UART och an Wemos D1 mini which is 5V tolerant.

[randybb]

I have 3 connected to one bus and no issues.

[Strixx76]

Got it working now by switch from hardware serial to software serial. When I switched from using RX- and TX-pin on the ESP to using D5 and D6 it started working. I can't explain why. (And yes I did disable serial logging).

When using the RX and TX pin the logs showed that the request was sent to each of the pzem but 3'rd never responded. If I removed the first or second the ESP registered a response from the third. I suspected a current problem, but then why did I received the response from the first and second pzem? I could see on the led that all three responded.

[pesh000]

Hello everyone, what is the full code when use 3 of the sensors?

[kammerjaeger]

My setup works without any modification, directly with 3.3V from the esp32. The sensors are connected parallel to each other directly to the pins of the ESP32. (5V worked too but then some current is always going from the leds to the esp when the pin is high. As far as I saw the ESP is 5V IO compatible so there should be no problem.) I tried to spread out the sensors on different uarts but I cannot get the third uart to work (on a ESP32). Maybe somebody has an example for that?

uart:
  - id: uart1
    tx_pin: GPIO17
    rx_pin: GPIO16
    baud_rate: 9600
    data_bits: 8
    stop_bits: 1
    parity: NONE

modbus:
  - id: mod_bus_pzem1
    send_wait_time: 250ms
    uart_id: uart1

button:
  - platform: template
    name: Reset counter
    id: reset_button

    # Optional variables:
    icon: "mdi:emoticon-outline"
    on_press:
      - pzemac.reset_energy: pzemac_1
      - delay: 500ms
      - pzemac.reset_energy: pzemac_2
      - delay: 500ms
      - pzemac.reset_energy: pzemac_3
      - delay: 500ms
      - pzemac.reset_energy: pzemac_4

sensor:
  - platform: pzemac
    id: pzemac_1
    current:
      name: "Phase 1 Current"
    voltage:
      name: "Phase 1 Voltage"
    energy:
      name: "Phase 1 Energy"
    power:
      name: "Phase 1 Power"
    frequency:
      name: "Phase 1 Frequency"
    power_factor:
      name: "Phase 1 Power Factor"
    update_interval: 60s
    address: 0x10
    modbus_id: mod_bus_pzem1

  - platform: pzemac
    id: pzemac_2
    current:
      name: "Phase 2 Current"
    voltage:
      name: "Phase 2 Voltage"
    energy:
      name: "Phase 2 Energy"
    power:
      name: "Phase 2 Power"
    frequency:
      name: "Phase 2 Frequency"
    power_factor:
      name: "Phase 2 Power Factor"
    update_interval: 60s
    address: 0x11
    modbus_id: mod_bus_pzem1

  - platform: pzemac
    id: pzemac_3
    current:
      name: "Stove 2 Current"
    voltage:
      name: "Stove 2 Voltage"
    energy:
      name: "Stove 2 Energy"
    power:
      name: "Stove 2 Power"
    #frequency:
      #name: "Stove 2 Frequency"
    power_factor:
      name: "Stove 2 Power Factor"
    update_interval: 60s
    address: 0x12
    modbus_id: mod_bus_pzem1

  - platform: pzemac
    id: pzemac_4
    current:
      name: "Stove Current"
    voltage:
      name: "Stove Voltage"
    energy:
      name: "Stove Energy"
    power:
      name: "Stove Power"
    #frequency:
      #name: "Stove Frequency"
    power_factor:
      name: "Stove Power Factor"
    update_interval: 60s
    address: 0x13
    modbus_id: mod_bus_pzem1

[aerodolphin]

Got it working now by switch from hardware serial to software serial. When I switched from using RX- and TX-pin on the ESP to using D5 and D6 it started working. I can't explain why. (And yes I did disable serial logging).

When using the RX and TX pin the logs showed that the request was sent to each of the pzem but 3'rd never responded. If I removed the first or second the ESP registered a response from the third. I suspected a current problem, but then why did I received the response from the first and second pzem? I could see on the led that all three responded.

How many PZEM modules you were able to connect stable?

[kkeonline]

I don't think it's the current problem. I've changed to 5v2a power supply. I can load more

I have 6 pzem and 1 of them always error, remove any 1 of 6 pzem, another 5 will work fine without any issue, so this is the i/o current problem (the i/o pin have limit output current at 25mA, no matter what power supply you use)

[atsawin]

I just figure out how to do this. Here are 3 buses with 6 meters each for total of 18 meters connect to single ESP8266.

There are 2 problems for multiple PZEM-004T.

1. Hardware. We have to use multi-drop circuit like this:

2. Software. We can not use update_interval command. For many meters, the timing will likely to be collided with each other. The timing is random for each boot. For unlucky boot, the timing will collided like this.

Look at red rectangle (this is from 2 buses with 6 meters each)

Zoom for red rectangle. It send read command for first meter but not wait long enough. While first meter is answering, it send read command to second meter and will fail to get answer from first meter. Although it is full duplex bus, I think software won't support this.

To fix the software problem, we have to set update_interval to never and use interval like the the source code at the top of this report.

Finally, here are excerpt of my config: Sensor pzemac_01 - pzemac_06 connect to modbus_1 Sensor pzemac_07 - pzemac_12 connect to modbus_2 Sensor pzemac_13 - pzemac_18 connect to modbus_3

uart:
  - rx_pin: D1
    tx_pin: D0
    baud_rate: 9600
    id: uart_1
  - rx_pin: D3
    tx_pin: D2
    baud_rate: 9600
    id: uart_2
  - rx_pin: D6
    tx_pin: D5
    baud_rate: 9600
    id: uart_3

modbus:
  - uart_id: uart_1
    id: modbus_1
  - uart_id: uart_2
    id: modbus_2
  - uart_id: uart_3
    id: modbus_3

sensor:
  - platform: pzemac
    id: pzemac_01
    modbus_id: modbus_1
    address: 0x01
    current:
      name: "MDB-01 Current"
    voltage:
      name: "MDB-01 Voltage"
    energy:
      name: "MDB-01 Energy"
    power:
      name: "MDB-01 Power"
    frequency:
      name: "MDB-01 Frequency"
    power_factor:
      name: "MDB-01 Power Factor"
    update_interval: never

[...]

interval:
  - interval: 10s
    then:
      - delay: 150ms
      - lambda: "id(pzemac_01).update();"
      - delay: 150ms
      - lambda: "id(pzemac_02).update();"
      - delay: 150ms
      - lambda: "id(pzemac_03).update();"

[...]

[kkeonline]

I have use 6 pzem with esp01s

at beginning it work good, but after a few hour, 1 pzem always lost readng data (crc error) another 5 reading fine. if I remove any 1 pzem cable, another 5 pzem will read data normally. I think this is because i/o current limitation of mcu, difference mcu may have difference i/o current cappacity. So I remove 1 pzem out use only 5 pzem and it work fine for a month now.

the mcu i/o could communicate rs485 data, but it not meet rs485 standard on current cappacity limitation. then, to solve this problem, if use rs485 to ttl connect to mcu i/o instread of connect the i/o directly to pzem will solve the i/o current limit and could connect more pzem on the rs485 line (however I have only 6 pzem to try, anyone have 10+ pzem could try this concept and tell me it work or not)

[atsawin]

I already tried with TTL-485 modules. (There are few of them at top left corner of my picture.)

ESP8266 <-> TTL-485 <-> multiple TTL-485 <-> multiple PZEM

However, I didn't try with more than 4 PZEM yet because I got stuck with software timing problem.

Now, with software timing problem resolved, I'll let it run (3 buses x 6 meters = 18 meters) with multi-drop serial for a few days to see if it stable or not. (it already run about 18 hours for 2 bus x 6 meters = 12 meters.) If the problem occur, I might add 3.3 V <-> 5 V converter. I may have to use 485 as a last resort.

@kkeonline Did you disable update_interval with update_interval: never and use manual update? If you use update_interval, it might because ESP is reboot and has conflict with new random timing. My ESP (NodeMCU V3) reboot itself from time to time. I use uptime sensor to find that out.

  - platform: uptime
    name: Uptime Sensor

[kkeonline]

I already tried with TTL-485 modules. (There are few of them at top left corner of my picture.)

ESP8266 <-> TTL-485 <-> multiple TTL-485 <-> multiple PZEM

However, I didn't try with more than 4 PZEM yet because I got stuck with software timing problem.

Now, with software timing problem resolved, I'll let it run (3 buses x 6 meters = 18 meters) with multi-drop serial for a few days to see if it stable or not. (it already run about 18 hours for 2 bus x 6 meters = 12 meters.) If the problem occur, I might add 3.3 V <-> 5 V converter. I may have to use 485 as a last resort.

@kkeonline Did you disable update_interval with update_interval: never and use manual update? If you use update_interval, it might because ESP is reboot and has conflict with new random timing. My ESP (NodeMCU V3) reboot itself from time to time. I use uptime sensor to find that out.

  - platform: uptime
    name: Uptime Sensor

OK, I will try > manual interval with 6 pzem without ttl-rs485.

[kkeonline]

@kkeonline Did you disable update_interval with update_interval: never and use manual update? If you use update_interval, it might because ESP is reboot and has conflict with new random timing. My ESP (NodeMCU V3) reboot itself from time to time. I use uptime sensor to find that out.

  - platform: uptime
    name: Uptime Sensor

With 6 pzem, after a few hours, 1 pzem will crc error, reset the board not fix it still crc error after reboot. must turn off for a few minutes to cool it down, then it will work ok for a few hours and start crc error again. Test with update_interval: 10s and never, both give the same result.

Now take off 1 pzem and use 5 pzem as before.

[dmachadol]

I have connected 10 PZEMs in parallel. I have modified 10 pzem probes by eliminating the resistors of the RX LED (leaving only one of them to see the data reception) to reduce the voltage drop and so that they all receive the data without problems, and I have separated the signal diode with a 1n4148 diode. tx data from each probe so that its voltage drop is not distributed across all the TX LED resistors of all the pzems connected in parallel. It works with an ESP32 without problems. The diode allows you to see which module is doing the TX without interfering with the rest of the PZEM probes.

[dmachadol]

This is how the setup turned out ![Uploading IMG_5150.JPG…]()