Pulse_counter not counting properly

[CervoAutistico (Daniele)]

I’m pretty new with esphome, I want to make a small weather station with the weather kit from sparkfun ad both the rain gauge and the anemometer send pulses to keep track of precipitation and wind speed (ex. Rain Gauge: 1 pulse = 0.254mm Anemometer: 1 pulse per second = 2.4km/h).
Now I found the pulse_counter with the “Total” attribute which should give me the total pulses, so I built a small circuit on a breadboard with a button instead of the reed switches used by the rain gauge and the anemometer to test it out.

sensor:
  - platform: pulse_counter
    pin:
      number: 21
      inverted: true
      mode:
        input: true
        pullup: true
    name: 'Pulsazioni'
    count_mode:
      rising_edge: INCREMENT
      falling_edge: DISABLE
    update_interval: 10s
    use_pcnt: False
    internal_filter: 50us

    total:
      name: 'Pulsazioni Totali'

This is the code, as you can see I tried also to disable the esp32 dedicated hardware to increase the internal filter but the issue it’s still there. The issue is if I click (whether I do it quickly or slowly) the button for example 15 times the registered pulsed could go from the exact value to even 8-12 pulses more, so I could even get a total of 27 clicks.
The only difference I saw was when I set the internal filter value to 1ms which caused to count less clicks than the actual made (ex. 10 click made and 6 clicks counted)
The pulse_counter documentations also says on the esp32 it should be highly accurate, so I suppose I’m doing something wrong but can’t figure out what.

[orange-assistant (the real one)]

In your case the pulse meter might be worth a look

Pulse Meter Sensor

[CervoAutistico (Daniele)]

I already saw that and tested it. I got the same issue, still counts more clicks than I actually do.

[JulianDH (Julian Hall)]

I use pulse meter for my anemometer. It does not count but measure the frequency of each pulse and convert that into pulses per minute equivalent. It is more accurate, but it does not rule out noise that is picked up on the data line or the need for a proper pull up resistor. If you search there are a number of threads on this subject and I will not repeat it here.

[JulianDH (Julian Hall)]

Not knowing your specifics but your sensor might be floating.

[CervoAutistico (Daniele)]

at the moment I’m only using a button to emulate a pulse, I don’t know if this could be the origin of the issue. I haven’t bought the weather kit yet so I cannot try directly with the anemometer

And I’ll give a look to the other post about pulse meter

[RonnieLast (Last of the Ronnies)]

That sounds like you’re experiencing switch bouncing as the switch contacts are rattling when closing.

What is Switch Bouncing and How to prevent it using Debounce Circuit

You might need a debounce circuit on the switch or the debounce filter on the input:

Sensor Component

[CervoAutistico (Daniele)]

Ok I finally found a way to use the pulse_meter. I placed an external pullup resistor and now the pulse_meter works fine so I will use that. But I’m still curious about why in this configuration the pulse_counter doesn’t recognize any input (both with pullup or pulldown resistor) and same with pulse_meter with a Pulldown.

[CervoAutistico (Daniele)]

I didn’t knew about that filter. I’ll give it a try asap.

[loic69]

Can you share your code fore pulse_meter rain gauge and anemometer ?
Thx

[WJ4IoT (WJ)]

@CervoAutistico, @RonnieLast , @orange-assistant, @loic69 and @JulianDH thanks for your comments, very helpful but I missed the latest version you used.

LOL the 10 seconds interval used in the example for an 1-minute sensor put me completely on the wrong foot, ignore my previous version.

For my sensor (Misol Rain Gause) it was important to reduce the internal_filter.
For the moment it looks like that 8us is a good value which also sees a fast (manual) flip. Normal flips will go more gradually I think because the buckets fills slowly with water.

[Fallingaway24 (Justin)]

Im not sure how your coming to the conclusion that pulse_counter/puse_meter is “tricky to use” because its not and internal_filter is an Optional configuration for those that need a higher level of filtering out false positives. You dont have to mess with it at all and it will use the default settings all of which is explained in the documentation.

@WJ4IoT

? Can I create a template sensor inside ESPHOME to count the number of times the binary_sensor switches to “ON” ?

ESPHome — ESPHome

That is answered in the documentation too. There are lots of examples as well.

Automations and Templates

@WJ4IoT

Writing this done might inspire me to find the solution inside ESPHOME myself

Id start with reading the documentation and if your really motivated, try a search box because people have already posted guides for setting up the Misol rain guage and calibrating it in esphome, you just have to make an effort to go use the search box and find it.

[WJ4IoT (WJ)]

Hi @Fallingaway24 Thanks for your reply, I am sorry I made you writing, you can see I have already corrected this mistake while you were composing your response. I do try to utilise this forum and documentation; must confess the lamba part is still Work in Process; e.g. the possibilities of on_… is biy of a puzzle

After tweaking the pulse_counter and realising 10 sec is not 1 minute the results are improving.

[Fallingaway24 (Justin)]

Good! Its very useful information. Not understanding how to use lambda isnt uncommon. I would still 100% recommend learning it at whatever your pace is but, keep in mind that for the majority of things, you can almost always only use esphome style yaml by itself…

Are you talking about when the documentation is like this its confusing?
These

on_.....:

I assume thats what you mean because its common and i remember wanting to slam a keyboard through a monitor trying to figure that out when i started! Its actually pretty simple though. Ill show you some examples to help.

Using the same one as abobe. While conditions

on_...:
  while:
     condition::

The reason they use the … isnt to confuse you, its because there many types of on_… commands.

Lets say your using a switch. Now you go check the documentation and look up switch to see what functions/commands Switch uses.

Switch Component

So, it uses on_turn_on: and on_turn_off:

Back to your “while” condition above.

on_...:
  while:
     condition

Your using switch so then instead of … you use “on_turn_on” “on_turn_off”

switch:
  - platform: gpio
    name: "my switch"
    on_turn_on:
      while:
        condition:
           - binary_sensor.is_off: test_sensor
        then:
           - switch.turn_on: xxccccc

What if you were using a number component? A box where you can select up/down and select a number or use a slider.

Number Component

For Number you can use, “on_value” and “on_value_range”

So instead of on_… you would so something like this.

number
  - platform: template
    name: "my number"
    on_value:
      while:
        condition:
           - binary_sensor.is_off: test_sensor
        then:
           - switch.turn_on: xxccccc

So… the reason its “on_…” is because it depends on what other thing you are using such as Switch, Number, Button, etc. They all use a unique on_… syntax.

One more… lets use Servo.

You need to use the servo.write inorder to tell the servo to move and how much to move. The example uses that on_…
I used buttons on mine for example(Left, Right) and button uses?

Button Component

So… that annoying “on_…” example means “on_press” because I needed a left and right button.

button:
  - platform: template
    name: "Left"
    on_press:
       then:
         - servo.write:
           id: my_servo
           level: -100.0%


  - platform: template
    name: "Right"
    on_press:
       then:
         - servo.write:
           id: my_servo
           level: 100.0%

[WJ4IoT (WJ)]

Thanks for this detailed reply. It is clear to me now that “de keuze is reuze” so there is just “on_…” and the variations are described on each component. It also made me look twice; I started with “on_state” but based on this reply and a second look I realised " on_press" was better (yes I know RTFM).

However we moved now a bit away from the topic so to correct this I want to make the following daring (NOOB) statement:

a pulse_counter is more suitable for situation with a fixed pulse length (like in energy meters). The pulse length of a Rain Gauge can vary and might even hang on tipping point when the rain stops. Due to this it is less suitable to use it as a pulse_counter. Better use a binary_sensor (and do all further logic inside HA)

f.y.i. What is each tip? I asked Misol and the answer was that each tip is 0,3 mm

[Fallingaway24 (Justin)]

Yes, exactly each component has its own variations of on_… well actually some get shared but, its best just to look up whichever one your using. Ya, on_state, on_press, on_click, etc. It can be confusing as to which one to use. They are all very similar but differ slightly and in some situations one will be better than the others.

Yes, some times pulse_counter is best and others its not, it just depends. Also, with sensor filters the pulse length is irrelevant because you can choose to include or exclude pulses based on all sorts of options. Its really up to the end user how complicated or simple they want to make it. Using a binary sensor is essentially just a pulse but it has a fixed upper and lower threshold for On/Off and you could 100% duplicate that with pulse_counter and sensor filters so in my opinion it really doesn’t matter one way or the other.

I found this posted in an Amazon review if it helps.