Hi.
I'm wondering about kwh_to_power.
Currently, the function computes power as
energy / (time_now - last_time)
and attributes it to time_now.
(I think this should be attributed to the middle of the interval, not the end, as done here. But this is not my main issue.)
My use case is a counter index that gets sent from times to times. The pulse rate is not that high. When the index is not incremented, it does not mean there is no consumption at all. And when it finally gets incremented, it means that a certain amount of energy has been consumed since the last time it was incremented, even if the counter had been received unchanged in the meantime.
A little more on this here: http://openenergymonitor.org/emon/node/3338#comment-16946
This is a bit hard to deal with currently.
When the index is sent twice with the same value, the power is computed as zero. Not so much of an issue since it is close to zero. Except that when the index gets increased, the power is computed since last index reception, not since last index increment, and we end up with an absurdly high power value if the former index was received just before.
A solution to this could be to only process the power if the index actually changed (this is what I do, see my link above). This is fine, mathematically.
If the data was represented as a step function, it would be fine to record the power for time_now and let the visualization do the job: display a flat curve with this value from last_time to time_now. It is not the case. I managed to trick the visualization with a hack: record computed power for both last_time and time_now. This way, it gets displayed as a step function.
This is not so nice, though: it leads to data duplication, and worse, last_time gets two power values, and it's "lucky" that the plotter picks them in the right order. (Not really luck, it is reproducible, but I think we shouldn't rely on this, should we ?)
If I record the value only at the middle of the interval, then if the index is unchanged for a long period of time, I get a value close to zero in the middle on the interval, but not a nice flat function because the point is linked (interpolated) by the visualization to the peaks on the right and left.
Basically, in practice, if I use the gas once in the morning and once in the evening, I'd expect a square U shaped chart, but I get a V. There is a loss of information. It is confusing.
I don't any simple solution to this, apart from the hack I explained above.
Creating a "step function" visualization ? We'd need it for both realtime, rawdata, and perhaps other visualization. At least, this approach would be mathematically correct.
Another approach would be to alter data in the database: compute the power even when the index is unchanged, but then when it is changed, compute the power for the whole interval since last increment, and modify the values that were recorded in the meantime. Sounds like my hack in more complicated. Perhaps the "step function" hack was a better approach.
When dealing with this, we need to keep in mind that the visualization is not the ultimate goal. The data could also be used for an external process. So twisting the database to let the visualization produce what the eye expects it not the best option.
I hope I'm making myself clear. I've been banging my with this for a bit of time, and I feel like a need another point of view.
Thanks for any help.
BTW, is anybody concerned with this ? I'd imagine anyone metering gas with the same kind of meter would be.
Re: khw_to_power
I've looked at it for my Elster water meter (one pulse ever 5L consumed). With water (and probably gas) the quiet times between pulses usually do mean a consumption rate of 0. Every time I try to get my head around calculating flow rates I convince myself it's an intractable problem, and end up just calculating daily usage and then looking for anomalies there.
The problem is there's no way to distinguish between:
. a late night dishwasher run where the meter stops just before the next tick, followed by a glass of water the next morning that causes the tick, and so looks like a 5L glass of water.
. a dishwasher run where the meter stops just after a tick, followed by an all-night slow dripping leak somewhere that consumes 4.99L, followed by a glass of water the next morning that causes the tick, and so looks like a 5L glass of water.
The LED on my electric meter is somewhat similar in that it only counts import, so it typically stops flashing at sun up and doesn't start again until sundown, and it is trying to tell me 0 consumption for the duration.