This doc handles one device point of view. Values, changes, and statistics concerning multiple devices are handled elsewhere.

Data are updated from clients roughly every 300 seconds - every 5 minutes.

Data are of two types - numeric and textual.

There are two primary metric that the user can be interested:

(1) numeric values and their changes (and magnitude of the changes)
    - this metric is primarily linked to the numeric values
    - it could be also used for storing event counters instead of real data. Example is a number of reboots over a period of time. See (2) below for additional info.

(2) more/less static textual values and date of their change (ideally accompained with info about change source)
    - this is primarily associated with the textual values
    - it is also associated with storing timestamps. For example, the number of reboots above can be ebhanced with a timestamps of last x such events.



----- Part 1 - numerical values, averages etc. -----

To be able to compute running averages, data samples must be stored. There is a way how to save space at the cost of loosing some precision.

The last changes of a value may be interesting. Thus, storing last three samples directly is good.

This way, running average of last three samples is available always. That means there are data representing now, +5minutes, +10minutes and +15 minutes available. Next to that, a previous 15-minute average could be shown.

Every 15 minutes, 15-minute average is stored, entering computation of gradual average for one hour.

Every hour, hour average is replaced by gradual hour average and old hour average enters computation of gradual 6-hour average.

This mechanism is applied in cycle. The granularities are:

Data policy 1 (only stored data, the computed ones are not stored):

5-min value - 2x (+actual = 15 minutes into next level)
15-min average - 3x (+new value from previous level = 1 hour value to the next level)
1 hour average - 5x
6-hour average - 3x
1 day average - 6x
1 week average - 3x
1 month average - 2x
1 quarter average - 1x

In total, 25x the original data size.

Data policy 2:

5-min value (11x) in-memory ONLY
1 hour RUNNING averages over 1 day (up to 24 samples)
1 day RUNNING average over 1 month (up to 31 samples)

In total:
   in-memory: 13x the original data size
   in-DB: 2x the original data size

Data policy 3:

25-min value (1x)
1-day/month average (2x) (selectable)
lifetime average (2x)

In total, 5x the original data size

NOTE: in full version, the data sets for data policies 1 and 2 (every hour for a number of hours and every day for a number of days) could be stored in DB for later processing.


--- Part 2 --- Textual values and changes track

With textual values, there is no point in making averages (only number of appearance of a same value among a number of devices but that is not relevant when looking at one device).

As for any particular value, it has sense to store actual value and a number of previous ones, together with timestamps for the changes that happened.

Data policy 1 (amount based):

Actual value + date of change
For 15 last changes, keep: value + date of change

Data policy 2 (time based):

Actual value
All changes wihtin last: (selectable): week (day/month/year/lifetime)