The Arduino WiFi preboot is a resilient captive-portal like template application that implements switching between WiFi STA and WiFi AP mode in order to allow a user to configure the WiFi network for the Arduino device in case no WiFi network has been configured or in case the WiFi network has changed and the Arduino needs to be reconfigured to connect to the new WiFi network.

The template solves the issue of having to manually reprogram each ESP device individually in case the WiFi network has changed.

If no configuration has been made, or the connection to the WiFi network has been severed, the template will commute the Arduino into soft AP mode. The soft AP SSID will be a randomly generated number seeded by the Arduino WiFi hardware MAC address. Additionally (and optionally, as marked within the code), the Arduino will start blinking the numeric code that constitutes the AP SSID using the built-in LED: this feature helps when a bunch of Arduino devices lose their connectivity and the user might have to identify which WiFi soft AP SSID corresponds to which hardware Arduino device.

The video shows the Arduino blinking 1 followed by 4, such that the soft AP SSID being advertised is currently 14 and the user can use any device, even mobile device, to connect to the AP SSID 14 in order to configure this device. It was considered to use Morse code to blink an SSID but simplicity is always preferable.

The user can connect to the WiFi soft AP and then using a browser attempt to access any web-page in order to be redirected to a configuration page. The configuration page will allow the user to configure the WiFi network SSID to along with the password. After submitting the form, the template will display a message that the Arduino will try connecting to the specified WiFi SSID and network.

The WiFi network SSID and password will be stored persistently such that upon reboot or power loss, the Arduino will swiftly reconnect to the configured SSID. In case the connection to the configured WiFi network cannot be established with a configurable timeout (specifically WIFI_RETRY_TIMEOUT * WIFI_CONNECT_TRIES milliseconds), the template will zap the configuration and switch to soft AP mode in order to be reconfigured.

Any user-code can be placed within the connectedLoop() function and it will be executed by the Arduino loop() routine with a minimal delay of one milliseconds (the user will have to introduce an appropriate delay within connectedLoop() in order to not throttle the CPU).

The following features are implemented:

• authenticate first in order to configure the AP point,
• minimal yet W3C HTML compliant webpage (to work with all browsers) for configuring the SSID and password,
• captive-portal redirection for devices that support detection,
• blinking the temporary soft AP SSID in order to be able to map the physical Arduino device to the soft AP,
• uses very popular and standard libraries, typical of WiFi ESP applications,
• compatible with ESP32 and ESP8266 (for now, possibly extensible to ARM),
• both synchronous and asynchronous variations provided, the former being standard but appearing cluttered up and the latter being a more robust implementation but with the reservation that the delay() function cannot be used and that any user-code must be re-written using timers

The "async" variation is perhaps the most robust in that it allows some form of "virtual threading" to be used on single-core devices such as the typical and widespread ESP8266. In order to achieve the effect of multiple running concurrent code, the "aync" variation uses timers (provided by the "TickTwo" package) that are not really used in the template for their semantics as timers, but rather as separation of threads that can run code (perceivable) concurrently (or more correctly, interlocked). The "TickTwo" package essentially uses time measurements to determine when the callbacks for the individual timers have to be called, thereby allowing "gaps" in execution (where code in synchronous versions would just spin and wait for the scheduler/CPU to give them control) to be filled by other code whose scheduling fits the gap.

On the other hand the "synchronous" variation is the standard you'll find for any Arduino sketch and if the device benefits from multiple cores, then tasks can be used to just run code concurrently, thereby eliminating the clutter within the Arduino main loop() method where utility code, pertaining to the "Wifi preboot template", would end up mingled with user code. If you are used to delay() and the code contains lots of delay() calls, then more than likely the "synchronous variation is the easiest to adopt.