disquisitioner
commented
2 years ago I was looking at adding sample averaging to the code already, which might dovetail nicely here. We currently take one sensor reading per reporting interval, which by default is every 30 minutes. We could read the sensors more often and average them, even though we might still only report results on the display and to the cloud every 30 minutes. We'd need to wake up the device more often to do that, which would consume more power, but we'd only need to wake up and power the sensor section at each sampling, not the wifi (or display, MQTT back-end, etc.).
ericklein
Display trend information on display in 12hrs, 24hrs, and 72hrs modes. For the purpose of prototyping, we could use these symbols to represent the data: "/" trend up - data is trending up compared to the previous time segment "\" trend down - data is trending down compared to the previous time segment "-" trend even - data is even compared to the previous time segment.
12 segment is all we need at this time. In 12hrs mode, each segment represents average sample data for one hour. In 24hrs mode, each segment represents average sample data for two hours. In 72hrs mode, each segment represents average sample data for six hours.
If we stay with the current three lines format on the display. Using the left side of the display. The top line would be 12hrs mode, the mid line would be 24hrs mode, the bottom line would be 72hr mode.
Delta triggers from [https://github.com/ericklein/air_quality/issues/7] Temp changes by 1 degree F Humidity changes by 1% CO2 level changes by 25