#Include frustration (ScruffR: with Digistump Oak and Libs 2.0)


I have been trying for several days now to include Neopixel and DHT libraries on both Particle Build and Particle Dev both can’t find the header files.

The InternetButton library for example works fine on particle Build without any fiddling just following the add library method, why are the other libraries different?

Particle Dev I have gotten the furthest on by using “…/Adafruit_DHT.h” it can’t find it without the …/ in front, which i can’t find anyone else mentioning on the Forum?

It doesn’t work with “Adafruit_DHT/” in front and i can’t seem to steer the compiler to it with “lib/Adafruit_DHT/src/”. it just always looks in the project src folder. Am I doing something wrong?

Now it has found Adafruit_DHT.h (as i moved it into the project src folder) it wants application.h which then wants all the additional headers within that which is getting silly.

Searching the Libraries i can’t add a “Spark” “Arduino” or “application” library, which are all the basic functional libraries which from the forum the Particle Build IDE seems to include automatically?

Can someone help please?

How are you adding the libraries in Dev? They should show up under the project.properties folder, not directly under src. After adding the libraries from the library icon, I included them like this, and it compiled just fine,

#include <neopixel.h>
#include <Adafruit_DHT.h>

In the project.properties folder, they looked like this, so this is where I got the names I should use for the include directive.


I have tried link to project and copy to project.

I can see Link to project adds it to the project.properties folder and doesn’t include the library files themselves but that doesn’t work either.

I get Adafruit_DHT.h no such file:

Heres the dependancy in project.properties:

I get the same result with “” or <>.

What else can i try?

If you don’t intend to alter the libraries it’s advisable to just link the libraries rather than copy them to your project (providing it’s supported for your platform).

But if you copy them to your project the library files should end up in the lib subdirectory as


And you should remove the examples folders from copied libraries.

BTW, for me all three includes build as expected

But what I think the actual cause of your trouble is that you are targeting a Digistump Oak which may not yet support Libraries 2.0
Hence I think the currently only working way for you is to copy the library to your project and have the includes accordingly (I’ll post back once I’ve tried how).

The target platform and system version are always crucial informations that should be explicitly stated in the opening post - maybe even in the topic title.

OK thats why none of the fixes I have found have helped.

Is there a way to roll it back to Libraries 1.0? or is it built into Particle cloud now.

thanks for looking into it :smile:

I have been playing a bit with Particle Dev and as it seems that’s not a Libs 2.0 issue, since not even the simples project without any extra libraries can be built.

//#include "application.h" // not known
//#include "Particle.h"    // not known

void setup() {
  pinMode(D7, OUTPUT);     // D7 not known

void loop() {

@suda, any idea what’s wrong?

@ScruffR I tested your example and it seems to work in Particle Dev.

@Arc unfortunately there’s no way to rollback to Libs v1. There seem to be couple of issues here:

  • Neopixel library depends on “application.h” which isn’t present in Oak firmware so this seems that neopixel library isn’t compatible with Oak
  • Oak doesn’t support Libs v2 but by using relative paths (#include <../lib/NAME/src/NAME.h>) you can get around that
  • Current version Particle Dev flattens the project structure. We’re going to release fixed version soon but until then you can install particle-complete package in Atom which already contains the fix

@suda, not for me tho’

Or is there no D7 pin on Oak?

And the missing Particle.h and application.h will produce issues on almost every library since most of them will include these.

Nope it does not have D7: https://digistump.com/wiki/oak/tutorials/pinout

Yup, but this had to be a problem before libs V2. I think Oak exposes itself as Arduino so if a library is both Arduino and Particle compatible then it should work fine. The solution for this would be bringing Particle support to upstream libraries and using them instead of custom forks.

Ok it seems the Oak isn’t very well supported on this platform, I’m going to try the Arduino IDE more and try to get the Particle library into that.

I tried adding the DHT library using relative paths like you described but it didn’t work. Have i still got something wrong?

Standalone Particle Dev with the fix for this hasn’t been released yet. For now you can install regular Atom and particle-dev-complete package which will give you the latest version.

1 Like

OK thanks for your help @suda