ESP Pulse_Meter Noise leads to too much counts

ESPHome
1

Hei Community,
I have some struggle using the W5500-EVB-Pico-PoE together with the pulse_meter.

On startup some time everthing works fine and pulses are count. After some time there is a lot of noise and the pulse_counter triggers way too much.

The Hint is: if I use an adopted Script on a WLAN ESP32 everything works fine.

Can anyone give advice on what to do ?

Stack:
W5500-EVB-Pico-PoE
WIZPoE-P1
Closing Reed as Input

Config:

esphome:
  name: w5500_03
  friendly_name: "W5500-EVB-Pico_03"
  platformio_options:
    build_flags:
      - -Dpadsbank0_hw=pads_bank0_hw

logger:
  baud_rate: 0
  level: DEBUG

api:
  reboot_timeout: 0s

ota:
  - platform: esphome

external_components:
  - source: github://tiehfood/w5500-evb-pico-esphome-components@main
    components: [async_tcp, ethernet]

rp2040:
  board: wiznet_5500_evb_pico

ethernet:

# Onboard LED and restart switch
switch:
  - platform: gpio
    pin: 25
    name: "Onboard LED"
    id: onboard_led
  - platform: restart
    name: "Restart Device"
    entity_category: diagnostic

# Non-blocking LED flash script
script:
  - id: flash_led
    mode: restart
    then:
      - switch.turn_on: onboard_led
      - delay: 200ms
      - switch.turn_off: onboard_led

sensor:
  # Pulse Counter on GP12
  - platform: pulse_meter
    id: pulse_counter_1
    name: "Pulse Counter 1"
    unit_of_measurement: "l/min"
    accuracy_decimals: 1
    internal_filter: 50ms
    timeout: 30s
    filters:
      - multiply: 10
    pin:
      number: 12
      inverted: true
      mode:
        input: true
        pullup: true
    on_value:
      then:
        - script.execute: flash_led

  # Pulse Counter on GP22
  - platform: pulse_meter
    id: pulse_counter_2
    name: "Pulse Counter 2"
    unit_of_measurement: "l/min"
    accuracy_decimals: 1
    internal_filter: 50ms
    timeout: 30s
    filters:
      - multiply: 10
    pin:
      number: 22
      inverted: true
      mode:
        input: true
        pullup: true
    on_value:
      then:
        - script.execute: flash_led

pulse_counter_problem
pulse_counter_problem1655×539 110 KB

I do not know what to do as I just can not figure out what causes this ‘noise’.

Any Help appreciated.

Regards Manuel

2

If you have noisy environment, you might need external pullups (don’t use gpio12 in that case).
And use higher internal_filter if possible.

3

Sorry i forgot to mention i tested this with Internal pullup on Pin 12 and with internal and external pullup 10k together on pin 22.
Leads to same result

4

You might want to present your circuit. What is giving the pulses? How long wiring etc. 1K pullups behave better in noisy environment than 10k or 40k.
You can also try longer filter and different internal_filter_mode.

5

This is the Datasheet of the Reed Switch: Reed Kontaktgeber zu MNK N Zähler (Zenner) | 105018

I use this for two usecases i testet:

A: Grounding Internal Pulled up GPIO 12

B: Grounding Internal Pulled up GPIO 22 with external Pullup 10kOhm

Worth Mentioning: The Reed has internal Resistor of 47Ohm.

Any advice ?

Regards Manuel

6

And are the wires running together with some mains wiring or close to electric motor etc?

So did you try?

7

So the question is: “is the counter messing up or is the signal incorrect?”

I have no idea what this means.

If I was trying to solve this problem (and I have done that for my gas meter, that has a reed switch). I would be looking at the actual signal that is coming in at the esp32. A standard GPIO has very low noise immunity, i.e. it is very sensitive to noise. It is likely that your wires to the meter are longer than a meter and possibly ten meters or more. At that length a standard GPIO is pretty much a bad idea (that sometimes works okay).

Read these to make it work better:
Max distance for GPIO cable? - Raspberry Pi Stack Exchange

pi 2 - Long length of wire off of GPIO pins - Raspberry Pi Stack Exchange

The key point is that you actually need to have a decent amount of current going through the switch, so you need a very strong pull up (as @Karosm suggested 1K or even half that). You also need the capacitator.

You may also need to limit how quickly the counter can count.

Back when I did this for my meter with Tasmota I couldn’t get its counter to work well enough, so I wrote some custom code to check the value every 500ms and then count the transitions. That worked pretty well.

I currently have it running with a newer version of Tasmota using scripting and 542ms debounce. I disconnected the reed switch (since it wasn’t working) and am using a magnetometer for the reading. The pulse counter still gets some extra pulses (0 to 10 a day), so my HW/SW combination is still not quite good enough.

8

It’s kind of tricky to estimate the pulse length with these kind of setups. We know that the pulse interval is >10s, but I have not really an idea about the range of pulse length if OP doesn’t measure it.
Anyway, the graph shows that there are some serious interferences or something wrong with the whole setup.

9

It is likely a gas or water meter. My gas meter closes the switch for about 10-20% of lowest digit’s travel (comes on at about 0 and stays closed till about 1 or 2). Depending on gas flow this means seconds to hours.

Since they work magnetically most meters will have similar behavior. Even with my 542 ms denounce it isn’t enough. This is likely because the denounce is implemented as: count the interrupt and if you get another interrupt before the debounce timer expires do not count them. This gives faster response than: when you get the interrupt, set a timer to check the input after it expires and only if it is still active count the pulse. The later method can still over count, but it is less likely.

I would stick an oscilloscope on the wire and see what is there. I suspect it is not pretty. At some point I will put an optoisolator on mine. That will require the noise to supply several mA of current to get the GPIO to count. If you have that much noise you need to figure out what is causing it and eliminate that problem first.