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?
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.
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.
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.
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
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?
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).
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?
@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.