Please can someone point me to a description of exactly what each feed type does?
I have tried google, site search and various other routes to no avail.
For those of you around from the beginning, I suspect that the names are enough to tell you conceptually what the feed does. As a very new user, it's more of a challenge.
I have wired my gas meter to my emonPI and the pulse field increments nicely. I am aware, however, that the value will reset to zero any time the emonPI is reset.
Having logged the feed, I tried a feed process of Accumulate. Not only is it not updated when the pulse count updates, it instead updates by some large number periodically. This showed me that I do not understand how the feed processes actually work ie what each takes in and then outputs.
Hence the plea for a pointer to documentation.
Re: Feed Type Documentation
Hello Simon, we will soon have better documentation for this.
The input process you want for this is the wh_accumulator that will remove the resets continuing on from the point prior to the reset. I would then recommend using the PHPFina feed engine. What are you measuring with the pulse count? is it one pulse per watt hour? or something different?
Re: Feed Type Documentation
Thank you. Very happy to help by reading a beta version and suggesting where a beginner would benefit from more clarity (as I am!). Just let me know. I'd offer a quick turnaround :)
meter reads 1 pulse per cubic metre of gas consumed. The kWh value varies with gas composition so I wanted to track the meter's readings for ease of bill checking etc. Trying Wh does seem to be adding just 1 each time though the units are of course not Wh. What does Accumulate do please - what is it adding?
it's a brand new meter, and has a relay which pulses closed as it goes through zero in the LSD. I am getting a few (3 per hour approx) random pulses when no gas is being drawn so tomorrow will switch the 10k pull-up resistor to a pull down one.
Re: Feed Type Documentation
Thanks, Yes the accumulator just adds the input value to a cumulative total, If the input value is 10 and the present total is 100, the result will be 110.
The wh_accumulator takes an input that is already accumulating such as the pulse count on the emonpi and then gets the difference between the present value and the last and then adds that difference to the total. If the difference between the present value and the last value is negative which would indicate a reset it ignores that update.
It also has a check that is designed to allow the input data to have a very breif reset to zero and then for the pulse count to jump back up again such as if there is a temporary blip in the monitoring equipment. It limits the maximum equivalent power that it can accumulate to 23kW if the pulse rate is 1 Wh per pulse. Im not completely happy with this part. It can avoid jumps in the data but is only applicable to an input in watt hours and a power limit of 23kW which may well vary from system to system. For your gas pulse, it sounds like the pulse rate will be significantly below this threshold for it to not to engage this part.
You could log the pulse count to a feed in parallel so that you can double check to see that the wh_accumulator is behaving. At least then you can rebuild from the raw data if something goes wrong.
Re: Feed Type Documentation
Thank you - the Wh explanation makes total sense.
i am unclear on Accumulate. What actually is the input value when it's a pulse input? Surely 1?
Re: Feed Type Documentation
the pulse input from the emonpi is cumulative pulse count, i.e:
15001
15001
15002
15003
This would result in an output with the accumulate process that would sum all of these together.
If instead the monitoring device just sent the total number of pulses in the last period:
1
0
1
1
the result would accumulate to produce an accumulating timeseries as is needed in this application. However there is a danger with this approach of sending the number of pulses in the last period of data loss both if data is sent over radio (rfm12/69) and then with the internet connection. Sending the cumulative pulse count as done in the first approach and then using the wh_accumulator that removes resets gets around this as a couple of missed packets will not matter as the pulse count is updated correctly on the next successful update.
Re: Feed Type Documentation
Very logical and elegant (= I like it).
Presumably all process lists should end with a log to feed in order to allow graphs etc to operate? Are there circumstances where one wouldn't?
Re: Feed Type Documentation
the process wh_accumulator, power_to_kwh and many of the others have the log_to_feed bit built in so you dont have to add this in addition. You can tell if it does log to a feed if the feed create options appear when you select the process - it gives you the option to name the feed or select an existing one - you need to watch logging from multiple input processors to the same feed though..
Re: Feed Type Documentation
That's clever and simple, once one understands the concept.
As the system doesn't seem to permit the name to be reused when setting up a feed, I think it self-protects against different entities trying to climb into the same feed.
thank you for all the clarity - much appreciated. Hooks me even more!