i use the M12 LJ12A3-4-Z Bx 5 V Inductive Proximity Sensor to count pulses on my watermeter.
This has been done before and with good results.
The things I (and many others) experience is that this is not a 100% reliable solution. sometimes you get multiple extra pulses and sometimes pulses are missing.
It took me a lot of testing where these extra/missing pulses came from.
there are a lot of factors which can cause this behaviour
sensor jittering,
bug in p003 plugin
ESPEasy software
wifi transmission
protocol used(HTTP, MQTT)
data send through controller or through rules
timing problems in rules
after 4 weeks of testing and testing i think i have a solution which seems 100% reliable.
it is 1 week runnig and absolutely no missing or extra pulses.
to help others i will describe my setup and name the points i find important. Maybe you are one of the lucky ones who have a good setup without these ;points but still it would not hurt
Always use a 10K pullup resistor on the ESP input
use an optocoupler, i see a lot of people without electronics knowledge who either do not use a pull up resistor or do use one but connect it to the 5V
the inputs of the ESP are 3.3v and are 5v tolerant, this means in can accept 5v levels but in doing so you might blow up the port. to be save stay on 3.3v logic on the ESP input side
of course you could always use a resister divider but please note this is NOT a logic shifter. true it acts as one and will probably work but it is not a clean solution
when using the P003 pulsecounter, use a debounce time to avoid jitter, i use 2000ms(if set to high you might miss a pulse, if set to low you might get extra pulses
set the p003 pulsecounter to a 1 second interval. this means whenever it receives a pulse it will flush the data to the variable every second
since my maximum water consumption is 25 liters per minute this means 1 pulse every 2.4 seconds so as long as the interval is set lower than the max flow you are save and will not miss a pulse (unless things happen at the exact same time. sofar this did not happen).
reset the pulsecounter every 24 hours, just to make sure the variable values do not get to big
set wifi to nosleep(not sure if this is mandatory but it helps)
use a dummy sensor which keeps the total meter value(pulsecounter has no realtime update, dummy device has)
use the pulsecounter to trigger a rule which increments this total meter value
send over the complete value(i used to sendover the delta but if anything goes wrong with the transmission you miss a pulse) using rules
use the http protocol to send it over(i used to use MQTT but this can cause missing/extra pulses)
with all this in place i still had an occasional missing/extra pulse.
i suspect that this was caused by either a timing problem in the rules(2 things happening at exact the same time) or a short burst in the waterpipe which causes the watermeter to move back/forth and caused a jitter in the sensor
what i did was adding a small but powerfull magnet to the side of the proximity sensor. The idea is to make the sensor more sensitive. by doing so i did not expect that this would solve the problem because when the senso is more sensitive there still is a border area where the sensor will go from 0 to 1 and back and this area is sensitive for jitter.
when you move the magnet around you notice that the sensor will become more sensitive while moving in another direction it will become less sensitive. let the watermeter run and move the magnet around. the idea is to widen the pulse so that it stays on longer)
Well with that final adjustment it is running stable for 7 days in a row now(fingers crossed)
I tried the magnet trick before but it did not solve my problem at that moment so whenever you notice problems with the pulsecounter missing/adding pulses it is not an easy fix.
things i tried which did not solve the problem.
change the protocol(HTTP/MQTT)
change MQTT timing
sendover data directly from pulsecounter instead of rules
let rules be triggered by gpio pin instead of pulsecounter variable
changed wifi from eco to no sleep
Code: Select all
On System#Boot do // When the ESP boots, do
TaskValueSet 3,1,0 // TaskValueSet TASKnr,VARnr,Value, Reset the Flow counter to 0
TaskValueSet 3,2,0 // TaskValueSet TASKnr,VARnr,Value, Reset the PreviousFlow counter to 0
if [Water#CounterTotal] = 0
TaskValueSet 3,4,1836974 // TaskValueSet TASKnr,VARnr,Value, set watermeter start value in case of power failure
endif
TimerSet,1,30 // Set Timer 1 for the next event in 30 seconds
EndOn
On Clock#Time=All,00:10 do // Reset Pulsecounter and LitersToday
if [Water#Flow] = 0
TaskValueset 3,3,[Water#CounterTotal] // set Water#CounterOffset to correct value at start of day. just for testing purposes
resetpulsecounter,1
endif
EndOn
On Watermeter#Count do // When Pulse is detected
if [Watermeter#Count] = 1 // if pulse is received
TaskValueSet 3,4,[Water#CounterTotal]+1 // increase Water#CounterTotal with 1 liter
SendToHTTP 192.168.1.50,8084,/json.htm?type=command¶m=udevice&idx=344&nvalue=0&svalue=[Water#CounterTotal]
TaskValueSet 3,1,60000/[Watermeter#Time] // set Water#Flow
SendToHTTP 192.168.1.50,8084,/json.htm?type=command¶m=udevice&idx=338&nvalue=0&svalue=[Water#Flow]
endif
EndOn
On Rules#Timer=1 do // When Timer 1 expires, do
if [Water#Flow] > 0 or [Water#PreviousFlow] > 0 // Only send value if flow and PreviousFlow > 0
SendToHTTP 192.168.1.50,8084,/json.htm?type=command¶m=udevice&idx=338&nvalue=0&svalue=[Water#Flow]
TaskValueSet 3,2,[Water#Flow] // set Flow to PreviousFlow
TaskValueSet 3,1,0
endif
TimerSet,1,30 // Set Timer 1 for the next event in 30 seconds
Endon