And I tell a lie… it does use the loop, and instead uses a state machine to determine whether to get the sensor reading, idle until a total of 20 seconds uptime has elapsed to allow OTA to happen, or go into deepsleep. You just want it to be hanging around for long enough to hear espota sending it the message to start processing OTA…īelow is the code I currently have on a pair of ESP8266s (DigiStump Oak) that have been running well for the last several months… (and is overdue some tweaking as it’s a mismash of example code).
As long as there is a delay of some description (even a delay(1)) the ESP will get the yield() call it needs to ensure it doesn’t lock up, as well as encouraging it to idle while not doing anything. # - Send command to controller to differ between flashing and transmitting SPIFFS image. # use it like: python espota.py -i -I -p -P -f # This script will push an OTA update to the ESP # Modified since from Matthew O'Gorman () I’m not sure why the timeout would configurable… as going by the espota.py script, it is hard coded for 10 seconds, and doesn’t have a ‘timeout’ option… quite strange! Maybe platformio is running it multiple times? esp8266/Arduino/blob/master/tools/espota.py?utm_source=platformio&utm_medium=docs #!/usr/bin/env python I’d probably be tempted to increase the lookup to at least 5 seconds, so 50… I’ll have a look at the code I did to do something similar… basically all in setup instead of loop. Is my look of 30x 100ms enough to catch the OTA (the while loop with ota handle() ). In platformio.ini " upload_flags = -timeout=20" it looks like the unit for this flag is 10sec ? curious, no? It does not always works and I wonder the following:
So I launch an upload from atom and just wait… I do not have any “loop()” fonction, like most code with deepsleep, so I set a short loop at the end of my code, this way: mqtt.disconnect() ĪrduinoOTA.begin() // initialisation de l'OTA I added some OTA handling at the end of my code, before going back to sleep. I currently work on a weather sensor that spend most of its time in deepsleep, shortly wake up, measure and send data and goes back to deepsleep. Pins' values while in deep sleep, reset, and during restart are unaffected by the value the pin was set to before deep sleep.I use atom+platformio to develop some software on ESP8266. It takes 300ms from the reset pin rising edge for the user's program to start running (at least when deep sleep mode WAKE RFDEFAULT is used) Special function - timer reset when in deep sleepġ0k pullup on D1 mini schematic, and reset circuit connection to DTR/RTS/RSTġ0k pullup on D1 mini schematic, blue LED & 470 ohm resistor on ESP-12F I programmed the esp8266 using Arduino board support package 2.3.0 - as some of the behaviour is probably bootloader/SDK dependent, YMMV. The two test programs are at the end of this post.The gap between 'Reset pulled low' and 'Chip restarting' is intentional, I put it in because of the GPIO0/GPIO2 bootloader behaviour (you'll see it when you scroll down).The blue line is the reset signal and the red line is the pin being tested. The timebase for the charts below is 100 milliseconds per division, and the vertical scale is in volts.As the picoscope has a 1 MΩ input impedance, a 100 kΩ pull up to 3.3v with no other load makes a resistor divider with a 3v output voltage.The modules include some pull and and down components. These tests were performed on a 'WeMos D1 Mini V2' module carrying an 'ESP-12F' module carrying the esp8266.Schematicīy switching the Arduino Uno outputs between high, low and high impedance, we can test a variety of pull up and pull down values applied to the pins of the module. I decided to test how different pins behave when in deep sleep or undergoing a reset. Deep sleep requires a reset (including a bootloader and some radio calibration) to wake from. I want to do some battery powered sensing with an esp8266 - and to get a good battery life, I need to use the 'deep sleep' mode.