I would to keep track of water usage, to do that I place an inductive sensor on top of the spinning wheel of the meter. It does detect pulses, but too many. The sensor is placed direct on top of the spinning wheel. I’ve used several yaml’s, currently it’s this one:
sensor:
- platform: pulse_meter
pin: GPIO4 # Change this to the actual GPIO pin your sensor is connected to
name: "Water Flow Rate"
unit_of_measurement: "L/min"
accuracy_decimals: 2
state_class: "measurement"
filters:
- multiply: 1 # Adjust based on your meter's pulses per liter
- debounce: 100ms
total:
name: "Total Water Usage"
unit_of_measurement: "L"
accuracy_decimals: 2
state_class: "total_increasing"
Most of inductive sensors have operating voltage higher than Esp’s.
What sensor you have and how it’s wired?
Also, you probably need to set pullup/pulldown on pin mode. Which one, depends on your sensor/wiring.
Anytime you need help, it is a good idea to provide enough information.
Is this your own idea, or are you following some path that others have already followed? I found several different ways people have used to read their meters, some look quite innovative, some look quite difficult to get just right.
Exactly what hardware are you using, part numbers and schematic?
Exactly how to do have it set up?
What debugging have you attempted?
Does it still give too many pulses when it is nowhere near anything?
How do you know it is giving too many pulses? Perhaps your meter has more resolution than you think.
What tools and capabilities do you have? How much electronics do you understand? Do you know how a proximity sensor works and what to expect from it? Do you know if the sensor is working? Do you know if it is providing pulses at all, or perhaps just noise?
thanks for the replies, I’ll give some more details.
I’m using a LJ18A3-8Z/BX sensor, internal pullup, runs at 5V. ESP32-c3-devkit board, sensor connected to power and GPIO4. The watermeter has its own counter, so comparing pulses and actual usage is easy. I understand electroincs and sensors, so if you have details on those, please reply.
the sensor is positioned exactly above the spinning wheel.
I would say the amount of pulses are around 1,5 times the amount of rotations. My next check will be to see if there’s a constant multiply factor (I don;t expect that, btw).
The watermeter spinning wheel makes 1 rotation per liter water and has his own counter, so comparing both values is easy.
So, what more info do you need to give me some tips on where to look/how to approach?
the pullup resistor is part of the sensor, not on the esp32 board. I does behave normally when I move something metal over the sensor. I’ll also check if the error is related to a high flow or also is there when there’s a low flow. Perhaps the sensor has problems cooping with high flow/pulses
So from the Esp point of view the pullup is external. And I suspect it’s pulled up on 5V, so it’s not something you should connect to Esp gpio. I’m not expecting that to cause your extra pulses though.
It can be connected and used without any problems.
I think I’ve come to the root cause of the problem. It’s probably the debounce of internal_filter setting. I can set so the sensor is ‘blind’ for extra pulses in that timeframe. What I saw was that when the metal wheel ‘enters’ the sensor it gives a pulse and when it ‘leaves’ the sensor, it gives another pulse. Setting internal_filter to 6 sec solved the problem.
All I have to do now is find the optimum setting: generate a lot of flow, measure time for 1 spin, adjust internal_filter a bit un that.
There is some debate about if esp pins are 5V tolerant. My understanding is they have a diode to 3V3 to limit the voltage on the other pins. Depending on the size of the pull-up in the sensor it might work fine for years.
I know that I have damaged an esp8266 and a few other chips over time by exceeding what they were capable of with standing.
This is why I asked for the “shape” of the data you were seeing. I wondered how you arrived at the denounce value. Your sensor has a max bandwidth and might or might not generate clean pulses (single transition or multiple for each event). If it generates clean pulses, I would count both and divide by 2 to get liters.
At 6s you have a max flow to 10 liters/min. That might be sufficient for you, but is somewhat on the low side for a maximum. The other problem with that technique is it probably has an issue at low/no flow. The pulse when entering gets counted. The flow stops before the exit. Later, after the denounce timeout, the flow starts again and when exiting the pulse gets counted. The timing has to be just right, but it can happen.
The other thing that can happen is wobble with flow going back and forth. Most meters go backwards with backwards flow, just counting pulses yours will get out of sync.
Only you can decide how accurate you need it to be and how much effort you want to put into it to make it so.
Datasheet is clear with that. What’s the middle/long term stress on the chip, only Espressif knows.
But I’m quite sure they would publish 5V tolerance if they anyhow could. It would be economically very convenient to them.
the debounce value for me now seems to be 2.9sec, that’s the time a full rotation (liter) of flow takes when multiple taps are open. I’ll first check how this goes.
Other problem which was reported is that when the flow stops and the little metal spinning wheel is in front of the sensor, it can give pulses without there’s flow. And that’s a real problem, which can be solved by using 2 sensors, next to each other. 1 liter then is only when both sensors give a pulse.