Wifi Wait Callback #596
Wifi Wait Callback #596
Conversation
|
If the wifiWaitCallback returns |
|
Just use configportal non blocking and call process in your loop |
|
although you can already do this I might merge this so you have 2 options.. I just think people will do something stupid in this loop and wonder why their portal isn't responding properly. |
|
Oh, thanks - I didn't know about the non-blocking mode because it's not in the documentation. I can understand not wanting to merge to keep this foolproof - a warning not to do anything slow in the loop might do the trick. I'd rather not use development branch so for now I'm using my fork off master and it's working great. Very useful to have some visual feedback on wifi connection state either way! |
|
Yeah that issue is all that exists at the moment hopefully someone can help write some docs |
|
If I get some time this weekend to implement the branch and try it out, I’ll write up some usage docs. Is this branch close to ready / merging?
… On Apr 26, 2018, at 3:49 PM, Shawn A ***@***.***> wrote:
Yeah that issue is all that exists at the moment hopefully someone can help write some docs
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Pretty much, there are about 2 major features that need completion, 90% of it is already documented in the overview in #500 and the source is well documented. |
|
oh and I need to fix up examples |
|
Can you think of any reason to still require this? |
|
Not really — I switched to the asynchronous development branch and it's working great. Thanks! |
When WifiManger is running the config portal, we currently don't have any control and can't make anything happen. We'd like to do some fun things to indicate current status, as well as escape the Wifi configuration step if we need to run offline. This change introduces a
wifiWaitCallbackthat gets called every WiFi config portal loop.