OneWire library throwing a boatload of errors

I wrote a Photon app a few months ago, and it worked fine. Now I’m revisiting it to enhance it, and I’m getting a whole bunch of errors. Googling “OneWire/OneWire.cpp:135:15: error: ‘INPUT’ was not declared in this scope” results in exactly one hit, in these forums I believe, but I couldn’t find a followup thread that solves it. Here is part (but not all!) of the error dump:

OneWire/OneWire.cpp: In constructor ‘OneWire::OneWire(uint16_t)’:
This looks like an error in OneWire library.
Would you like to create an issue on GitHub to let the author know?
OneWire/OneWire.cpp:135:15: error: ‘INPUT’ was not declared in this scope
pinMode(pin, INPUT);

There are probably 40 or 50 similar “not declared in this scope” errors.

I tried compiling a file I found somewhere (I don’t remember where) called “sparkcoreonewiretest” and it does the same thing.

Any help would be appreciated!



Try using this lib instead

Search the forum for “DS18b20 photon” to see various discussions. One included below:

Thanks Mr. Network, I’ll give that a shot. Wow what a fast reponse – you da Mister.

I wonder why it worked 5 months ago, though…


OK upon reading some more about this, I now realize that my issues are because I switched to a Photon from my original Core that I developed the code on. I naively assumed they were bit-compatible, at least at the library level. Doh!

One more comment – I found another “OneWire” lib that is already in Build. Just re-pointing to that library (via the Include in App feature of Build) fixed everything. The Particle-OneWire lib would’ve required code changes – maybe quite a few. The new OneWire one seems to be backward-compatible with the one that I used with my Core.

1 Like

Yes - They must have updated the main lib in the interim!
I just changed mine back (from when I originally ported them for the Photon).

Thanks! :smile:

Hello Guys!

I’m also having a bit of headache with the OneWire library. Whenever I try to use the OneWire type in a file other than the main .ino file or if I try to pass a parameter of type OneWire to a function, I get this error:

'OneWire' does not name a type

Any idea what’s causing this? It’s pretty ugly that the library’s code can only be accessed in the main .ino. Makes the code messy. Or Am I doing something wrong?

I’m using the web IDE at


That’s not ugly but very normal in C.
Each file needs to include the needed headers to make non-keywords known to the compiler.
Each file gets compiled as seperate module and only gets linked to the others after all modules have been compiled successfully.

No, no, I know that :slight_smile: But even if I include it or pre-declare the class, it still doesn’t accept it as a type. It must be some Arduino-like wizardry, definitely not a C or C++ mechanism.

Even in the main .ino file I can’t use OneWire as a normal type:

OnewWire obj (PIN); //This works

void func (const OneWire& obj); //This gives error:'OneWire' does not name a type

I checked the OneWire type definition in the OneWire library header and it’s declared as a normal class. So there must be some Arduino-like wizardry involved here.
One guy mentions on the Arduino forums that this error can be cause by not having your library source files in the right place within the libraries directory. But since I’m using the online IDE, I have no control over where the library source files are…

Another strange thing is runtime behavior.
If I declare the OneWire object on the stack at the top of the main .ino file, the temperature reading works fine:

OneWire obj (PIN); //Temperature reading works later

But if I declare a OneWire pointer and I allocate space for the object on the heap in the setup function, the temperature reading fails:

OneWire* obj;
void setup ()
  obj = new OneWire (PIN); //Temperature reading fails later


I’ve just tried this code and it compiles

// This #include statement was automatically added by the Particle IDE.
#include "OneWire/OneWire.h"

OneWire obj(D1); //This works

void func(const OneWire& obj); 

And it even builds when having the prototype for your fn() in its own header and the implementation is the respective .cpp file.
like this

// test.h
#ifndef _TEST_H_
#define _TEST_H_
#include "OneWire/OneWire.h"

void fnc(const OneWire& obj); 
// test.cpp
#include "test.h"

volatile int i;

void fnc(const OneWire& obj)
// test.ino
#include "OneWire/OneWire.h"
#include "test.h"

OneWire obj(D1); //This works

void setup() { fnc(obj); }
void loop() { }

I guess your problem was that you hadn’t actually instantiated an object by calling the constructor.

And for your pointer version, how do you call the methods of your OneWire object?
In what way does it fail?

Thank you, ScuffR!

This is very strange… I don’t understand how it works for you to pass it as param and to put it into another file and why the same thing does not work for me…

If you look at my example in my previous post, I did instantiate the class in the setup() function, like this:

obj = new OneWire (PIN);

By failing, I mean that somewhere in the temperature reading something fails and ultimately it returns 0 degrees instead of the actual temperature.

I don’t want to spam this forum by posting the whole source code here…

Have you tried just copy-pasting my code into your Web IDE and build that?
What device and firmware version are you building against?

You did instantiate for the pointer test but not here

And there was a typo, so this should not have worked (contrary to the comment ;-))

Firmware used to build is the latest (0.4.5) and the device is a Photon.
Yes, there was a typo, but in the IDE it was correct :smile:

As soon as I copy for example this line of your code into my IDE, it starts giving me the error (“OneWire does not name a type”) :

void func (const OneWire& obj); //ScuffR's code, compiles fine for him, not for me

The only thing that I have in my main .ino file before the point where I pasted your code is this:

#include "LiquidCrystal_I2C_Spark/LiquidCrystal_I2C_Spark.h"
#include "OneWire/OneWire.h"

#include "TimeUtils.h" //Some header of mine, nothing interesting in it, just some simple functions
#include "Temperature.h" //Some header of mine, nothing interesting in it, just some simple functions
#include "SystemUtils.h" //Some header of mine, nothing interesting in it, just some simple functions

const int OneWirePin = D2;

LiquidCrystal_I2C* lcd = NULL;
OneWire oneWire (OneWirePin);
byte oneWireAddr[8];
int lastSecond = -1;

This should not interfere with the OneWire library code…

Don’t try to past one line of my code into your file, use my whole sketch and move forward from there by adding one library after the other and always verify/build each state and then add your own files and finally your own code bit by bit.

When you get an error you’ve found the culprit - it’s obviously not the OneWire library as such, as it just compiles with my sketch.

Just for extetics I think you should not have these blanks between the function name and the parameter list.

BTW: I doubt this worked even without the typo, since it’d expect a public OneWire::OneWire() which isn’t there.

The public constructor requires one parameter which you don’t provide by writing it this way.

Thank you, ScuffR!

Yes, sorry, I forgot to add the int parameter to the constructor. I’ve edited my previous posts and added it now.
About the spaces between the function names and the brackets… I’m used to writing it that way. Our coding style at work requires it.

Ok, I’ve tried pasting your whole code from your .ino file into a new app:

// This #include statement was automatically added by the Particle IDE.
#include "OneWire/OneWire.h"

OneWire obj(D1); //This works

void func(const OneWire& obj); //OK

And it works… as long as the function func does not have an implementation. Try adding an empty body to function func and it immediately starts not compiling. :wink:

// This #include statement was automatically added by the Particle IDE.
#include "OneWire/OneWire.h"

OneWire obj(D1); //This works

void func(const OneWire& obj) {} //Ooops! "Error: 'OneWire' does not name a type"

I dare to contradict again.

This does build just fine.

#include "OneWire/OneWire.h"

const int OneWirePin = D2;

OneWire oneWire(OneWirePin);

void func(const OneWire& obj) { }

I also had code in the function, I also had other functions (besides setup() and loop()) between prototype and implementation and I had things divided in several files (as above) - it just builds fine.

But I would avoid to have an object named the same as a parameter of a function in the same scope, as you are reusing obj above.

This is becoming extremely awkward…
You’re right, if I paste your code, it works:

#include "OneWire/OneWire.h"

const int OneWirePin = D2;

OneWire oneWire(OneWirePin);

void func(const OneWire& obj) { }

But the same exact code (letter-by-letter identical) written by me does not work. I’m trying to figure it out…

Unbelieavable! I paste the following two pieces of code into the very same .ino file while it has nothing else in it:

#include "OneWire/OneWire.h"

const int OneWirePin = D2;

OneWire oneWire (OneWirePin);

void func (const OneWire& oneWire)

This one (above) works.

#include "OneWire/OneWire.h"

const int OneWirePin = D2;

OneWire oneWire (OneWirePin);

void func (const OneWire& oneWire)

And this one gives error: “Error: ‘OneWire’ does not name a type”

I can’t see any difference between the two…

OK, I have figured out the difference. The above two pieces of code are indeed identical. The difference was that for the one that did not compile there was a blank line before the first line of code (before the #include statement). And this is what makes the difference. If there’s a blank line before the include (anywhere before it), you get the compilation error. So weird!

Well, it seems that anything before the OneWire include causes the error, not just blank lines but any line of code before it.

So I moved the OneWire include to the first line of the .ino file, and it works. But this is soooo very strange…

That is strange in deed!

Especially since there was an exactly opposite issue a long time back when things only worked with a blank first line.
Maybe something @suda wants to know of.