Did I lock my oak?

[digi_guy]

I was happily playing around with #include <ESP8266WiFi.h> before I saw that note about not using it.

Things were going fine for about a half dozen uploads, but now Arduino IDE gets to the upload stage and fails.

I've tried holding pin 1 to ground, which gets me back to wifi update page, but doesn't seem to erase the current sketch which still runs.

Any thoughts? Do I need to go through the deeper upload over serial process? Which leads to my last question, can one oak be used to write to another? I don't have any other arduinos in the house, or a linux computer, or any of the serial cables...

[exeng]

When you say pin 1 to ground, did you power cycle, wait 3-4 seconds, remove pin 1 from ground and see the rapid 3 blink pattern repeated. If so, you should be able to upload new sketches.

[digi_guy]

Thanks, I got it working again.

I held pin 1 to  ground and had the rapid 3 blink pattern, but instead of trying to upload a new sketch, I thought I had to go through to rawgit.com/digistump/OakSoftAP/master/config.html and then setup the wifi again. For some reason that process simply reverted back to the previous sketch.

[Nevyn]

I was happily playing around with #include <ESP8266WiFi.h> before I saw that note about not using it.

Any chance you could point me to this note only I can't seem to find it.

Thanks in advance,
Mark

[PeterF]

It's on the github page for OakCore, and I also included it in the Particle reference for the Oak page until we get a list of problematic functions, etc.

[mikekgr]

It's on the github page for OakCore, and I also included it in the Particle reference for the Oak page until we get a list of problematic functions, etc.

Dear pfeerick, correct me if I am wrong, but in the links you mentioned, there is not any reference regarding the problematic function of ESP8266WiFi.h ( #include <ESP8266WiFi.h> ). As far as I understood, you said that we have to omit this header, ESP8266WiFi.h.
Am I right?
please explain it.

Thanks and Best Regards,
Mike Kranidis

[defragster]

AFAIK - including the header is okay - that won't cause problems as it may allow access to functions but not change anything.  The problem may come from using certain functions that could cause the resultant sketch to compile or run improperly with regard to the Particle scheme and software.  Certainly some operations are good and harmless - but the ones that are somehow incompatible may have undesired side effects - and at this point what those are is not known.

[PeterF]

Including that header will not do anything other than make its functions available - it doesn't change anything. But using the functions made available by that header may result in breakage, as it is one of the included ESP8266 libraries. I have not said to omit "#include <ESP8266WiFi.h>", only to be prepared to do a factory reset if the worst happens and you can't get into safe mode.

For my part, I haven't had any issues with any of the following libraries or functions:

Code: [Select]

#include <WiFiClient.h>
#include <ESP8266WiFi.h>

WiFiClient client;
WiFi.status()
WiFi.begin();


[mikekgr]

Including that header will not do anything other than make its functions available - it doesn't change anything. But using the functions made available by that header may result in breakage, as it is one of the included ESP8266 libraries. I have not said to omit "#include <ESP8266WiFi.h>", only to be prepared to do a factory reset if the worst happens and you can't get into safe mode.

For my part, I haven't had any issues with any of the following libraries or functions:

Code: [Select]

#include <WiFiClient.h>
#include <ESP8266WiFi.h>

WiFiClient client;
WiFi.status()
WiFi.begin();


Thanks a lot. More clear now... ;-)