I asked this question a while ago and the answer got rather side tracked!
I also asked previously about a rate of change calculation, actually, if these stats were available (for this use case, Diff), and I knew the time period over which I had requested the data, I could easily calculate a Rate of Change.
My use case is to determine whether heating is required and that is to some degree dependent on rate of change of external temperature.
I could store the data in Node-red and do it, but that seems daft!
As a point of note, the data viewer exports the data in milliseconds. Is this deliberate or is this just because Javascript always uses date/time in milliseconds? Internally I am pretty sure seconds are used (I could be wrong).
I did answer on that thread (although it did get buried by significant side tracking)
Looking closer at the code, there are api endpoints for average but not for min and max etc
This tallies with the phpfina engine only having functions for average but no mention of min and max functions.
However, there doesnāt appear to be any mention of average in the phptimeseries engine so use of the āaverageā feed api must be limited to phpfina only.
The graphs calculate these things āon pageā as it were, I too think it would be very useful to have api endpoints (and the functions in the feed engines if needed) so that we could query that data directly, as then could the graphs page and apps etc thus reducing the need for any duplication of the calculations, it would offer consistent results from one place (per engine?).
I believe use of millis is indeed due to the use of JS, but the lowest resolution emoncms can work to is 1 second so the end 3 zeros in any unixmillis timestamp are just padding.
Seems there is no mention of the feed/average.json api endpoint in the main repo feed api help page, only the emoncms.org help page shows it, but I have just confirmed itās working on my own server.
I dug through the code a bit more and realised that those āstatsā are calculated using a javascript library I think. Iāll look for a different solution.
Yes thatās correct, a specific feature of the graph module Im afraid. Again If anyone would like to help with adding min/max API end points for date ranges as you suggest I would be happy for these to be added, Ideally building on the existing feed/data API rather than a full search of the underlying data as that will have scaling issues on multi user installations.