I’m a relative newbie here, and still trying to understand much of the detail of how the various systems and subsystems hang together in emoncms/emonpi/firmware, but there is one addition I would like to recommend be available in a future release, given the OpenSource ethos, and the committment to energy monitoring (and monitoring of resources in general), and that is to include some functions that are relevant to pulse-based metering systems, and to gas metering in particular.
I was a bit surprised after I had my electrical monitoring up and running, and was eyeing up my gas meter, when I realised that, with all the attention to detail being paid to the measurement, analysis and presentation of electrical energy, that the equivalent for gas-based energy was not even basic. I know that stems largely from the fact that virtually every gas meter uses pulses of some sort, but you can derive more information from a stream of pulses than is currently done in emoncms.
This is important, at least to me, because in my house, I typically consume around three times the energy in kWhours in the form of gas as I do in electricity, over the course of a full year. This is largely to do with the use of gas-fired central heating and hot water in a house in Scotland which can see a lot of cold days, obviously especially so in Winter. My house is by no means untypical, so it appears that, for an energy monitoring organisation, it is pretty largely ignoring a major energy component consumed by a large fraction of premises across the developed world. I could make a similar argument for oil-based energy usage, too, but I’ll leave that for others to make their own cases.
So sticking to gas as context, here is my take on it. Do feel free to critique this, I am entirely capable of making mistakes, or misunderstanding the capabilities of emoncms/emonPi, or being a total idiot, or even living on the wrong planet. I am happy to be corrected, but gently! (Fingers crossed.)
On the detection of a pulse, you know from the context of its source what it represents, in my case the consumption of one cubic foot of gas. You can timestamp it and record it in a feed, and that can be displayed in a graph. If it was recorded at fixed intervals (phpFINA), you will see a series of isolated thin bars all of the same height in a histogram, with empty gaps of varying width between them, essentially a stream of ones and zeros.
Once you have more than one timestamped pulse, you can derive the duration between adjacent pairs, and by dividing the Joules in one cuFt (1146053J) by the duration preceding a given pulse you can derive a rate of energy usage in Watts for the consumption over that period. Those resulting Watts are relevant for every datapoint between the relevant pulses.
A. Emoncms currently doesn’t let you derive that duration using the standard Input processing, and neither does the standard firmware in the emonpi nor emontx, because they do not send pulsegap data, only pulsecount data. If you want a duration, you have to modify either the firmware to track it and send it alongside the pulsecount (which is information that is as pertinent to pulses as counting them), or modify or create suitable Input process functions to derive the durations from the accumulating pulsecount, and for that you need access to timestamps, or at least the current time, to do so, and I submit that that capability should be made available to the user in the processlists.
B. Even if you manage to derive the Watts usage as above, emoncms doesn’t currently let you store that data properly in a feed, because the Watts data for a period can only be calculated at the end of that period, but are relevant for every datapoint between the current pulse and the previous one, but emoncms doesn’t let you write that data back into those intermediate datapoints, so again you need a custom feed function that can do so, and it needs access to a duration to let it determine how far back in the feed it needs to go to amend otherwise empty datapoints. Without this, the gas Watts data in a feed is very unrepresentative of the measured reality.
C. None of the existing apps (Myelectric, mysolarpv, myenergy, etc), cater for gas. They do cater for Watts, so can handle gas Watts, but the labelling assumes all Watts are electric, either grid electric, solar-electric, wind-electric, etc. So there is a need for a mygas, myoil, or even a mydualfuel (with oil/gas labelling choice).
D. A consequence of having a possibly frequent rewriting of gas Watts history is that a moving line graph such as that in mysolarpv can get rapidly out of date if the 5 second refresh doesn’t also carry out its own rewrite at the righthand end of the graph. If a fresh pulse arrives, the Watts value spike is put up immediately, and the previous npoints in the graph should be updated, too where relevant, without having to force a reloading of the data from the feed every 5 seconds.
E. More generally, in a Low-write context, the use of feeds to hold temporary information for an intermediate calculation should be discouraged, when a memory-based alternative can be made available, and a wider range of mathematical operations, or variations permitting different choices of the values or constants they operate on, would improve flexibility. These would reduce or eliminate the need for a user to get stuck in creating her own functions when the standard ones don’t quite let her carry out the operation or calculation she needs.
F. Erm, that’s me done, over to you. 
