As the world settles into this pandemic, some things are still difficult to mentally reckon, such as the day of the week. We featured a printed day clock a few months ago that used a large pointer to provide this basic psyche-grounding information. In the years since then, [Jeff Thieleke] whipped up a feature-rich remix that adds indoor air quality readings and a lot more.
Like [phreakmonkey]’s original day tripper, an ESP32 takes care of figuring out what day it is and moves a 9 g servo accordingly. [Jeff] wanted a little more visual action, so the pointer moves a tad bit every hour. A temperature/humidity sensor and a separate CO₂ sensor output their readings to an LCD screen mounted under the pointer. Since [Jeff] is keeping this across the basement workshop from the bench, the data is also available from a web server running on the ESP32 via XML and JSON, and the day clock can get OTA updates.
Need a little more specificity than just eyeballing a pointer? Here’s a New Times clock that gives slightly more detail.
The writer(s) continue to have the same problem with significant digits, accuracy, and resolution; see https://hackaday.com/2018/06/03/6-weather-station-goes-where-you-do/
Not a bad decision. That way you can see the poor performance of the DHT22 in its full glory.
Using the mhz19 with automatic calibration indoors adds to the uselessness.
FWIW, the LCD displays 4 significant digits (at normal household temperatures) to accommodate the optional Celsius -> Fahrenheit conversion. If you display in Celsius, you see the three significant digits as reported by the sensor (for the DHT-22 case). And the humidity always displays with 4 digits so it lines up nicely on the display. Since any sensor could be dropped into this design, being fixated on the issue of accuracy and significant digits seems a little petty. But I am open to any pull requests you are able to provide to improve the project.
As for the MHZ-19B, I’ve been very happy with it as a measure of the air quality. It has some quirks but I’m not trying to put Mauna Loa out of business, so the absolute values aren’t as important to me. The overall trends absolutely line up with events such as entering the room in the morning or opening a window. And more importantly, extreme values correspond to physical effects that I normally wouldn’t have associated with higher CO2 levels.
For example, this is the current state of my data: https://imgur.com/DTpPN0o
You can see when when I opened the window (more) around 3:47 PM, when the air conditioning kicked on at 4:42 PM, and shut off about 30 minutes later. And you’ll be pleased to see that the values for this data source are rounded and provided to 3 significant digits…
And yes, the accuracy and resolution of the DHT22 (I also have a DHT11) is probably the most disappointing part of the current state of my build. For almost free, it is good enough to add in though.
Do you want to measure a value or just see a trend? Most of the time trend values are easy to get and useless. Who wouldn’t think that humidity and CO2-level raises when more persons are longer times together in a small room? This anecdotal “I feel droopy, must be high CO2” combined with confirmation bias to validate a measurement… An entire industrie earns money this way, selling sugar pills to cure diseases. Not very scientific. I digress.
The mhz19b is a great sensor, the DHT-series are only good for trends. Have a look at http://www.kandrsmith.org/RJS/Misc/hygrometers.html for, well, humidity sensors.
As far as I understand the mhz19b-autocalibration process it assumes that the lowest CO2 level within 24 hours is 400 ppm. This is a good assumption if the sensor is outdoors at a well ventilated place. Inside my flat, sensor in a bookshelf not really near the window, I never reached that level any time (unless I open a window for a long time, which is unpractical during winter). So I did the outdoor-calibration once a time and then turned autocalibration off. Hopefully it doesn’t drift much over time.
I would replace the DHT22 with a BME680. This gives additional fun with the mysteriouse “quality of air” values.
For CO2 I would give the Sensirion SCD30 a try. It does temperatur and humidity, too. Quote from its datasheet about automatic self calibration “When activated for the first time a period of minimum 7 days is needed so that the algorithm can find its initial parameter set for ASC. The sensor has to be exposed to fresh air for at least 1 hour every day.”
The excellent library[1] that I’m using to read the MH-Z19B disables automatic calibration by default. I looked at a couple of libraries and WifWaf’s seems to have the best implementation for dealing with the MH-Z19B’s quirks. I have no expectation that the PPM value is accurate or calibrated, but for my purposes it is more than sufficient. I have data going back to March, around 650,000 readings, and there doesn’t seem to be any notable drift or unexpected data other than spurious readings. [2]
The SCD30 looks interesting although it is significantly more expensive than the MH-Z19B and as you mentioned it looks like if you don’t babysit it daily you may not be able to trust the values anyway. That’s way too much effort for my “protractor super glued to a LCD panel” needs… For the extra money, I think the BME680 suggestion is the best one. If I didn’t have the DHTs sitting around already I would go with that sensor just for the barometer.
Finally, as for the “Who wouldn’t think that humidity and CO2-level raises…” comment – I think the answer is a lot of people, including me. There wouldn’t be so many studies[3][4][5] that attempt to determine the relationship between CO2 levels and performance if it was obvious.
[1] https://github.com/WifWaf/MH-Z19
[2] https://imgur.com/yd6jC9W
[3] https://pubmed.ncbi.nlm.nih.gov/25117890/
[4] https://pubmed.ncbi.nlm.nih.gov/11062927/
[5] https://www.epa.gov/sites/production/files/2014-08/documents/base_3c2o2.pdf