Fix calculation of average for values with not equally spaced samples

[carhe]

In the following, I assume that the term "average" is meant to be the same as the mean of a measure.

Describe the bug
Calculation of average does not work right for values with not equally spaced samples.

To Reproduce
Steps to reproduce the behavior:

1. Choose some analog measure to test with. The effect can be observed very easily if value changes every some seconds.
2. Enable history logging for the measure with the option to store only changes.
3. Wait until 2 or 3 changes have been recorded and fed to the average calculation.
4. Except for rare special cases, the computed average will be wrong.

Expected behavior
Compute the correct result (see below).

Versions:

• Adapter version: 1.0.9

Background

The reason for this problem is the way how averages are computed, which does not cover the general case of not equally spaced samples (it only works with equally spaced samples).

In general, the mean m of an analog signal x in the time interval T is defined as m = 1/T * integral_T x(t) dt. For sampled (i.e. discrete time) measures, this translates into m = 1/T * sum x_i * delta t_i with delta t_i = t_i+1 - t_i. In other words, each x_i must be weighted by the period of time for which it has been active.

Currently, the average is calculated as follows: m = 1/N * sum x_i with N being the number of samples. This gives the correct result if samples are equally spaced (i.e. delta t_i is some constant independent of i), but not in the general case.

Example

I monitor the outside temperature at my home with a resolution of 1 K. A sample is recorded whenever the temperature changes, or if there has been no change for a long time (e.g., 1 hour). Now let's say I record the following temperature profile: 1°C at 0:00, 2°C at 0:05, 3°C at 0:10, 4°C at 0:15, 5°C at 0:20, 5°C at 1:20 (i.e., no change between 0:20 and 1:20). The correct mean would be m = 1/80min * (1°C * 5min + 2°C * 5min + 3°C * 5min + 4°C * 5min + 5°C * 60min) = 4,375°C. But currently, the computed result would be m = 1/6 * (1 + 2 + 3 + 4 + 5 + 5) = 3,33°C, which is far from the correct result (note that the temperature has been < 4°C for less than 15 minutes and >= 4°C for 65 minutes).

The way of computing the result should be fixed to work for the general case. Unfortunately I have no knowledge about internal iobroker structures or even Javascript to be able to provide a fix, but I think fixing this issue is a low-hanging fruit (clear improvement, should not cause much effort).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions.
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.

[carhe]

The problem is still open and relevant. The reproduction steps did not change.

I am wondering if nobody else is interested in this, as this is a rather fundamental problem that makes the plugin produce wrong results for all but equidistantly sampled values. Or do people just not recognize that the results are wrong?

[ixperte]

I also have problems with non equaly distributed values for the delta option. Unless for the 15min range, all values are wrong. Is there any progress expectable? Otherwise i have to progeam it with blockly by my own. I would prefer to use statistics

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions.
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.