Clarify cooperative process timing

This commit is contained in:
2026-09-06 19:44:19 +10:00
parent 9707d18b2b
commit fcd991c5a2
2 changed files with 2 additions and 2 deletions
+1 -1
View File
@@ -12,7 +12,7 @@ For complete end-to-end patterns, use [Provisioning lifecycle](PROVISIONING_LIFE
| startConfigPortal([apName, apPassword]) | Immediately starts a configuration AP and captive portal. |
| stopConfigPortal() | Immediately stops the configuration portal. |
| startWebPortal() / stopWebPortal() | Starts/stops the portal web server without the configuration-AP flow. |
| process() | Services active portal, scan, station-profile, and connection state. Call from loop(). |
| process() | Cooperatively services active portal, scan, station-profile, and connection state. Call from loop(); do not treat it as a hard real-time operation or rely on a fixed maximum duration. |
| getConfigPortalSSID() | Returns the current configuration AP name. |
| getConfigPortalActive() / getWebPortalActive() | Reports active configuration or web portal state. |
| setHttpPort(port) | Chooses the portal server port before starting it. |
+1 -1
View File
@@ -1,6 +1,6 @@
# Provisioning lifecycle
Choose a connection flow that matches the device's operating policy, then call process() regularly for as long as WiFiManager is active. The consuming firmware owns its product-service lifecycle and restart decision.
Choose a connection flow that matches the device's operating policy, then call process() regularly for as long as WiFiManager is active. It is a cooperative service call, not a hard real-time guarantee: target Wi-Fi or DNS work can occasionally take longer than a typical loop iteration. The consuming firmware owns its product-service lifecycle and restart decision.
## Choose a flow