@ -105,6 +105,7 @@ Full documentation is available on https://Hieromon.github.io/AutoConnect, some
- Changed the bootUri behavior to be an automatic pop-up at the captive portal. (PR #181)
- Supports AutoConnect menu configuration.
- Supports the built-in OTA feature.
- Supports an attempt order when available APs would be found multiple, and RSSI lower bound on AP signal strength. This option can specify the order of connection attempting according to the WiFi signal strength indicated with RSSI. (PR #187)
### [1.1.4] Feb. 14, 2020
- Supports for overriding text of the menu items with user-defined labels.
When the captive portal is started, SoftAP starts and the STA is disconnected. The current SSID setting memorized in ESP8266 will be lost but then the reconnect behavior of ESP32 is somewhat different from this.
AutoConnect changes WIFI mode depending on the situation. The [AutoConnect::begin](lsbegin.md) function starts WIFI in STA mode and starts the webserver if the connection is successful by the 1st-WiFi.begin. But if the connection fails with the least recently established access point, AutoConnect will switch the WIFI mode to AP_STA and starts the DNS server to be able to launch a captive portal.
The [*WiFiSTAClass::disconnect*](https://github.com/espressif/arduino-esp32/blob/a0f0bd930cfd2d607bf3d3288f46e2d265dd2e11/libraries/WiFi/src/WiFiSTA.h#L46) function implemented in the arduino-esp32 has extended parameters than the ESP8266's arduino-core. The second parameter of WiFi.disconnect on the arduino-esp32 core that does not exist in the [ESP8266WiFiSTAClass](https://github.com/esp8266/Arduino/blob/7e1bdb225da8ab337373517e6a86a99432921a86/libraries/ESP8266WiFi/src/ESP8266WiFiSTA.cpp#L296) has the effect of deleting the currently connected WiFi configuration and its default value is "false". On the ESP32 platform, even if WiFi.disconnect is executed, WiFi.begin() without the parameters in the next turn will try to connect to that AP. That is, automatic reconnection is implemented in arduino-esp32 already. Although this behavior appears seemingly competent, it is rather a disadvantage in scenes where you want to change the access point each time. When explicitly disconnecting WiFi from the Disconnect menu, AutoConnect will erase the AP connection settings saved by arduino-esp32 core. AutoConnect's automatic reconnection is a mechanism independent from the automatic reconnection of the arduino-esp32 core.
When the captive portal is started, SoftAP starts and the STA is disconnected. At this point, the station configuration information that the ESP module has stored on its own (it is known as the SDK's [station_config](https://github.com/esp8266/Arduino/blob/db75d2c448bfccc6dc308bdeb9fbd3efca7927ff/tools/sdk/include/user_interface.h#L249) structure) is discarded.
If the [**autoReconnect**](apiconfig.md#autoreconnect) option of the [AutoConnectConfig](apiconfig.md) class is enabled, it automatically attempts to reconnect to the disconnected past access point. When the autoReconnect option is specified, AutoConnect will not start SoftAP immediately if the first WiFi.begin fails. It will scan WiFi signal and the same connection information as the detected BSSID is stored in the flash as AutoConnect's credentials, explicitly apply it with WiFi.begin and rerun.
AutoConnect can connect to an access point again using saved credential that has disconnected once, and its control is allowed by [**autoReconnect**](apiconfig.md#autoreconnect). [*AutoConnectConfig::autoReconnect*](apiconfig.md#autoreconnect) option specifies to attempt to reconnect to the past established access point that stored in saved credentials. AutoConnect does not start SoftAP immediately even if 1st-WiFi.begin fails when the [**autoReconnct**](apiconfig.md#autoreconnect) is enabled. It will scan the WiFi signal, and if the same BSSID as the detected BSSID is stored in flash as AutoConnect credentials, explicitly apply it and reruns WiFi.begin still WIFI_STA mode. (The autoReconnect works effectively even if the SSID is a hidden access point)
```cpp hl_lines="3"
AutoConnect Portal;
@ -28,12 +28,13 @@ Portal.config(Config);
Portal.begin();
```
An autoReconnect option is available to *AutoConnect::begin* without SSID and pass Passphrase.
An [**autoRecconect**](apiconfig.md#autoreconnect) option is only available for [*AutoConnect::begin*](api.md#begin) without SSID and PASSWORD parameter.
!!! caution "An autoReconnect will work if SSID detection succeeded"
An autoReconnect will not effect if the SSID which stored credential to be connected is a hidden access point.
!!! note "An autoReconnect is not autoreconnect"
The [*WiFiSTAClass::disconnect*](https://github.com/espressif/arduino-esp32/blob/a0f0bd930cfd2d607bf3d3288f46e2d265dd2e11/libraries/WiFi/src/WiFiSTA.h#L46) function implemented in the arduino-esp32 has extended parameters than the ESP8266's arduino-core. The second parameter of WiFi.disconnect on the arduino-esp32 core that does not exist in the [ESP8266WiFiSTAClass](https://github.com/esp8266/Arduino/blob/7e1bdb225da8ab337373517e6a86a99432921a86/libraries/ESP8266WiFi/src/ESP8266WiFiSTA.cpp#L296) has the effect of deleting the currently connected WiFi configuration and its default value is "false". On the ESP32 platform, even if WiFi.disconnect is executed, WiFi.begin() without the parameters in the next turn will try to connect to that AP. That is, automatic reconnection is implemented in arduino-esp32 already. Although this behavior appears seemingly competent, it is rather a disadvantage in scenes where you want to change the access point each time. When explicitly disconnecting WiFi from the Disconnect menu, AutoConnect will erase the AP connection settings saved by the arduino-esp32 core. AutoConnect's automatic reconnection is a mechanism independent from the automatic reconnection of the arduino-esp32 core.
### <iclass="fa fa-caret-right"></i> Auto save Credential
By default, AutoConnect saves the credentials of the established connection to the flash. You can disable it with the [**autoSave**](apiconfig.md#autosave) parameter specified by [AutoConnectConfig](apiconfig.md).
See the [Saved credentials access](credit.md) chapter for details on accessing stored credentials.
@ -244,40 +245,34 @@ void loop() {
For more details, see section [Constructing the menu](menuize.md) of Examples page.
### <iclass="fa fa-caret-right"></i> Change menu title
### <iclass="fa fa-caret-right"></i> Change the menu labels
Although the default menu title is **AutoConnect**, you can change the title by setting [*AutoConnectConfig::title*](apiconfig.md#title). To set the menu title properly, you must set before calling [*AutoConnect::begin*](api.md#begin).
You can change the label text for each menu item but cannot change them at run time. There are two ways to change the label text, both of which require coding the label literal.
```cpp hl_lines="6 7"
AutoConnect Portal;
AutoConnectConfig Config;
1. Overwrite the label literal of library source code directly.
void setup() {
// Set menu title
Config.title = "FSBrowser";
Portal.config(Config);
Portal.begin();
}
```
You can change the label of the AutoConnect menu item by rewriting the default label literal in [AutoConnectLabels.h](https://github.com/Hieromon/AutoConnect/blob/master/src/AutoConnectLabels.h) macros. However, changing menu items literal influences all the sketch's build scenes.
Executing the above sketch will rewrite the menu title for the **FSBrowser** as the below.
```cpp
#define AUTOCONNECT_MENULABEL_CONFIGNEW "Configure new AP"
### <iclass="fa fa-caret-right"></i> Change the menu labels
!!! note "**build_flags** with PlatformIO will no effect"
The mistake that many people make is to use PlatformIO's build_flags to try to redefine any literal at compile time.<br>
The AutoConnect library statically contains the label literals which are embedded as binary data when compiling the library code. The label literals will not change without compiling the library source.<br>
And PlatformIO is a build system. Library sources will not be compiled unless AutoConnectLabels.h is updated.
You can change the label of the AutoConnect menu item by rewriting the default label letter in [AutoConnectLabels.h](https://github.com/Hieromon/AutoConnect/blob/master/src/AutoConnectLabels.h) macros. However, changing menu items letter influences all build scenes for the Sketch.
2. Change the label literals for each Arduino project
```cpp
#define AUTOCONNECT_MENULABEL_CONFIGNEW "Configure new AP"
Another way to change the label literal is to provide a header file that defines the label literals, as mentioned in [Appendix](changelabel.md#change-the-items-label-text). You can also use this method to display label text and fixed text in the local language on the AutoConnect page. See [**Appendix:Change the item's label text**](changelabel.md#change-the-items-label-text) for details.
### <iclass="fa fa-caret-right"></i> Combination with mDNS
@ -302,6 +297,56 @@ void loop() {
}
```
### <iclass="fa fa-caret-right"></i> Connects depending on the WiFi signal strength
When the ESP module found the multiple available access points (ie. AutoConnect has connected in the past), the default behavior AutoConnect will attempt to connect to the least recent one. However, If the ESP module can operate properly with any access point, it is advantageous to establish a connection with the best one of the reception sensitivity.
The [*AutoConnectConfig::principle*](apiconfig.md#principle) parameter has the connection disposition, and specifying **AC_PRINCIPLE_RSSI** will attempt to connect to one of the highest RSSI value among multiple available access points. Also You can expect stable WiFi connection by specifying the lower limit of signal strength using [*AutoConnectConfig::minRSSI*](apiconfig.md#minrssi).
Combining these two parameters allows you to filter the destination AP when multiple available access points are found.
[*AutoConnectConfig::principle*](apiconfig.md#principle) affects the behavior of both 1st-WiFi.begin and [**autoReconnect**](advancedusage.md#automatic-reconnect). If you specify **AC_PRINCIPLE_RECENT** for the [**principle**](apiconfig.md#principle), it will try according to the conventional connection rules, but if you specify **AC_PRINCIPLE_RSSI**, it will try to connect to the access point that is sending the strongest WiFi signal at that time instead of the last accessed AP. Also, the static IPs will be restored from a saved credential instead of AutoConnectConfig. (The values specified by AutoConnectConfig is ignored)
<throwspan="2">Which credentials would be selected</th>
<throwspan="2">Static IPs</th>
</tr>
<tr>
</tr>
<tr>
<tdrowspan="3">AutoConnect<br>::begin</td>
<tdrowspan="2">NULL specified</td>
<td>AC_PRINCIPLE_RECENT</td>
<td>Nothing, depends on SDK saves</td>
<td>Use the specified value of AutoConnectConfig<br></td>
</tr>
<tr>
<td>AC_PRINCIPLE_RSSI</td>
<td>Auto-selected credentials with max RSSI</td>
<td>Restoring static IPs suitable for the SSID from saved credentials</td>
</tr>
<tr>
<td>Specified with the sketch</td>
<td>Not efective</td>
<td>By AutoConnect::begin parameters</td>
<td>Use the specified value of AutoConnectConfig</td>
</tr>
<tr>
<tdrowspan="2">AutoReconnect</td>
<tdrowspan="2">Load from<br>saved credential</td>
<td>AC_PRINCIPLE_RECENT</td>
<td>Recently saved SSID would be chosen</td>
<tdrowspan="2">Restoring static IPs suitable for the SSID from saved credentials</td>
</tr>
<tr>
<td>AC_PRINCIPLE_RSSI</td>
<td>Auto-selected credentials with max RSSI</td>
</tr>
</table>
### <iclass="fa fa-caret-right"></i> Debug print
You can output AutoConnect monitor messages to the **Serial**. A monitor message activation switch is in an include header file [AutoConnectDefs.h](https://github.com/Hieromon/AutoConnect/blob/master/src/AutoConnectDefs.h) of library source. Define [**AC_DEBUG**](https://github.com/Hieromon/AutoConnect/blob/master/src/AutoConnectDefs.h#L14) macro to output the monitor messages.[^1]
### <iclass="fa fa-caret-right"></i>Move the saving area of EEPROM for the credentials
### <iclass="fa fa-caret-right"></i>On-demand start the captive portal
By default, the credentials saving area is occupied from the beginning of EEPROM area. [ESP8266 Arduino core document](http://arduino-esp8266.readthedocs.io/en/latest/filesystem.html?highlight=eeprom#flash-layout) says that:
The [default behavior of AutoConnect::begin](lsbegin.md) gives priority to connect to the least recently established access point. In general, We expect this behavior in most situations, but will intentionally launch the captive portal on some occasion.
Here section describes how to launch on demand the captive portal, and suggests two templates that you can use to implement it.
> The following diagram illustrates flash layout used in Arduino environment:
1. Offline for usual operation, connect to WiFi with an external switch
> Sketch OTA update File system EEPROM WiFi config (SDK)
> ```
You can use this template if the ESP module does not connect to WiFi at an ordinal situation and need to establish by a manual trigger. In this case, it is desirable that AutoConnect not start until an external switch fires. This behavior is similar to the [WiFiManager's startConfigPortal](https://github.com/tzapu/WiFiManager#on-demand-configuration-portal) function.
[*AutoConnectConfig::immediateStart*](apiconfig.md#immediatestart) is an option to launch the portal by the SoftAP immediately without attempting 1st-WiFi.begin. Also, by setting the [*AutoConnectConfig::autoRise*](apiconfig.md#autorise) option to false, it is possible to suppress unintended automatic pop-ups of the portal screen when connecting to an ESP module SSID.
To implement this, execute AutoConnect::config within the **setup()** function as usual, and handle AutoConnect::begin inside the **loop()** function.
and
```cpp hl_lines="9"
#define TRIGGER_PIN 5 // Trigger switch should be LOW active.
#define HOLD_TIMER 3000
> EEPROM library uses one sector of flash located [just after the SPIFFS](http://arduino-esp8266.readthedocs.io/en/latest/libraries.html?highlight=SPIFFS#eeprom).
AutoConnect Portal;
AutoConnectConfig Config;
Also, in ESP32 arduino core 1.0.2 earlier, the placement of the EEPROM area of ESP32 is described in the [partition table](https://github.com/espressif/arduino-esp32/blob/master/tools/partitions/default.csv). So in the default state, the credential storage area used by AutoConnect conflicts with data owned by the user sketch. It will be destroyed together saved data in EEPROM by user sketch and AutoConnect each other. But you can move the storage area to avoid this.
void setup() {
pinMode(5, INPUT_PULLUP);
Config.immediateStart = true;
// Config.autoRise = false; // If you don't need to automatically pop-up the portal when connected to the ESP module's SSID.
Portal.config(Config);
}
The [**boundaryOffset**](apiconfig.md#boundaryoffset) in [AutoConnectConfig](apiconfig.md) specifies the start offset of the credentials storage area. The default value is 0.
void loop() {
if (digitalRead(TRIGGER_PIN) == LOW) {
unsigned long tm = millis();
while (digitalRead(TRIGGER_PIN) == LOW) {
yield();
}
// Hold the switch while HOLD_TIMER time to start connect.
if (millis() - tm > HOLD_TIMER)
Portal.begin();
}
!!! info "The boundaryOffset ignored with AutoConnect v1.0.0 later on ESP32 arduino core 1.0.3 later"
For ESP32 arduino core 1.0.3 and later, AutoConnect will store credentials to Preferences in the nvs. Since it is defined as the namespace dedicated to AutoConnect and separated from the area used for user sketches. Therefore, the [boundaryOffset](apiconfig.md#boundaryoffset) is ignored with the combination of AutoConnect v1.0.0 or later and the arduino-esp32 1.0.3 or later.
if (WiFi.status() == WL_CONNECTED) {
// Here, what to do if the module has connected to a WiFi access point
}
### <iclass="fa fa-caret-right"></i> On-demand start the captive portal
// Main process of your sketch
If you do not usually connect to WiFi and need to establish a WiFi connection if necessary, you can combine the [**autoRise**](apiconfig.md#autorise) option with the [**immediateStart**](apiconfig.md#immediatestart) option to achieve on-demand connection. This behavior is similar to the [WiFiManager's startConfigPortal](https://github.com/tzapu/WiFiManager#on-demand-configuration-portal) function. In order to do this, you usually configure only with AutoConnectConfig in *setup()* and [*AutoConnect::begin*](api.md#begin) handles in *loop()*.
Portal.handleClient(); // If WiFi is not connected, handleClient will do nothing.
}
```
```cpp hl_lines="5 6"
AutoConnect Portal;
AutoConnectConfig Config;
!!! note "It will not be automatic reconnect"
The above example does not connect to WiFi until TRIGGER\_PIN goes LOW. When TRIGGER\_PIN goes LOW, the captive portal starts and you can connect to WiFi. Even if you reset the module, it will not automatically reconnect.
void setup() {
Config.autoRise = false;
Config.immediateStart = true;
Portal.config(Config);
}
2. Register new access points on demand
void loop() {
if (digitalRead(TRIGGER_PIN) == LOW) {
while (digitalRead(TRIGGER_PIN) == LOW)
yield();
Portal.begin();
The following template is useful for controlling the registration of unknown access points. In this case, the ESP module establishes a WiFi connection using WiFi.begin natively without relying on AutoConnect.
Known access point credentials are saved by AutoConnect, to the ESP module can use the saved credentials to handle WiFi.begin natively. This means that you can explicitly register available access points when needed, and the ESP module will not use unknown access points under normal situations.
```cpp
AutoConnect* portal = nullptr;
bool detectSwitch() {
/*
Returns true if an external switch to configure is active.
*/
}
Portal.handleClient();
}
```
The above example does not connect to WiFi until TRIGGER\_PIN goes LOW. When TRIGGER\_PIN goes LOW, the captive portal starts and you can connect to WiFi. Even if you reset the module, it will not automatically reconnect.
if (connectWiFi(config.ssid, config.password, 30000))
break;
}
if (WiFi.status() != WL_CONNECTED) {
// Here, do something when WiFi cannot reach.
}
}
void loop() {
if (detectSwitch()) {
AutoConnectConfig config;
config.immediateStart= true;
if (!portal) {
portal = new AutoConnect;
}
portal->config(config);
if (portal->begin()) {
portal->end();
delete portal;
portal = nullptr;
}
}
// Here, ordinally sketch logic.
}
```
### <iclass="fa fa-caret-right"></i> Refers the hosted ESP8266WebServer/WebServer
@ -463,31 +566,21 @@ An example sketch used with the PageBuilder as follows and it explains how it ai
## Configuration functions
### <iclass="fa fa-caret-right"></i> Configuration for Soft AP and captive portal
You can adjust the AutoConnect behave at run-time using [AutoConnectConfig](apiconfig.md). AutoConnectConfig is a class that has only AutoConnect configuration data. You define the behavior of AutoConnect using AutoConnectConfig member variables and give it to AutoConnect via the [AutoConnect::config](api.md#config) function.
AutoConnect will activate SoftAP at failed the first *WiFi.begin*. It SoftAP settings are stored in [**AutoConnectConfig**](apiconfig.md#autoconnectconfig) as the following parameters. The sketch could be configured SoftAP using these parameters, refer the [AutoConnectConfig API](apiconfig.md#public-member-variables) for details.
AutoConnectConfig can specify the following runtime behavior:
- IP address of SoftAP activated.
- Gateway IP address.
- Subnet mask.
- SSID for SoftAP.
- Password for SoftAP.
- Channel.
- SoftAP name.
- Hidden attribute.
- Station hostname.
- Auto save credential.
- Offset address of the credentials storage area in EEPROM.
- Captive portal time out limit.
- Maintain portal function even after a timeout.
- Length of start up time after reset.
- Automatic starting the captive portal.
- Start the captive portal forcefully.
- Auto reset after connection establishment.
- Home URL of the user sketch application.
- Menu title.
- Ticker signal output.
- Built-in OTA update.
- [Assign user sketch's home path](#assign-user-sketchs-home-path)
- [Built-in OTA update](#built-in-ota-update-feature)
- [Change menu title](#change-menu-title)
- [Change SSID and Password for SoftAP](#change-ssid-and-password-for-softap)
- [Configuration for Soft AP and captive portal](#configuration-for-soft-ap-and-captive-portal)
- [Move the saving area of EEPROM for the credentials](#move-the-saving-area-of-eeprom-for-the-credentials)
- [Relocate the AutoConnect home path](#relocate-the-autoconnect-home-path)
- [Static IP assignment](#static-ip-assignment-2)
- [Station host name](#station-host-name)
- [Ticker for WiFi status](#ticker-for-wifi-status)
!!! note "AutoConnect::config before AutoConnect::begin"
*AutoConnect::config* must be executed before *AutoConnect::begin*.
@ -514,6 +607,36 @@ The sketch HOME path is closely related to the [bootUri](apiconfig.md#booturi) t
| Which page **loads** at the boot time, ROOT or HOME | Appears after module reboot by **RESET** button with AutoConnect menu | AutoConnectConfig::bootURI | AC_ONBOOTURI_ROOT | AC_ONBOOTURI_HOME |
| Which page **appears** at the captive portal, ROOT or HOME | Auto pop-up | AutoConnectConfig::bootURI | AC_ONBOOTURI_ROOT | AC_ONBOOTURI_HOME |
### <iclass="fa fa-caret-right"></i> Built-in OTA update feature
AutoConnect features a built-in OTA function to update ESP module firmware. You can easily make the Sketch that equips OTA and able to operate with the AutoConnect menu.
[AutoConnectConfig::ota](apiconfig.md#ota) specifies to import the [built-in OTA update class](otabrowser.md) into the Sketch.
See the [Updates with the Web Browser](otabrowser.md) chapter for details.
### <iclass="fa fa-caret-right"></i> Change menu title
Although the default menu title is **AutoConnect**, you can change the title by setting [*AutoConnectConfig::title*](apiconfig.md#title). To set the menu title properly, you must set before calling [*AutoConnect::begin*](api.md#begin).
```cpp hl_lines="6 7"
AutoConnect Portal;
AutoConnectConfig Config;
void setup() {
// Set menu title
Config.title = "FSBrowser";
Portal.config(Config);
Portal.begin();
}
```
Executing the above sketch will rewrite the menu title for the **FSBrowser** as the below.
### <iclass="fa fa-caret-right"></i> Change SSID and Password for SoftAP
An **esp8266ap** is default SSID name for SoftAP of captive portal and password is **12345678** for ESP8266. Similarly, **esp32ap** and **12345678** for ESP32. You can change both by setting [apid](apiconfig.md#apid) and [psk](apiconfig.md#psk).
@ -542,9 +665,43 @@ void setup() {
}
```
You can also assign no password to SoftAP launched as a captive portal. Assigning a null string as `String("")` to [AutoConnectConfig::psk](apiconfig.md#psk) does not require a password when connecting to SoftAP.
You can also assign no password to SoftAP launched as a captive portal. Assigning a null string as `String("")` to [*AutoConnectConfig::psk*](apiconfig.md#psk) does not require a password when connecting to SoftAP.
But this method is not recommended. The broadcast radio of SSID emitted from SoftAP will leak and reach several tens of meters.
### <iclass="fa fa-caret-right"></i> Configuration for Soft AP and captive portal
AutoConnect will activate SoftAP at failed the first *WiFi.begin*. It SoftAP settings are stored in [**AutoConnectConfig**](apiconfig.md#autoconnectconfig) as the following parameters. The sketch could be configured SoftAP using these parameters, refer the [AutoConnectConfig API](apiconfig.md#public-member-variables) for details.
Appropriately specifying the WiFi channel to use for ESP8266 and ESP32 is essential for a stable connection with the access point. AutoConnect remembers the WiFi channel with a credential of the access point once connected and reuses it.
The default channel when a captive portal starts and AutoConnect itself becomes an access point is the [*AutoConnectConfig::channel*](apiconfig.md#channel) member. If this channel is different from the channel of the access point you will attempt to connect, WiFi.begin may fail. The cause is that the ESP module shares the same channel in AP mode and STA mode. If the connection attempt is not stable, specifying a proper channel using AutoConnectConfig::channel may result in a stable connection.
### <iclass="fa fa-caret-right"></i> Move the saving area of EEPROM for the credentials
By default, the credentials saving area is occupied from the beginning of EEPROM area. [ESP8266 Arduino core document](http://arduino-esp8266.readthedocs.io/en/latest/filesystem.html?highlight=eeprom#flash-layout) says that:
> The following diagram illustrates flash layout used in Arduino environment:
> Sketch OTA update File system EEPROM WiFi config (SDK)
> ```
and
> EEPROM library uses one sector of flash located [just after the SPIFFS](http://arduino-esp8266.readthedocs.io/en/latest/libraries.html?highlight=SPIFFS#eeprom).
Also, in ESP32 arduino core 1.0.2 earlier, the placement of the EEPROM area of ESP32 is described in the [partition table](https://github.com/espressif/arduino-esp32/blob/master/tools/partitions/default.csv). So in the default state, the credential storage area used by AutoConnect conflicts with data owned by the user sketch. It will be destroyed together saved data in EEPROM by user sketch and AutoConnect each other. But you can move the storage area to avoid this.
The [**boundaryOffset**](apiconfig.md#boundaryoffset) in [AutoConnectConfig](apiconfig.md) specifies the start offset of the credentials storage area. The default value is 0.
!!! info "The boundaryOffset ignored with AutoConnect v1.0.0 later on ESP32 arduino core 1.0.3 later"
For ESP32 arduino core 1.0.3 and later, AutoConnect will store credentials to Preferences in the nvs. Since it is defined as the namespace dedicated to AutoConnect and separated from the area used for user sketches. Therefore, the [boundaryOffset](apiconfig.md#boundaryoffset) is ignored with the combination of AutoConnect v1.0.0 or later and the arduino-esp32 1.0.3 or later.
### <iclass="fa fa-caret-right"></i> Relocate the AutoConnect home path
A home path of AutoConnect is **/\_ac** by default. You can access from the browser with http://IPADDRESS/\_ac. You can change the home path by revising [**AUTOCONNECT_URI**](https://github.com/Hieromon/AutoConnect/blob/master/src/AutoConnectDefs.h#L69) macro in the include header file as [AutoConnectDef.h](https://github.com/Hieromon/AutoConnect/blob/master/src/AutoConnectDef.h).
@ -582,7 +739,7 @@ portal.begin();
### <iclass="fa fa-caret-right"></i> Station host name
[AutoConnectConfig::hostName](apiconfig.md#hostname) assigns the station DHCP hostname which complies with [RFC952](https://tools.ietf.org/html/rfc952). It must satisfy the following constraints.
[*AutoConnectConfig::hostName*](apiconfig.md#hostname) assigns the station DHCP hostname which complies with [RFC952](https://tools.ietf.org/html/rfc952). It must satisfy the following constraints.
- Up to 24 characters
- Only the alphabet (a-z, A-Z), digits (0-9), minus sign (-)
@ -592,7 +749,7 @@ portal.begin();
Flicker signal can be output from the ESP8266/ESP32 module according to WiFi connection status. If you connect the LED to the signal output pin, you can know the WiFi connection status during behavior inside AutoConnect::begin through the LED blink.
[AutoConnectConfig::ticker](apiconfig.md#ticker) option specifies flicker signal output. The following sketch is an example of flashing the active-high LED connected to pin #16 according to WiFi connection during the AutoConnect::begin.
[*AutoConnectConfig::ticker*](apiconfig.md#ticker) option specifies flicker signal output. The following sketch is an example of flashing the active-high LED connected to pin #16 according to WiFi connection during the AutoConnect::begin.
```cpp
AutoConnect portal;
@ -626,11 +783,11 @@ The flicker cycle length is defined by some macros in `AutoConnectDefs.h` header
- `AUTOCONNECT_FLICKER_WIDTHAP` and `AUTOCONNECT_FLICKER_WIDTHDC`:
Specify the duty rate for each period[ms] in 8-bit resolution.
[AutoConnectConfig::tickerPort](apiconfig.md#tickerport) specifies a port that outputs the flicker signal. If you are using an LED-equipped ESP module board, you can assign a LED pin to the tick-port for the WiFi connection monitoring without the external LED. The default pin is arduino valiant's **LED\_BUILTIN**. You can refer to the Arduino IDE's variant information to find out which pin actually on the module assign to **LED\_BUILTIN**.[^3]
[*AutoConnectConfig::tickerPort*](apiconfig.md#tickerport) specifies a port that outputs the flicker signal. If you are using an LED-equipped ESP module board, you can assign a LED pin to the tick-port for the WiFi connection monitoring without the external LED. The default pin is arduino valiant's **LED\_BUILTIN**. You can refer to the Arduino IDE's variant information to find out which pin actually on the module assign to **LED\_BUILTIN**.[^3]
[^3]: It's defined in the `pins_arduino.h` file, located in the sub-folder named **variants** wherein Arduino IDE installed folder.
[AutoConnectConfig::tickerOn](apiconfig.md#tickeron) specifies the active logic level of the flicker signal. This value indicates the active signal level when driving the ticker. For example, if the LED connected to tickPort lights by LOW, the tickerOn is **LOW**. The logic level of LED_BUILTIN for popular modules are as follows:
[*AutoConnectConfig::tickerOn*](apiconfig.md#tickeron) specifies the active logic level of the flicker signal. This value indicates the active signal level when driving the ticker. For example, if the LED connected to tickPort lights by LOW, the tickerOn is **LOW**. The logic level of LED_BUILTIN for popular modules are as follows:
module | Logic level | LED_BUILTIN Pin | Arduino alias
----|----|:---:|----
@ -643,15 +800,6 @@ LOLIN32 Pro | Active-low | 5 | SS
### <iclass="fa fa-caret-right"></i> Built-in OTA update feature
AutoConnect features a built-in OTA function to update ESP module firmware. You can easily make the Sketch that equips OTA and able to operate with the AutoConnect menu.
@ -214,6 +214,14 @@ Configure applying items of the [AutoConnect menu](menu.md). You can arbitrarily
```
However, even if you specify like the above, the AutoConnectAux page items still display on the menu. To remove the AutoConnectAux items, use the [AutoConnectAux::menu](apiaux.md#menu) function.
### <iclass="fa fa-caret-right"></i> minRSSI
Specify the lower limit of the WiFi signal strength allowed to use as an access point. This value should be greater than -120 as RSSI. Generally, a data link will not be established unless it exceeds -90 dBm. Also, packet transmission is not reliable below -70 dBm to -80 dBm.
<dlclass="apidl">
<dt>**Type**</dt>
<dd><spanclass="apidef">int16_t</span><spanclass="apidesc">The default value is -120</span></dd>
</dl>
### <iclass="fa fa-caret-right"></i> netmask
Sets subnet mask for Soft AP in captive portal. When AutoConnect fails the initial WiFi.begin, it starts the captive portal with the IP address specified this.
@ -242,6 +250,17 @@ Specify the timeout value of the captive portal in [ms] units. It is valid when
<dd><spanclass="apidef">unsigned long</span><spanclass="apidesc">Captive portal timeout value. The default value is 0.</span></dd>
</dl>
### <iclass="fa fa-caret-right"></i> principle
Specify the connection order will attempt to connect to one of the highest RSSI values among multiple available access points. It is given as an enumeration value of **AC_PRINCIPLE_t** indicating.
<dlclass="apidl">
<dt>**Type**</dt>
<dd>AC_PRINCIPLE_t</dd>
<dt>**Value**</dt>
<dd><spanclass="apidef">AC_PRINCIPLE_RECENT</span><spanclass="apidesc"></span><spanclass="apidef"> </span><spanclass="apidesc">Attempts to connect in the order of the saved credentials entries. The entry order is generally a time series connected in the past.</span></dd>
<dd><spanclass="apidef">AC_PRINCIPLE_RSSI</span><spanclass="apidesc"></span><spanclass="apidef"> </span><spanclass="apidesc">Attempts to connect to one of the highest RSSI values among multiple available access points.</span></dd>
</dl>
### <iclass="fa fa-caret-right"></i> psk
Sets password for SoftAP. The length should be from 8 to up to 63. The default value is **12345678**.
- Supports the built-in OTA feature as [AutoConnectOTA](otabrowser.md#updates-with-the-web-browserupdated-wv115).
- Supports an attempt order when available APs would be found multiple, and RSSI lower bound on AP signal strength. This option can specify the order of connection attempting according to the WiFi signal strength indicated with RSSI.
#### [1.1.4] Feb. 14, 2020
- Supports for overriding text of the menu items with user-defined labels.
@ -67,7 +67,7 @@ You have the following two options to avoid this conflict:
- Suppresses the automatic save operation of credentials by AutoConnect.
You can completely stop saving the credentials by AutoConnect. However, if you select this option, you lose the past credentials which were able to connect to the AP. Therefore, the effect of the [automatic reconnection feature](advancedusage.md#automatic-reconnect) will be lost.
If you want to stop the automatic saving of the credentials, uses [AutoConnectConfig::autoSave](apiconfig.md#autosave) option specifying **AC_SAVECREDENTIAL_NEVER**. Refer to the chapter on [Advanced usage](advancedusage.md#auto-save-credential) for details.
If you want to stop the automatic saving of the credentials, uses [AutoConnectConfig::autoSave](apiconfig.md#autosave) option specifying **AC_SAVECREDENTIAL_NEVER**. Refer to the chapter on [Advanced usage](advancedusage.md#autosave-credential) for details.
## <iclass="fa fa-question-circle"></i> Does not appear esp8266ap in smartphone.
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:3.17499995px;line-height:1.25;font-family:'Times New Roman';-inkscape-font-specification:'Times New Roman, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332"
x="79.585876"
y="-32.471371"
x="79.343994"
y="-18.098808"
id="text9138-7-3-9-9-90-9"><tspan
sodipodi:role="line"
id="tspan1283"
x="79.585876"
y="-32.471371">Loads saved credentials from the flash</tspan><tspan
x="79.343994"
y="-18.098808">Loads saved credentials from the flash</tspan><tspan
sodipodi:role="line"
id="tspan1285"
x="79.585876"
y="-28.502621">that matches the last SSID stored in</tspan><tspan
x="79.343994"
y="-14.130058">that matches the last SSID stored in</tspan><tspan
Several parameters as follows of [AutoConnectConfig](apiconfig.md) affect the behavior of [AutoConnect::begin](api.md#begin) function. Each parameter affects the behaves in interacted order with the priority and apply to the logic sequence of [AutoConnect::begin](api.md#begin).
The following parameters of [AutoConnectConfig](apiconfig.md) affect the behavior and control a logic sequence of [AutoConnect::begin](api.md#begin) function. These parameters are evaluated on a case-by-case basis and may not be valid in all situations. The Sketch must consider the role of these parameters and the conditions under which they will work as intended. You need to understand what happens when using these parameters in combination.
- [immediateStart](apiconfig.md#immediatestart) : The captive portal start immediately, without first WiFi.begin.
- [immediateStart](apiconfig.md#immediatestart) : The captive portal start immediately, without the1st-WiFi.begin.
- [autoReconenct](apiconfig.md#autoreconnect) : Attempt re-connect with past SSID by saved credential.
- [portalTimeout](apiconfig.md#portaltimeout) : Time out limit for the portal.
- [retainPortal](apiconfig.md#retainportal) : Keep DNS server functioning for the captive portal.
You can use these parameters in combination with sketch requirements and need to understand correctly the behavior caused by the parameters. The following chart shows the AutoConnect::begin logic sequence including the effect of these parameters.
The following chart shows the AutoConnect::begin logic sequence that contains the control flow with each parameter takes effect.
<imgalign="center"src="images/process_begin.svg">
For example, [AutoConnect::begin](api.md#begin) will not exits without the [**portalTimeout**](apiconfig.md#portaltimeout) while the connection not establishes, but WebServer will start to work. A DNS server that detects the probe of the captive portal is also effective. So, your sketch may work seemingly, but it will close with inside a loop of the [AutoConnect::begin](api.md#begin) function. Especially when invoking [AutoConnect::begin](api.md#begin) in the **setup()**, execution control does not pass to the **loop()**.
For example, [AutoConnect::begin](api.md#begin) will not end without the [**portalTimeout**](apiconfig.md#portaltimeout) while the connection not establishes, but WebServer will start to work. Also, the DNS server will start to make a series of the captive portal operation on the client device. The custom web pages now respond correctly by the two internally launched servers, and the Sketch looks like working. But AutoConnect::begin does not end yet. Especially when invoking AutoConnect::begin in the **setup()**, control flow does not pass to the **loop()**.
As different scenes, you may use the [**immediateStart**](apiconfig.md#immediatestart) effectively. Equipped the external switch to activate the captive portal with the ESP module, combined with the [**portalTime**](apiconfig.md#portaltimeout) and the [**retainPortal**](apiconfig.md#retainportal) it will become WiFi active connection feature. You can start [AutoConnect::begin](api.md#begin) at any point in the **loop()**, which allows your sketch can behave both the offline mode and the online mode.
However, [**portalTimeout**](apiconfig.md#portaltimeout) can be used effectively in various scenes in combination with [**immediateStart**](apiconfig.md#immediatestart). Its combination is useful for implementing Sketches that can work in situations where WiFi is not always available. Namely, Sketch will support a running mode with both offline and online.
If AutoConnect staying in the captive portal exceeds the time limit, Sketch can switch a process-mode to offline according to WiFi signal detection. Conversely, it can start a captive portal immediately with intentional control to shift the process-mode to online from offline. Especially, You can activate the process-mode shift manually by trigger via external switches.
The [**retainPortal**](apiconfig.md#retainportal) option allows the DNS server to continue operation after exiting from [AutoConnect::begin](api.md#begin). AutoConnect traps captive portal detection from the client and redirects it to the AutoConnect menu. That trap will answer all unresolved addresses with SoftAP's IP address. If the URI handler for the source request is undefined, it returns a 302 response with `SoftAPIP/_ac` to the client. This is the mechanism of AutoConnect's captive portal. Captive portal probes will frequently occur while you are attempting on the client device's WiFi connection Apps and these implementations are varied each OS, so it not realistic to identify all probing URIs. Therefore, while retainPortal is enabled, it is not preferable to executing the sketch under the WiFi connection Apps on the client device. (Probably not work correctly) You need to exit from the WiFi connection Apps once.
Please consider these kinds of influence when you make sketches.
The [**retainPortal**](apiconfig.md#retainportal) option allows continuing the captive portal operation even after exiting from AutoConnect::begin. This option allows the use of the automatic portal pop-ups on the smartphone devices etc. even after the ESP module has established a connection with some access point in STA mode. (Excepts blocking a series of portal processes via intentionally accessing a URL outside the scope of **/_ac**. eg., if you try to communicate with the mqtt server without connecting to the access point, its access will be redirected to **/_ac** caused by the trap of the captive portal detection)
!!! info "The AutoConnect::begin 3rd parameter"
Another parameter as the [3rd parameter](api.md#begin) of AutoConnect::begin related to timeout constrains the connection wait time after WiFi.begin. It is the **CONNECTED** judgment of the above chart that it has an effect.
Hieromon Ikasamo
5 years ago
