GravityRZ wrote: ↑25 Mar 2021, 18:24
can you see anything which would cause it to mallfunction when the flow is around 25 pulses a minute
The short answer to your question is "no". But here is the long answer:
Interpretation of the logs:
In both cases only clean pulses were detected, i.e. that all three read steps always did read the same level (low/high).
This applies for all the runtime since the last reset. This is indicated by the "/0" and "/0/0".
The "[3603|6523]" in the first case indicate, that (at logging time) the low signal was 3,603 seconds and the high 6,523 seconds.
In the second case the shortest low 524 ms ([524|5815]) and the longest high 133,136 seconds ([8412|133136]).
The difference of the first two numbers ([2135302|2135146|) show, that 156 signal edges were ignored in the debounce time.
The first "/0" shows, that no single debounce effect happened, so you could probably shorten the debounce time a little bit.
You see that the last number in the fist block (e.g. "|2134211]"), which is the TotalCount, is only incremented every second log entry, so you are not using "Pulse change".
I think you are using "Pulse low" because the TotcalCount is incremented whenever the length of the low signal was updated.
And the sequence of long numbers indicate e.g. for "[2135302|2135146|2135146/0|2135146/0/0|2134315]",
- that 2135302 times the signal changed from high to low (interrupt)
- 2135146 reads were done in step 1
- 2135146 reads in step 2 (no single wrong level ("/0|")
- 2135146 reads in step 3 (no single wrong level ("/0/") and no wrong spikes within a stable signal("/0]).
- And, when I calculated correctly, you manually set or increased the pule counter to/at 2133484,
- because with "PULSE low" and if you had started with TotalCount=0 the last large number (2134315) should be half of the the previous (2135146).
A lot of information, isn't it?
But it does not show, why you sometimes count +/- 1 pulse.
What you could do is, to keep the counter running over a rush-hour period, and after that capture some log entries.
Then the numbers after the "/" still indicate, where possible problems may have been.
BTW: In the version, where I am currently working on (TD-er asked me to enhance code readability),
I have added some further "overdue indicators", which show, if the Pulse Counter plugin was blocked/delayed by other ESPEasy processing.
I did that, because I found in my tests of my new version with one of my older ESP8266s, that the Pulse Counter is blocked sometimes for several seconds. This ESP8266 has a bad antenna and frequent reconnects.
This would explain occasional wrong counting. This normally occurred after the message "Error : MQTT : Intentional reconnect". In this period only interrupts were processed, but not the normal stepped check processing in P003.
I intend to investigate this a little more by use of these "overdue indicators". But this is not yet in your current version and I could only observe the problem yet with one specific ESP8266.