Hi, I am using emoncms on raspberry and I use an S0 pulse counter to monitor consumption. but wh accumulator has strange behavior. my meter has 1000 pulses every kwh so 1 pulse is worth 1 watt. but in the feeds now i have 14060 pulses and 14039 wh why does this happen?
l
There is probably an explanation somewhere in the OpenEnergy Documentation. From my experience I use the Accumulator process whenever dealing with pulses. In this example 1 pulse = .075 gallons.
Have a read of how PHP Fina works here: Learn | OpenEnergyMonitor
We’d need @TrystanLea or the like to confirm it also applies to the accumulator, but with PHPFina, if you update a feed with multiple values within the same interval period, only the first value is stored.
If the accumulator works like this:
Read the value stored in the previous interval, increment by the amount in this reading and store that value
Then if you receive two 1Wh pulses within 10s, you will only actually “store” one of them.
That could explain how you’ve missed some?
hello it seems that the problem occurs more when I have high consumption. but why does this happen? wh accumulator is calculated based on the primary feed. shouldn’t lose points. how can i solve this annoying problem?
Did you read the description in that Learn article I posted above?
If it happens during high consumption then my explanation is even more likely to be true.
Did my explanation make sense?
You can probably reduce the problem by storing data more frequently. Instead of using 10s interval, use a smaller interval? Or use a different feed storage type. They are all described in Learn along with their different benefits and drawbacks.
I have a feeling it is the first value in the window. I had a discussion about this a while back IIRC.
[edit]
Ah yes - Starting out - Raspberry PI3b / Arduino Uno R3 => local Emoncms - #20 by pb66 @pb66 might be able to help.
Thanks Brian, I’ve corrected my post…
The PHPFina construct does keep the last value written to a time slot, but the feedwriter (in the low-write installation mode) only writes to a timeslot once, thus only the first value of a timeslot is stored in this case.
The outcome in this particular thread will still be the same though - missed accumulated Wh 
I get the opposite problem, my Wh Accumulator runs away after a while.
You can see it is fine initially, then increasingly goes haywire.
I’m using feedwriter and keep meaning to switch it off.
I’m also running the
URL : https://github.com/emoncms/emoncms.git
Branch : * feed_insert_skipbuffer
Describe : 10.2.7-8-g48d40637
Can’t remember why now. 
Need to find time to tidy this all up.
@TrystanLea any thoughts.
Interesting, Il try and put together a test to see if I can replicate this. Il try posting at a faster interval than the feed interval. I think it should be independent of the feed interval as the wh_accumulator calculation all happens using redis pre data storage but maybe Im missing something?
@borpin your issue looks like a reset that isnt caught properly, do you see zero values in the original feed at the larger step points?
It is very odd.
I remember noticing this before and not getting around to looking further. It must be specific to my Proxmox version running on a Debian container as my EmonPi, recording exactly the same Input with exactly the same input processing is fine! Both running feedwriter.
[edit]
And the pulse v kWh looks fine as well (on the EmonPi).
Data is via a directly connected pulse sensor via the pulse interfacer, sometimes runs slower than the feed interval and sometimes faster.
[edit2]
This shows it better - the diff is the same. Data gaps are where due to low consumption, there isn’t a flash.
[edit3] - final one…
I lied, the Feed on the Proxmox server is 10s and the Feed on the EmonPi is 5s.
Thanks @borpin, testing here it all works fine, independently of feed interval, until I flush redis to simulate a reboot. After clearing redis the process fetches the last value from the feed and the feed can be quite a bit behind the actual value at this point. The result is that the pulse count starts to lag the pulse count coming in from say the emontx, which reproduces what @calida_82 sees I think.
This is a limitation from the effort to reduce write wear to the SD card using redis unfortunately. I cant easily see a way of improving this without increasing the write rate, perhaps there is a way of doing that for specific processes like the wh_accumulator without negatively affecting SD card wear significantly.
@calida_82 what hardware/software are you using to count the pulses? are you using an emontx/emonpi or the emonhub pulse counter interfacer?
I assume you are using redis on the proxmox server @borpin?
Yes I am.
@Bill.Thomson discovered, and I’ve integrated into our EProm library, EEWL. It’s a wear-levelling library for EEPROM.
As I’ve got it at present - and we’re still testing - it receives the accumulated energy and pulse values from the sketch each time the data is sent to emonCMS, but it only stores them in the EEPROM when any one goes above 200 units (i.e 200 Wh or 200 pulses) from the last time the values were saved. I chose 200 as that represents a relatively insignificant value, both in terms of the units used for billing and in monetary value. In the event of a power fail or reset, the sketch can recover the last saved values - meaning that a maximum of 10 s worth plus 200 units might have been lost.
Given that it’s safe to allocate ¾ of the EEPROM to this (retaining ¼ for the calibration etc), under normal use I envisage an EEPROM life of around 60 years. That should be adequate.
