Further improvements
Wow, you've built a complete CO2 meter with smart capabilities, all from scratch! I'm super proud of you!
If this workshop has scratched an itch for you and you'd like to go a bit further down the rabbit hole I've listed some ideas and resources here to get you started.
Some of them are implemented in the final firmware you can find on the master branch of this repository. So don't hesitate to have a look!
Tasks and threading
Did you notice your device seemed to hang when it was sending an HTTP request? This is because all the code we've written runs one after another. It might have even felt a bit iffy while writing it. To fix this problem our microcontroller runs a RTOS (real time OS). This gives us many possibilities to fix this problem. Try to offload the sending of notifications and logging of data to a separate task. Check out the following materials:
Mutexes and Semaphores
What if we put everything the device does into separate tasks? Reading data, updating the display, saving the calibration data, ... . We might run into problems when for example the "Read data" task and the "Save calibration data" task both try to access the CO2 sensor at the same time. This is where mutexes and semaphores come in. Try to request access to the sensor in both tasks using a mutex:
Code style
Up to now, most of our code exists in one huge main.cpp file. Read up on C++ code organization to make everything tidy.
Monitor WiFi connection
What if our WiFi password changes? The device has no way of reconnecting or notifying the user something is wrong. Write a task to see if our connection is still alive and allows the user to reconnect or reconfigure the WiFi.
Watchdog
What if our device hangs on a specific function? Maybe a reboot would get everything running smoothly again. This is where Watchdogs come in. Implement a Task Watchdog that monitors for long running tasks and reboots the device if something is taking far too long.
Change parameters at runtime
What if we'd like to change the URL the notification gets sent to without resetting the device or rewriting a part of our program? Maybe the device listens on it's USB Serial port for a message to change it? Maybe it can spin up a web server where you can update this information? Get creative!