AirGradient Forum

Compile issues with current version (3.3.9 or 3.4.0)

#1

Working to setup a build environement for the AirGradient firmware, to allow me to make potential “tweaks” to the monitor firmware.

Followed the procedure for IDE setup (have been doing numerous Arduino projects, so my baseline is good).
Added the ESP32 device and did the git clone of the Arduino libarary. Compile tries to run, but errors with:

/tmp/arduino_build_749163/sketch/OneOpenAir.ino.cpp -o /dev/null -DARDUINO_LIB_DISCOVERY_PHASE
Alternatives for Libraries/airgradient-client/src/common.h: []
OneOpenAir:39:10: fatal error: Libraries/airgradient-client/src/common.h: No such file or directory
ResolveLibrary(Libraries/airgradient-client/src/common.h)
→ candidates: []
#include “Libraries/airgradient-client/src/common.h”
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Using library AirGradient_Air_Quality_Sensor at version 3.3.9 in folder: /home/tadawson/Arduino/libraries/AirGradient_Air_Quality_Sensor
Using library Wire at version 2.0.0 in folder: /home/tadawson/.arduino15/packages/esp32/hardware/esp32/2.0.17/libraries/Wire
Using library EEPROM at version 2.0.0 in folder: /home/tadawson/.arduino15/packages/esp32/hardware/esp32/2.0.17/libraries/EEPROM
Using library ESPmDNS at version 2.0.0 in folder: /home/tadawson/.arduino15/packages/esp32/hardware/esp32/2.0.17/libraries/ESPmDNS
exit status 1
Libraries/airgradient-client/src/common.h: No such file or directory

Note also that this path is explicitly called from the OneOpenAir.ino file in the examples tree in the AirGradient_Air_Quality_Sensor library, no matter how it is uploaded, and in both the 3.3.9 and 3.4.0 versions.

Notably, nothing in the directions, imported library (either via library install, git clone, or the 3.4.0 (latest) .zip release provides this path or file. I did find what looks like “airgradient-client” in git, which has it, but the build environment does not seem to be able to find it, even when placed in the failing path, perms correct, and the IDE restarted.

Is the doc deprecated (or flat out wrong), or ? ? ? This shouldn’t be this difficult . . . You guys build it, so one would think the build process and environment would be extremely well known and documented . . .

Thanks,

  • Tim
#2

Were you following directions from:

I just installed ArduinoIDE and Git on a clean Windows and followed those instructions and I’m getting errors, but different than what you are seeing. I was successful in doing this when the document was last revised:

In file included from c:\users\wdagutilityaccount\appdata\local\arduino15\packages\esp32\tools\riscv32-esp-elf-gcc\esp-2021r2-patch5-8.4.0\riscv32-esp-elf\include\c++\8.4.0\bits\ios_base.h:46,
                 from c:\users\wdagutilityaccount\appdata\local\arduino15\packages\esp32\tools\riscv32-esp-elf-gcc\esp-2021r2-patch5-8.4.0\riscv32-esp-elf\include\c++\8.4.0\ios:42,
                 from c:\users\wdagutilityaccount\appdata\local\arduino15\packages\esp32\tools\riscv32-esp-elf-gcc\esp-2021r2-patch5-8.4.0\riscv32-esp-elf\include\c++\8.4.0\istream:38,
                 from c:\users\wdagutilityaccount\appdata\local\arduino15\packages\esp32\tools\riscv32-esp-elf-gcc\esp-2021r2-patch5-8.4.0\riscv32-esp-elf\include\c++\8.4.0\sstream:38,
                 from C:\Users\WDAGUtilityAccount\Documents\Arduino\libraries\arduino\src\AgValue.cpp:6:
c:\users\wdagutilityaccount\appdata\local\arduino15\packages\esp32\tools\riscv32-esp-elf-gcc\esp-2021r2-patch5-8.4.0\riscv32-esp-elf\include\c++\8.4.0\system_error:39:10: fatal error: bits/error_constants.h: No such file or directory
 #include <bits/error_constants.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
exit status 1

Compilation error: exit status 1

I rolled back my folder in git all the way back to 3.3.4 although I don’t think just doing a git checkout 3.3.4 also rolls back the submodules. I still get the same error.
Since mine is different, it could be something different that I’m doing, but I can open an Issue on the Github to get the conversation started.

#3

Exactly, and, as I recall, did a cut and paste of the clone command . . . . After more review, it looks like I didn’t get the -ova and -client libraries in the clone . . . I’ll try again tomorrow, and if needed, clone those repos separately.

I note that the later versions now also appear in the available Libraries in IDE 2.3.6 as well . . . Is there still a need to git clone directly? )I recall trying both, but might have been prior to noting the massive downrev needed for the ESP32 libs . . .)

FWIW, I’m on Linux . . . I’ll update more tomorrow.

Close . . .

#4

OK, resolved . . . . Turns out that after I had dome the clone (expecting 3.4.0, since it was showing as the most revent released) and still seeing it tagged as 3.3.9, I had grabbed the tarball from “Releases” (which is typically the same as a clone on most repos) and it doesn’t contain the two sub libraries. Did just the recursive clone again, and whatever variant the master branch is on, now builds cleanly.

So, consider my issue resolved.

#5

@Malloc_Alley, to me it looks like you either ended up with the wrong (or incomplete) ESP32 board libraries, since that is what your missing file is a part of.

Not sure if you did so or not, but note the need to severely downrev those to 2.1.7 (now at 3.x.something) as per AirGradient).

FWIW, I’m on the latest IDE (2.3.6) with the suggested ESP32 lib and version (EsspressIf 2.1.7) andnthe latest source on Linux, and I am building fine.

(Now to start playing with it! My main goal is to adjust where batch corrections are applied, since I see the “Raw” data on units needing same a garbage, since those are a hardware “fix”, not a correction algorithm like EPA, and feel that they should affect “Raw” and then the EPA stuff only affect the other. This is likely why myndata on the AG map is crap, while a guy close to me looks OK - he likely has the older, inherently more accurate sensor, and the raw dara used on the map coming from mine is 100% useless . . . )

#6

I had made sure to pic 2.1.7 for the board manager, but maybe it goofed. It was late and I didn’t feel like retrying it all over again.

Glad you got it resolved with the git clone with the recursive flag.

The best fix is for AirGradient to fix their stuff so the AirGradient Map uses the corrected values natively, rather than you have to patch your local device so the raw values it provides is actually corrected.

I’m not sure why they did it that way and I’ve had discussions in the past about making the main value be the corrected one and then have a separate Raw value, but the direction they went after discussing with their data science team was to have the main value be the Raw, and a separate value for the compensated, but seems like they aren’t using the compensated value as what the map is based on.

#7

No argument on the map fix, but since it seems that what should be an obvious/trivial fix has been hanging out there for at least a year, my faith in a timely resolution is quite low . . . One would think that this would have priority, since it pretty much invalidates AG as a valid data source to the world . . .

(Oh, and “main value be the compensated one” was basically what I was thinking of hot-wiring to test . . . )

Odd also that the dashboard uses the corrected values as well,mas does Home Assistant . . . . seems like the only thing using raw is the map . . .

On your ESP stuff, if you have another system that works, you might want to compare what is in the path in your error to see what actually landed there . . .

#8

Oh, and one more thoughtnon the map/batch correction topic.

I would arguenthat the raw values should have only the batch correction applied, and the compensated value should have them all. The batch correction is basically used to correct a hardware issue to get valid raw data prior to applying other corrections. This way, “baseline” PM values are still available, as well as those with localized corrections, as was the case in the initial design before Plantower got wonky. (Heck, the best soultion would be for Plantower to quit hiding behind it’s “it meets specs” BS argument, and revert the sensor to it’s prior level of accuracy . . . )

#9

Yeah, the git submodule thing is an annoying gotcha. It’s a pain to keep the main branch correctly sync’ed with the submodules.

I wrote instructions for flashing from the command line if that’s helpful: Flash an AirGradient ONE from the Command Line · mtlynch.io

#10

Thanks, but I find the Arduino IDE too easy to have any urge to flash from the CLI, especially since I am compiling as well. The big thing that bit me was trying to use the release tarballs for specific versions, which don’t have any flavor (or even stub dirs, as I recall) for the submodule libs.

#11

I just followed your blog the other day to build 3.3.9!

I was happily using the IDE in my GUI previously, but I am more of a CLI guy anyway so your post made that transition super easy. Thank you for posting that for the community.

1 Like