mhauru
commented
1 year ago This is related to a wider concern: If we want to make the platform more extendable to other use cases and other types of sensor data, we should have less bespoke code for current sensor types and metrics. Currently if a new kind of measurement would be added, say air pressure, we would have to add a new table for it, add a sensor type, and then write code to make sensors of that type write to the right table, visualisations to read from that table, etc.
A different approach could be to have a "readings" table that would hold all sensor readings, mixing CO2 and temperature and pressure and all that, with an extra column that specifies which metric they belong to, foreign key referencing some metrics table. Then adding a new metric would be a matter writing a row to a table, rather than creating a new table. This would be a lot like how the models handle results from different models and measures. This would still be tied to the sensor readings being of a certain data type, e.g. if some sensor would report categorical rather than float data that would have to be dealt with manually.
Another option would be to use something more like templating to write the structure.py file, so that there would be some config file that defines all metrics, and then ORM classes and corresponding DB tables would be created dynamically based on that config file.
Pinging @nbarlowATI just to discuss this.
There are now CO2 sensors that also report T&RH. Our database model can't handle this elegantly. Currently we simply ignore the T&RH data, because we consider the sensor to be a CO2 sensor. We could fix this by adding a new sensor type, a "CO2 & TRH" sensor, but this gets a bit clunky in places where sensors are separated by type. For instance, the time series plotting dashboard first asks you to select the sensor type, and we would like for such a sensor to appear under both CO2 and TRH types, rather than as a separate "CO2 & TRH" type. This would require ad hoc code for just this particular sensor type.
The way Hyper solves this is that they separate sensor types from metrics, so that temperature is one metric, humidity is another, and CO2 is a third, and different sensor types can report different combinations of metrics. We might move to a similar model, but that would require some surgery in the backend.