[PR #181] [CLOSED] F/non blocking api #1589

New issue

Closed

opened 2026-02-28 01:30:46 +03:00 by kerem · 0 comments

kerem commented

2026-02-28 01:30:46 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/tzapu/WiFiManager/pull/181
Author: @mrbig
Created: 6/2/2016
Status: ❌ Closed

Base: master ← Head: f/non_blocking_api

📝 Commits (8)

07e2ff5 configPortal works in non blocking mode
b9a2094 Non blocking autoConnect method
66b6991 Config portal uses noblocking connect mode
23b7f1d Add default connect timeout
f089ccc _apName and _apPassword are now copied to our space
1499672 Blocking mode for backward compatibility
d1421e2 Added example for non blocking mode
f3cb59c Updated examples to fix travis build

📊 Changes

3 files changed (+223 additions, -70 deletions)

View changed files

📝 WiFiManager.cpp (+152 -67)
📝 WiFiManager.h (+32 -3)
➕ examples/AutoConnectNonBlocking/AutoConnectNonBlocking.ino (+39 -0)

📄 Description

Hello,

this update introduces a non-blocking mode for the WiFiManager.

My devices use wifi merely to pull updates, and the don't even have connectivity every time they turn on. So blocking for several minutes with the config portal is not an option: I wanted to have my application run parallel with the config portal.

In this change I've broke down the main blocking functions (connect, portal event handling, portal connection) into smaller ones, and introduced an internal state maching (_currentState attribute) to keep track of the state.

Default is still the blocking mode, to provide backward compatibility with the original implementation. But in the internals it will do the non-blocking style, but wait before returning.

I've tried to keep the changeset minimal, unfortunately I had modify several functions.

There are still some small blocking events like the scan process, yet I believe they usually don't take more than a few seconds.

There's an example included to show how non-blocking mode can be used.

Any comments and suggestions are welcome.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/tzapu/WiFiManager/pull/181 **Author:** [@mrbig](https://github.com/mrbig) **Created:** 6/2/2016 **Status:** ❌ Closed **Base:** `master` ← **Head:** `f/non_blocking_api` --- ### 📝 Commits (8) - [`07e2ff5`](https://github.com/tzapu/WiFiManager/commit/07e2ff53b500fef5ed965c027d9153014854801d) configPortal works in non blocking mode - [`b9a2094`](https://github.com/tzapu/WiFiManager/commit/b9a2094851efcd508cab38c897b1c8bef4c7e1a3) Non blocking autoConnect method - [`66b6991`](https://github.com/tzapu/WiFiManager/commit/66b6991ab5b9b2ae65f7c837ba942ddc445a37d6) Config portal uses noblocking connect mode - [`23b7f1d`](https://github.com/tzapu/WiFiManager/commit/23b7f1d5dce11e6b315faf1d62e2c09913c62b8a) Add default connect timeout - [`f089ccc`](https://github.com/tzapu/WiFiManager/commit/f089ccc18a8223a5d404a901287d577abca4c0da) _apName and _apPassword are now copied to our space - [`1499672`](https://github.com/tzapu/WiFiManager/commit/149967217e0bef7533eb13a4c612e552a89ecc57) Blocking mode for backward compatibility - [`d1421e2`](https://github.com/tzapu/WiFiManager/commit/d1421e24c7cd53e28433443d397e9f2b0cfd4acd) Added example for non blocking mode - [`f3cb59c`](https://github.com/tzapu/WiFiManager/commit/f3cb59ca53878a918952cbf4d1833f0b9409bdcf) Updated examples to fix travis build ### 📊 Changes **3 files changed** (+223 additions, -70 deletions) <details> <summary>View changed files</summary> 📝 `WiFiManager.cpp` (+152 -67) 📝 `WiFiManager.h` (+32 -3) ➕ `examples/AutoConnectNonBlocking/AutoConnectNonBlocking.ino` (+39 -0) </details> ### 📄 Description Hello, this update introduces a non-blocking mode for the WiFiManager. My devices use wifi merely to pull updates, and the don't even have connectivity every time they turn on. So blocking for several minutes with the config portal is not an option: I wanted to have my application run parallel with the config portal. In this change I've broke down the main blocking functions (connect, portal event handling, portal connection) into smaller ones, and introduced an internal state maching (_currentState attribute) to keep track of the state. Default is still the blocking mode, to provide backward compatibility with the original implementation. But in the internals it will do the non-blocking style, but wait before returning. I've tried to keep the changeset minimal, unfortunately I had modify several functions. There are still some small blocking events like the scan process, yet I believe they usually don't take more than a few seconds. There's an example included to show how non-blocking mode can be used. Any comments and suggestions are welcome. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>