If we can do this in this thread (otherwise separate into a new one), I'll give a kick (constructive comments only ) :mcrossley wrote: ↑Mon 08 Feb 2021 11:49 amIt does! But implementing this will probably mean dropping device specific data and like the weather data just storing common attributes. If anybody wants to kick off a discussion on the attributes to store then that could be beneficial.HansR wrote: ↑Mon 08 Feb 2021 8:40 am And beyond that: nobody reacted on my remark above about:Do I have to interpret this lack of reaction as 'the datamodel will just expanded be with every AQ device'. That seems weird as the meteo stations do share tables and fields. Multiple meteo stations require multiple instances of CMX. Should multiple AQ stations not require the same?
- I think indeed device specific data is not required (unless anybody can convince me). Like temperature, PM or CO2 (NOx or whatever chemical you wish to measure) concentration is a measurement;
- Differences between devices (e.g. a GW1000 has PM and CO2, a PurpleAir has only PM) are only reflected in validity of the data and whether they are displayed.
- The number of AQ devices must be limited (e.g. no more than two or three)
- Cycle of storage must be limited like the meteo data (1, 5, 10, 20, 30 minutes). Storing every minute a value for every measurement is pretty extreme and for historical data hardly necessary. So the monthly AQ data can be reduced. Otherwise: consider compression of the data after month completion (and decompression when required).
- Derivatives like nowcast, averages etc... can be calculated or supplied by the device. That should be handled by the device driver.
- It needs to be decided which derivatives will be carried by CMX (just like all (weird) temperature derivatives). As CMX is truly useful anywhere, the data model should not be the limit but the user choice should in what he wants to display (in page or graphical)
- If history is not supported: don't bother, a reboot of the sensor just restarts the measurements and averages.
- Use one Airquality table for PM (for up to n devices) either device support in row length or device support as a record identifier
- Use one AirQuality table for Chemical (for up to n devices - typically 4: CO2, NO2, NO3 and a fourth (SO2 or organic etc...). Same for device support as above.
- Device support is not that distinction between devices is made but that you know which devices measured what. Especially when using SQL it is very easy to make sub-selections like this.
- Store the PM current (minute) values, hour averages, 3 hr, 24 hr and nowcast values in the same frequency as the meteo values
- Store gasses concentrations in the same frequency as the meteo values
- Make these values accessible for graphing (selection by the user) just like the meteo values (this could be extended)