problem compiling to Basic.ino/WiFiManager esp32

Try a different board. Maybe just use generic esp32 dev board which will compile, then upload and see if it works. The error appears to be board related and I don't have details as to how to fix but try what I said first.

I just tried using your board and it compiles ok. Check that your libraries and boards are up to date.

douwebakker Are you seeing my responses above?

BTW, what is significance of white vs orange? My screen shows white and it compiles ok.

Hi Ron, thanks for your messages. I'm a little too tired right now to continue. Tomorrow is another day.

Hi @douwebakker,

  Bit of a wild guess here, but maybe the clue is in the last few lines of your error messages:

Multiple libraries were found for "WiFiManager.h"
Used: E:\Documenten\Arduino\libraries\WiFiManager
Not used: E:\Documenten\Arduino\libraries\WiFiManager-master
Not used: E:\Documenten\Arduino\libraries\WhareHauoraWiFiManager-0.15.0

This is saying your system has 3 files called "WiFiManager.h", (in the 3 named different folders) and the compiler might be picking the wrong one.

I just did a search on my system, and the only one showing up is in the equivalent location to the first one.

Sometimes, a system acquires more one copy of the same "xxxx.h file", so it doesn't matter which one the compiler uses, but in other cases the files are different, and picking the wrong one will cause a mismatch.

If one of these 3 files is the one you need, then you need to find it ... my 'intuition' says the third one is the most likely, with the 2nd one as the next most hopeful, and the first as possible, but least likely, because the compiler is using the first and failing.

As a starting point, I suggest you rename the first two listed to something else ... e.g. "WiFiManager.hOLD", taking a careful note of what you are doing, so you can undo it, etc. later.

This will mean there is only one "WiFiManager.h" ... see if it compiles (or at least fixes most of the present errors).

If it doesn't help, then change the renaming to only have the second file as "WiFiManager.h" ... and so on, until you have tried all three.

--------

I hope that will fix your problem, though leaving it like that might cause problems later if you use a different card or if an update adds a 'new' "WiFiManager.h" file into the system.

I don't know if there is a 'official' fix to this problem, as it looks like a weak design spot to me.

One approach might be to make the #include <WiFiManager.h> into an explicit "E:\ <path name that works> \WiFiManager.h" style reference.

-------

Please treat as just a suggestion as where to look .. and be ready to undo any changes ... it is not a tested fix!

Best wishes, Dave

@davee Dave, it is not uncommon to see this. For instance as I work with several boards that all have wifi capabilities, I see a bunch of wifi libraries. The compiler knows which one to use from the Tools/Board setting. It is never a good idea to mess with include names or other library things since you might fix it for this sample, but then other samples or correct code may fail. I always encourage newish users to study the arduino.cc website especially the section called 

https://docs.arduino.cc/software/ide-v1/tutorials/installing-libraries

Although that reference includes manual installation, always try the first two methods first.

NOTE the discussion near the bottom re Please note: Arduino libraries are managed in three different places:

@douwebakker We need to see the real error messages. You have cut off the part with the information. Scroll the log up to the first error (in red) and then use a screen grab tool to just grab the entire message. This normally requires a box selection tool as the message will often be wider than the screen. Also the msg may be more than one line long with a second line using ^^^^ symbols to point to the relevant part of the first msg.

@douwebakker The library (directory/folder) that is the same name as the actual library but with _master on the end should be renamed without _master. You may need to delete any previous folders first.

Hi Ron @zander,

  I agree with your basic premise that it is better not to mess with filenames etc, if it can be avoided and I hope I made that fairly clear in my explanation. I was only suggesting a test to try to discover what had gone wrong. I was hoping someone else (and I had you in mind), would recognise a 'permanent term' fix if the problem was more clearly identified.

------------

As I commented, I thoroughly dislike the ease with which the same filenames regularly appear with different contents in Arduino contexts. You may be right that the board package selection is supposed to deal with this problem, but I do not believe it is as robust as it needs to be. And the problem is exasperated by 3rd party library authors who 'devise' their own library installation variants.

-----------

My main aim was to suggest a method of discovering if the problem is the system picking the wrong .h file. As with the best whodunnits, there is usually more than 1 suspect, and all I was aiming to do was check the alibis of these three ... 

I think the manner that the compiler always spits out a warning that there is more than 1 candidate file suggests the system designers know this is a weak spot .... and I agree with your general view that compiler warnings should be made visible, and so far as practicable, eliminated .... this is perhaps the most common example in Arduino land of that philosphy in action.

=======

I take the view that discovering the nature of fault or problem starts with discovering what the problem is - but that is only stage 1. 

Once you know what has 'failed', the answer may be obvious or it may be difficult and obscure, but at least your search for it can be directed.

Finding a backdoor fix for something is a poor substitute for comprehensively and methodically fixing a problem, but trying to fix a problem by continually repeatedly installing and installing packages in the hope of finding a sequence that works, without actually knowing the details of that problem is just as bad. So sometimes, trying backdoor fixes to discover the cause of the problem is a useful tool in the box.

--------

I hope that is clearer ... take care my friend ... we come from slightly different backgrounds, etc., but at the core we agree with each other far more than we disagree ... but sometimes the differences look much larger than they really are.

Best wishes, Dave

@davee Sorry Dave, I was too hard on you but I do disagree with the method you recommend for the reasons you outline, it leads to sloppy and error prone 'fixes'. The real underlying problem is that almost everyone including me operates their respective computers using the admin user privileges. The library files in a 'normal' environment are 'read-only' except for the 3rd location which is the libraries folder in the Sketchbook folder/directory. Since you can't have duplicate folders/dirs there can only be one library of a given name in each of the 3 locations. Also, since the build engine concatenates the libraries in the order 'IDE Install' then 'CORE folder' and finally your libraries folder, it's the last mentioned folder that has the library being searched for that counts. Another way of thinking about it is the IDE libraries are over rode by the CORE libraries which are over rode by your personal libraries. If you examine the compile logs of a few examples you will see this pattern of the engine finding several copies and it selects in the order I specified. This is the mechanism that allows us to write new library code that replaces old without a formal library submission process (hopefully temporary). Now to bring this back to the root cause of many newbie library errors. If you can NOT write to the IDE libraries folder, or the CORE libraries folder then all you can manipulate is your own user libraries folder and it can only have one library of a given name. That would have prevented a lot of library issues I was involved with over the last year or so.

I can't determine the OP's error yet until I see intact error logs but it will be one of the following.

1. Wrong board specified.

2. Boards not up to date.

3. Libraries not up to date.

4. Wrong library. (same name different author)

5. Very old source that needs a back level library. (rare, but esp32cam has/had this)

Some of these can be difficult to resolve unless you read the compile log carefully. Note which library was used to resolve a header file, it might not be the right one.

I hope that helps.

Hi Ron @zander,

  Thanks for the informative answer.

  As I said, all I was trying to do was to focus on finding the problem ... not fix it permanently.

-------------

  I obviously hope that the problem is not as simple as clicking 'update, as I would hope that had already been tried. whilst knowing that is still possible.

  If it turns out that using one of the other WiFIManager.h files enables it to compile, then I was hoping that information could be used to try to figure out the cause.

Documentation as to how much of it works seems thin on the ground .. or perhaps I haven't looked in the right place

---------

I don't have the NodeMCU-32S board, but thought I would try compiling it on a fairly 'vanilla' Arduino IDE V2.0 .. although it does have the standard ESP32 library.

So I selected the NodeMCU-32S board .. strictly one of the two possibilities ...

In the "Examples from Custom Libraries --> WiFiManager --> Basic"

And found it compiles without problems.

Obviously I can't test it works.

And no mention of multiple WiFiManager.h files ... which is to be expected, as I have already checked I have only one on my system.

----------------------------

So why the requestor's machine has 3 entries is unclear, particularly including one with a very 'customised' location name.

----------------------------

By the way, I have also noted your comments about directory privileges ... so far as I know, I have installed Arduino V2.0 as per the instructions .. on a Ubuntu box ... and being a Linux box, 'admin' and 'user' are not the same ... but all of the Arduino (2.0) "libraries" sub-directories I checked at were full access to me as a 'user'.

Of course I could change the privileges, but it doesn't look as they are protected as 'default' ... or maybe I missed something ... but it was a highly scripted operation.

--------------------

Best wishes, Dave

@davee So why the requestor's machine has 3 entries is unclear, particularly including one with a very 'customised' location name.

The 2nd one is the github 'master' file. When you download the zip from git it is named master both inside and outside the zip. This is a common practice in git. The OP appears to have duplicated and renamed that library. I just tested and if you leave -master on the name it still works. See pic1

The 3rd library, see pic2 is an old esp8266 library and is the likely cause of the problem. I found it in arduino.cc/reference/libraries link-> here

All 3 are accounted for, and the 2nd and 3rd were user incorrect actions as usual.

Just delete the following folders and try again.

E:\Documenten\Arduino\libraries\WiFiManager-master
E:\Documenten\Arduino\libraries\WhareHauoraWiFiManager-0.15.0

@davee As far as permissions, everything I have checked on my Mac tells me that without using the admin account I have no ability to modify the top 2 library entries. My testing isn't complete but a simple 'GetInfo' tells me I only have Read as my test user and Read-Write as admin. The reason I suspected this was many months ago we had a library mangler and I noticed the dir had 386 in the name. To the best of my knowledge any Win dir with that style of name was RO to normal users. It made sense then, and it still does. I will test further but now I need to eat.

Hi Ron @zander,

re permissions ... your observations obvously make sense as a strategy ... I began to doubt my own sanity ... and not for the first time .... 🙄 

So, I have looked a bit further ... bearing in mind I was thinking of ESP32 boards on this occasion ...

     some of those in Arduino/libraries are read only etc as you suggested with read-only access

 but those in Arduino/hardware/espressif/esp32/xx

where xx could be libraries or cores or package or whatever.. have full read/write access

 and some in  Arduino/libraries ... probably those chosen from Library Manager .. are full access

--

As I said before, the initial Arduino install followed the 'official' Arduino procedure

Whilst I don't remember the exact clicks to add ESP32, I think it was just add the github link in the Preferences page, and then install ESP32 in the Boards Manager ... certainly nothing that seemed underhand or backdoor-ish, and I don't recall it requiring 'sudo' permission override.

Have you seen documentation to suggest further steps, like changing access rights is expected/advised?

-------

So maybe the ESP32 libraries are 'vulnerable' to being overwritten but some Arduino ones have some protection ?

This leaves me to feel this protection strategy has more holes than a colander ...

  and I am not clear how the automatic updates to the 'protected' entries are applied without requesting 'sudo' privilege....

------------

Of course, Windows and Mac may be different.

---------

As for the original thread problem ... deleting the two directories as you suggest seems sensible ... but a bit  worryingly the compiler said it was using the first one for the .h file, which is the one that is left after deleting the other two ...

---------------

Sorry to @douwebakker for possibly sending him down a rabbit hole and hijacking his thread ... I am a compulsive 'questioner' on the basis it is one of the best ways of learning new things.

----------------

Best wishes, Dave