https://github.com/geerlingguy/airgradient-prometheus/issues...
https://github.com/geerlingguy/airgradient-prometheus/issues...
If you still have issues, please contact me through the link on my profile.
[1] https://forum.airgradient.com/t/co2-reading-of-3-constantly/...
I specifically remember softserial was very problematic, and actually reading the code convinced me to dump it. Might be fixed now, but there's timing code in there that could easily break on a compiler update because it's still written in C++ and has handcounted delays based on counting instructions in compiler output. Now, maybe they recheck those on every single release of avr-gcc to make sure the count didn't change, but why rely on that? We're talking about the same maintainers here who kept conditionally compiled ASM code to manually push and pop the stack in every function because some absolutely ancient MacOS 9(or something like that) version of GCC somehow didn't emit those instructions. That was still there in 2015, hopefully they removed it since then...
It also sets interrupts. I don't like library code doing this at all. I wanted complete control over that so I always know what interrupts might occur. And even worse it uses a circular buffer for storing data but IIRC offers no method of detecting a full buffer. Which led to a lot of "fun" debugging.
Arduino libraries are fine for simple prototyping, but they're not high quality enough for writing reliable microcontroller code.
Sometimes it reports 0 if left on for extended periods, other times the readings are wildly out of range of what the module is listed to support. I have emailed them regarding a different issue and didn't have the best response back and hasn't inspired confidence to raise this one.
On the plus side the module is replaceable and I'll probably just source it myself rather go through support.