I’ve edited and supplemented the original post (a query about deriving power from a train of pulses representing energy) so that it makes sense in isolation.
I still maintain that using a pulse to measure power is fundamentally wrong - I’m pretty darned sure that the pulse was never intended for that purpose, I think it was put there primarily as a calibration tool (replacing the black bar on the disc of the Ferraris meter movement) when testing using a known load. A secondary function of course - the flash rate does give the user a rough visual indication of the rate at which energy is being used. However, there are times when the user has no alternative, and for them I think an easy way to obtain power from the pulse count should be kept and at least made usable.
The present kWh to Power process produces, when the pulse rate is low, a very granular result when there a few pulses per reporting interval, and when there is less than one pulse per reporting interval, the power value switches between zero and some large value - typically 720 W. This is problem faced by users unable to use a c.t. to measure power.
Trystan had, in the linked thread, suggested procedures already present on the Graph Module (and in the Input processing) as a solution.
I don’t get that argument - I’ve never tried to use MySQL directly, but surely, if you are using PHPTimeSeries, you can change it so that the database itself is updated only when there is a pulse, therefore by definition it knows the time of the previous pulse (to within 10 s), so the averaging period is to be got from there rather than from the metadata?
You could do that as well - or instead. But it’s not backwards compatible with an existing database. The time period is still controlled (if not defined) to be an integral number of arrivals of data, which could introduce an element of confusion.
I would say yes, because using the graph is not at all intuitive and I’d never found the process you’ve described in the documentation - indeed it would never have occurred to me to look for it in a module whose function I perceive as display-only, especially when all the other processing functions are on the Inputs page.