Wh accumulator glitches

I have a feed for Wh counter, using pulsecount with Wh accumulator process.

While the pulse counter advances normally, I have experienced peculiar jumps in accumulated Wh values. Anyone else noticed this kind of glitches?

Of course, this makes the use of Wh accumulator pretty much useless, since the values are completely off.

I have seen odd behaviour thaqt could be explained by exactly this but I have not had time to track it down. I have seen problems where the daily kWh is impossible (5,000 etc.) on random days. I will try to look, but there is so much data - jumps like this would make sense in that case.

i had the same problem (vertical rise)
for me i was attempting to use schedule - it would stop counting when the schedule cut in (as the logic set the feed to zero), but then pick up as soon as the schedule ended (as it would pick up the count which continued in the background.

if that is what you are doing then the pulse count → increment prior to the accumulator may help (although it didnt fix my problem)
from what i can see its probably not that though as i dont think you are using a schedule

Hi all,
I had the same issue when arduino is rebooting for some reasons. The first measured values are very high and are altering the outcome for daily WH counter. I think can be avoided with a minor modification in the emontx sketch.
I hope it helps.

Are you using a very old version of emonLib?
The high pass filter that was used to remove the d.c. component of voltage and current did show high values for the first few sets of values as the filter settled to the correct d.c. level, but it was replaced a couple of years ago by a low pass filter that is initialised to the nominal value. There may still be a small step in the initial readings. Its size will depend on the accuracy of the d.c. bias on each input, but the step is nowhere near as big as before.

I have to check the emonlib version. Note that the values were for pulse count, not clamp sensors.

In that case, it will not be that emonLib problem, which will only affect the voltage and current (and therefore power) measured by the a.c. adapter and current transformer.

I’m resurrecting this as I’ve just observed a cluster of very strange glitches in my gas meter pulse counting process list. At 2am the night before last my gas_kWh accumulator shot up by some 400kWh. It has repeated this 3 more times, with slightly different upticks at approximately equal intervals of 10h45m! (the exact time deltas values are 38650, 38570 and 38530) seconds.

I have a pulse counter on my gas meter which is effectively de-bounced with a capacitor. The input process list looks like this:

The pulse counter feed shows no jumps across the time period (It did reset a week ago when I had to unplug the server for a while but that didn’t affect the gas_kWh). The pulse_delta feed (which is normally 0 as it updates every 10s and the gas meter updates every dm3 of gas, which takes us more than 10s to consume) however shows massive spikes at the time. Here’s a typical view of it:

This then leads the gas_kWh accumulator to have a massive step-jump as per the earlier postings.

Although I have been working on this machine, I’ve not been working at 2am or midnight. There are no entries that look suspicious, either in emoncms.log or syslog. I’m mystified! I’m also wondering if it’s going to happen again at 9pm tonight…

Any ideas?

I looked at the patch and it does seem that the current codebase (pulled directly from Github master) doesn’t need it as there is a call to a new function validate_timevalue that seems to do the same. It does however highlight the subtleties of null being interpreted correctly, or not, which may be relevant.

However, it didn’t happen again so I won’t be pursuing a solution until it does. It did inspire me to write a command line script (cliFina) that can apply updates to PHPFina files directly. It’s a bit like the postprocess ability or the Visualization editor but it can specify a range within the file to update. I used it to fix the issue by subtracting out the erroneous delta from the point it happened to the end of the current file. I had to run this four times. Here’s the call to fix the single intermediate datapoint error:

**pi@emonpi**:**~ $** sudo scripts/cliFina -n -p10 65:[1675255250,+0]=1893.3502197265625
Processing file /var/opt/emoncms/phpfina/65...
metafile: start_time=1673470640, interval=10, end_time=1675348560, 187793 entries
requested range: [1675255250,+0] normalized to [1675255250,1675255250]
Backing up file...done
time=1675255250, data=2339.209228515625, new=1893.3502197265625
File /var/opt/emoncms/phpfina/65 (1 changes were made in 0.001 seconds)

And heres the call subtracting the delta from the following point to the end of the file:

**pi@emonpi**:**~ $** sudo scripts/cliFina -n -p10 65:[1675255260,end]-=471.34313964844
Processing file /var/opt/emoncms/phpfina/65...
metafile: start_time=1673470640, interval=10, end_time=1675348870, 187824 entries
requested range: [1675255260,end] normalized to [1675255260,1675348870]
Backing up file...done
time=1675255260, data=2364.693359375, new=1893.35021972656
time=1675255270, data=2364.693359375, new=1893.35021972656
time=1675255280, data=2364.693359375, new=1893.35021972656
time=1675255290, data=2364.693359375, new=1893.35021972656
time=1675255300, data=2364.693359375, new=1893.35021972656
time=1675255310, data=2364.693359375, new=1893.35021972656
time=1675255320, data=2364.693359375, new=1893.35021972656
time=1675255330, data=2364.693359375, new=1893.35021972656
...
time=1675348870, data=3500.836669921875, new=3029.4935302734348
File /var/opt/emoncms/phpfina/65 (9362 changes were made in 0.585 seconds)

It’s available in the scripts folder of my emoncms clone and I’ll include it in my (eventual) pull request.

That would be interesting :slight_smile: