I have had a set-up that counts pulse from my grid and solar meters using the standard optical pulse counter. Until recently I had been doing things like:
Log to feed
Wh Accumulator
x 0.001
kWh to Power
Power to kWh/d
and before that I had kWh to kWh/d somewhere, and I was getting very lost.
I noticed that some of my daily value had gone a bit mental over the last few weeks so I decided to revisit the config.
I found a new (to me) function “total pulse count to pulse increment” that seemed to be mentioned somewhere in a post, and along with “Wh increments to kWh/d” does the right thing in general except when I try to use schedules. I have an E7 schedule defined but the “total pulse count…” seems to ignore the “If !scehedule, ZERO” just before it.
I guess my problem is that the help text is missing lots of info - some steps pass the value through unchanged and just log the modified value to a feed, some pass on the modified value. “total pulse count…” has no help text. I can’t find any sort of function reference guide that lists all the current functions.
I will at some point go into the source, but what, please, is “state of the art” WRT pulse counting?
Also, I removed the kWh accumulator feeds and the Apps now complain, even though I don’t care about the history pages - perhaps the Apps should ignore feeds when they are left unset in the config?
I think the use of schedule before that process will confuse things as eventually the “non-E7 period” will end and as soon as the “if !schedule, ZERO” no longer zeros the full increment will be logged.
I’m pretty sure you need to log the increment once at all times and then use that increment with the “if schedule, NULL” and “if !schedule, NULL” processes to pass or block the increment before logging to the “E7” and “Peak” accumulating feeds.
As a sidenote, the most important thing to know when using the “total pulse to pulse increment” process is that the created feed is logging the “last value” not “the increment”. therefore you cannot use the “total pulse to pulse increment” feed directly as it’s content would be exactly the same as a “log to feed” on the raw input, the feed created by this process is purely to remember the last value for calculating the most recent increment.
From memory
log to feed (raw value)
Wh accumulator (running total)
===> next process is passed an ever increasing “running total”
is pretty much the same as
total pulse to pulse increment (raw value)
Accumulator (running total)
===> next process is passed an ever increasing “running total”
But in my opinion it’s more flexible as it exposes the actual increment eg
total pulse to pulse increment (raw value)
log to feed (the increment)
Accumulator (running total)
===> next process is passed an ever increasing “running total”
and more reliable as it persists the last value. The WhAccumulator uses Redis to retain the last value so it could be vulnerable to error at restart and resets etc.
Another thing to watch for when using the WhAccumulator is the “25000” max value limit, this might be ok when using it with a 1w unit but if counting un-scaled pulses eg i pulse = 0.1wh, a 2.5kWh limit is easily reached and anything greater than that is ignored. No such limit exists in the total pulse to pulse increment" process.
Now that I read your explanation it makes sense. I will roll back those process steps and delete my unwanted feeds and rebuild with some more thought. IMHO the notes on the processes (as presented in the web GUI) need to be much clearer. I am going to try to contribute.
My E7 measuring is only rough anyway as the clock on the meter drifts and I stopped updating the schedule more than once in a while.