ericklein
commented
2 years ago I've implemented this change in nvstorage branch and will promote after testing is complete. The new core data struct is:
typedef struct { float internalTemp; float internalHumidity; uint16_t internalCO2; int extTemperature; int extHumidity; int extAQI; } envData;
To handle data persistence, extra variables I create mimic the core struct's data types.
Currently sensor readings are converted to integers as part of acquiring values from the sensors (both attached sensors and through getWeather(). That's probably fine for what's shown on the display, but causes loss of precision given most of our sensors are more accurate than that, the data is now also being shared with other services (e.g., MQTT and Dweet), and we've also talked about adding database support to store values for subsequent analysis, alert triggers, IFTTT, etc.
I propose we store data internally as floating point wherever relevant and convert it to integer or fixed point wherever necessary -- in the code that displays values on the eInk display, before they get sent to other services, etc.
This would require changing the envData typedef/struct to use floats rather than uint16_t, at least for temperature and humidity values. (Our current CO2 sensor returns readings as an integer, so CO2 values could stay uint16_t.) There would be minimal change in readSensor() and getWeather() as in most cases conversion from the floating point sensor values to integers happens implicitly via the compiler through assignment. (The exception here is temperature, which gets converted from C to F and then cast as an integer.) Some change would also be needed to infoScreen() to properly format floats as integers (or fixed precision) for display.
I like the idea that we'd retain whatever values sensors provide as our internal data model and let any code using that data for display, sharing, export, storage, alerts, etc. do the right math at the point of use, whatever that may turn out to be (and which they know best anyhow).