Troubleshooting pulse loss on the Cerbo GX digital input

In the course of migrating an oil meter into my Victron environment (and maybe VRM as well), I did connect its reed contact to a digital input of my Cerbo GX. I did not find any settings in the Cerbo to de-bounce the reed contact; I had to use an additional device in between to get this done. It’s a counter with the option to set up de-bouncing on its inputs and also provides configurable (open collector) outputs to properly drive Cerbo’s digital input.

Now I noticed that over time Cerbo seems to miss pulses. From 430,793 pulses, Cerbo only shows 430,627. This doesn’t seem to be that much, but my plan is to calculate my oil consumption from it.

To validate that Cerbo’s input is the problem, I verified the following:
a) I checked that input signal/voltage is in range using oscilloscope/multimeter.
b) I connected an additional counter in parallel to Cerbo’s input. That counter is showing the correct number of pulses.
c) the blue input LED always shows the correct input status.
d) I checked CPU load and response time of Cerbo GX via VRM. “D-bus round trip time” is usually below 7 milliseconds with 10 short peaks up to 20 ms during the past 6 months. CPU load is usually below 50%, load average below 5.

Cerbo is running the large firmware image as I’m using Node-RED to display some data in a dashboard as well as sending HTTP requests to a statistics tool. No additional software/tools are installed.
The frequency of the pulse is between 0.5 and 1 Hertz which shouldn’t be that big challenge for the Cerbo GX.

As I’m running out of ideas about what the problem might be, I’m hoping for some helpful suggestions from the community.

My wild guess: if the heater stops, the reed contact may be either in open or closed state. Cerbo may drop/time-out a closed status without counting, although the blue input LED always shows the correct status.

Cheers
-Andreas

Did the Cerbo reboot at all during that time? That might account for the missed pulses.

There were no unplanned reboots of the Cerbo.
I always performed firmware updates followed by a reboot during periods when no oil was flowing.

Nevertheless, I will log the system’s uptime just to be sure.

I did find and match existing information on Cerbo’s filesystem. From /var/log/messages* and /var/log/swupdate/@40000000* I created the list below.
This links all relevant reboots to firmware updates. So there were no unexpected reboots.

messages.0:Apr 4 20:00:51 einstein kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0 v3.80~13
messages.0:Mar 8 18:13:47 einstein kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0 v3.80~4
messages.1:Feb 28 19:39:58 einstein kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0 v3.70
messages.2:Feb 15 16:50:12 einstein kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0 v3.70~86
messages.2:Feb 3 16:55:31 einstein kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0 v3.70~83
messages.3:Jan 31 16:29:13 einstein kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0 v3.70~81
messages.4:Dec 7 16:44:03 einstein kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0 v3.70~54
messages.4:Nov 19 10:14:01 einstein kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0 v3.70~60
messages.5:Nov 7 14:44:18 einstein kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0 v3.70~54

is the Cerbo really made for that?

I had - in other systems - S0 Pulse counters for electricity - same differences as you see now

I came to the conclusion to use meters that count by themself, only give absolute readings to my main system

Benefit is also, if the main system reboots or whatever - exact figures are still there