I’ll give you a pass since you did mention that you haven’t done any ESP8266 work, but that code will not reset the watchdog whatsoever, since delay is called, which itself feeds the watchdog
It’s the current version of the code…
while (WiFi.status() == WL_CONNECTED)
{
digitalWrite(LED_BUILTIN, HIGH);
}
that is guaranteed to fail every time, because there is zero attempt to feed the watchdog. A mere yield() would probably suffice, but if that problem were fixed, there is the minor issue that the code would never continue to the loop… the test should have been done in the main loop, and been an if/else test. not a while loop.
Yes, indeed… delays of 1-2 milliseconds inherently yield() to the underlying RTOS… giving it a chance to manage the wifi stack, satisfy the watchdog , etc…
As long as you write non-blocking code, and scatter the odd delay or yield() where you think there could be slowdowns, the ESP8266 is easy to work with…
You should use ``` before and after code snippets of any length, compile log snippets, stack traces, etc… basically anywhere there are characters the forum software could missinterpret as formatting. Forum software also generally won’t preserve spacing, so the mono-spaced (i.e. characters and whitepace are the same size) content won’t be formatted/displayed correctly. Plus when formatted correctly, long code or log snippets are put in their own scrolling region, making the post easier to read.
Whilst the ESP8266 and ESP32 have their own idiosyncrasies compared to the ever reliable Arduino Uno, the only major rule of thumb is to never write code that blocks setup() or loop() for more than a second or so… without using a yield() or a short delay (1-2 milliseconds is usually) to give the underlying RTOS (real time operating system) control again so it can do any tasks it needs to do.
This applies to the ESP8266 more than the ESP32, since the ESP8266 only has one processor core, which must manage the wifi AND your program, whereas the ESP32 has two processor cores, and by default the wifi/bt runs on one, and your code on the other.
Okay cool- it is now outputting to serial what it says is the number of seconds until the ISS flyover- but it’s wrong.
But NASA is also apparently wrong:
This shows a flyover RIGHT NOW.
But this:
shows the ISS hitting the horn of Africa as we speak.
I have my long/lat correct, and I filled in the correct time zone in the API…
Not sure what you mean… thhat is for the ESP32 and the ESP8266… and the Wemos D1 Mini is nothing specially… it’s just a ESP8266 with a given form factor.
What timezone are those times in? The ‘realtime’ status page says GMT, perhaps these are GMT also? If they are local time it will make things confusing… i.e. that page for me shows Sunday is
Sun Nov 22, 6:26 PM 3 min 20° 13° above WNW 18° above N
if it shows the same for you, it’s probably GMT, otherwise, possibly a headache…
You might like to give this code a try also… I really liked the idea (and had been meaning to make a ISS tracker thing), but thought it could be done differently (and better, of course! ) …
It separates WiFi and location details into a separate header file, allows a little configuration as to NEOPIXEL pin, and status LED pin and active high/low, gives a lot more info in the serial console, is more robust to wifi and connection issues… i.e. it will reset and try again if the wifi will not connect after 30 seconds, or the second attempt fails, and will retry the current time and current ISS functions if they don’t get data. Also, it shows off how it can be done using a state machine, with a lot less blocking code.
Give it a try, kick the tyres, let me know what you think.
I got it to serial print TimeUntilFlyover, and it actually might be accurate. I was synchronizing with the real-time locator at NASA, above.
So the API call and JSON request work! That’s awesome. I look forward to understanding those things.
But it did not light up.
I want to insert a display.print to display the seconds until flyover, refreshed every minute or so, but It didn’t happen wherever I tried to put it. I inserted a new function void displayIT() to output to OLED, but it was ignored.
I’m also going to light an LED to show online status.
Without a display, you have to keep it hooked up to a serial monitor- and you have to keep the PC awake.
But now I want to figure out where in the program it’s quitting. Neopixel is the first function in the program. I’m going to start another thread that’s probably going to be about debugging.
I only made one change around the actual HTTP request, which should not have broken anything - it was a change to the function as the old syntax is being phased out (depreciated). Before it would simply state Error on HTTP request and carry on… now it should retry once a second until it is successful… (because it will not progress to the next state until it is successful). I will extend [edit: have extended] the error message so that it says what the actual error is… rather than just giving a generic error… but it happens every so often… could be internet is slow, server is busy, etc, etc…
If it doesn’t, it’s back to the drawing board, and we’ll make it work 
) …