[GH-ISSUE #296] WiFiManager Captive portal not showing up on my iOS devices #247

Closed
opened 2026-02-28 01:24:18 +03:00 by kerem · 31 comments
Owner

Originally created by @kirhim on GitHub (Jan 17, 2017).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/296

Hi, I am trying to make an IoT mood lamp with 8266. I am using Firebase server so that I could control the device from anywhere. Also, I have created an iOS app to control(turn on/off the lights) the device.

The problem I am having is this:
Say, I need to connect my device to a new network(wifi) but the device is not configured to the new network. In this case, I could just simply update the new network(SSID, PASSWORD) to Arduino IDE. But I am doing this project for commercial purposes and I want to provide simple and easy service to my customers. So I just want to connect any new network using my iOS app or in a simple way (without any coding). WiFiManager would make this possible right?

I was so glad that I found your code it was a real time saver for me.
The problem I am having is that even when I run the Arduino IDE code without any errors, I can't get the captive portal open in my iPhone and Mac Pro.
I guess I am suppose to generate a wifi network on my iOS device (ESP + ChipID) However, I don't see it. How do I get the view "How it looks" in the README.md file?

I've been trying to solve this issue for the past few days but still haven't found the right answer.
Please let me know if I am misunderstanding anything. Any comments would be very appreciate it.

Thanks,

Ki

Originally created by @kirhim on GitHub (Jan 17, 2017). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/296 Hi, I am trying to make an IoT mood lamp with 8266. I am using Firebase server so that I could control the device from anywhere. Also, I have created an iOS app to control(turn on/off the lights) the device. The problem I am having is this: Say, I need to connect my device to a new network(wifi) but the device is not configured to the new network. In this case, I could just simply update the new network(SSID, PASSWORD) to Arduino IDE. But I am doing this project for commercial purposes and I want to provide simple and easy service to my customers. So I just want to connect any new network using my iOS app or in a simple way (without any coding). WiFiManager would make this possible right? I was so glad that I found your code it was a real time saver for me. The problem I am having is that even when I run the Arduino IDE code without any errors, I can't get the captive portal open in my iPhone and Mac Pro. I guess I am suppose to generate a wifi network on my iOS device (ESP + ChipID) However, I don't see it. How do I get the view "How it looks" in the README.md file? I've been trying to solve this issue for the past few days but still haven't found the right answer. Please let me know if I am misunderstanding anything. Any comments would be very appreciate it. Thanks, Ki
kerem closed this issue 2026-02-28 01:24:18 +03:00
Author
Owner

@MarcFinns commented on GitHub (Feb 6, 2017):

behaviour confirmed but it happens randomly.
have you managed to get a solution?

<!-- gh-comment-id:277737093 --> @MarcFinns commented on GitHub (Feb 6, 2017): behaviour confirmed but it happens randomly. have you managed to get a solution?
Author
Owner

@tablatronix commented on GitHub (Feb 8, 2017):

click ap (i) ℹ️ , click forget network. If it thinks the password is saved, it won't redirect to the captiveportal sometimes. Using a random ap name helps sometimes.

<!-- gh-comment-id:278440127 --> @tablatronix commented on GitHub (Feb 8, 2017): click ap (i) :information_source: , click forget network. If it thinks the password is saved, it won't redirect to the captiveportal sometimes. Using a random ap name helps sometimes.
Author
Owner

@gsemet commented on GitHub (Mar 10, 2017):

Got this issue today. Forgetting the wifi network is enough, next try worked. Occured on some weird hostel connection, should be a bug from apple.

<!-- gh-comment-id:285664341 --> @gsemet commented on GitHub (Mar 10, 2017): Got this issue today. Forgetting the wifi network is enough, next try worked. Occured on some weird hostel connection, should be a bug from apple.
Author
Owner

@andysc commented on GitHub (Apr 2, 2017):

I'm seeing a similar problem - Mac OS (Sierra) says "The Wi-Fi network "GlowOrb-1234-5678" (the name I gave it) could not be joined". Sometimes it works. Other times not.
When it does work, and the captive portal window pops up, it sometimes loads the home page and works fine, and other times says "a problem occurred. The web page couldn't be loaded".

Debug is not showing any problem:
*WM: 192.168.4.1
*WM: HTTP server started
*WM: Request redirected to captive portal
*WM: Handle root

<!-- gh-comment-id:290991228 --> @andysc commented on GitHub (Apr 2, 2017): I'm seeing a similar problem - Mac OS (Sierra) says "The Wi-Fi network "GlowOrb-1234-5678" (the name I gave it) could not be joined". Sometimes it works. Other times not. When it does work, and the captive portal window pops up, it sometimes loads the home page and works fine, and other times says "a problem occurred. The web page couldn't be loaded". Debug is not showing any problem: *WM: 192.168.4.1 *WM: HTTP server started *WM: Request redirected to captive portal *WM: Handle root
Author
Owner

@pieman64 commented on GitHub (Apr 2, 2017):

@andysc have you tried changing the SSID to simply GlowOrb ?

<!-- gh-comment-id:290991778 --> @pieman64 commented on GitHub (Apr 2, 2017): @andysc have you tried changing the SSID to simply GlowOrb ?
Author
Owner

@tablatronix commented on GitHub (Apr 2, 2017):

Was the device previusly joined or had credentials already to a non existant ap?
Is sta mode is in constant search and fail, it causes ap to flake out, I am trying to address this in my pr.

Try pr #313

<!-- gh-comment-id:290991816 --> @tablatronix commented on GitHub (Apr 2, 2017): Was the device previusly joined or had credentials already to a non existant ap? Is sta mode is in constant search and fail, it causes ap to flake out, I am trying to address this in my pr. Try pr #313
Author
Owner

@MarcFinns commented on GitHub (Apr 2, 2017):

I confirm that with Mac and iOS it is very difficult to connect. It tends to immediately revert to the wifi it was connected to in the first place. In some cases i had to switch off the home router to make the ESP the only wifi and get the connection. Also, in many cases i have to manually open a browser and go to 192.168.4.1 otherwise the config page does not come up...

<!-- gh-comment-id:290992442 --> @MarcFinns commented on GitHub (Apr 2, 2017): I confirm that with Mac and iOS it is very difficult to connect. It tends to immediately revert to the wifi it was connected to in the first place. In some cases i had to switch off the home router to make the ESP the only wifi and get the connection. Also, in many cases i have to manually open a browser and go to 192.168.4.1 otherwise the config page does not come up...
Author
Owner

@andysc commented on GitHub (Apr 2, 2017):

@pieman64 no - was there a reason for suggesting that? (length, characters)?

<!-- gh-comment-id:290994601 --> @andysc commented on GitHub (Apr 2, 2017): @pieman64 no - was there a reason for suggesting that? (length, characters)?
Author
Owner

@andysc commented on GitHub (Apr 2, 2017):

@tablatronix yes, it was previously programmed (using normal ESP wifi stuff) to connect to a different AP

<!-- gh-comment-id:290994807 --> @andysc commented on GitHub (Apr 2, 2017): @tablatronix yes, it was previously programmed (using normal ESP wifi stuff) to connect to a different AP
Author
Owner

@andysc commented on GitHub (Apr 2, 2017):

changed AP to GlowOrb ... it didn't show up in the list of available access points until I turned wifi off then on, then it saw it. Spent a long time trying to connect to it (with the wifi logo going up and down)... before finally connecting, and doing the captive portal thing properly.
Oooh, are we onto something here @pieman64, or was that just lucky ;)

<!-- gh-comment-id:290995079 --> @andysc commented on GitHub (Apr 2, 2017): changed AP to GlowOrb ... it didn't show up in the list of available access points until I turned wifi off then on, then it saw it. Spent a long time trying to connect to it (with the wifi logo going up and down)... before finally connecting, and doing the captive portal thing properly. Oooh, are we onto something here @pieman64, or was that just lucky ;)
Author
Owner

@andysc commented on GitHub (Apr 2, 2017):

It also seems that once it has failed to find the AP that was configured (i.e. if you turn the access point off), and it goes into config mode, if you don't set up a new association, it forgets the old AP settings and makes hardly any attempt to connect to them if you power cycle the ESP.
Thus, if your network was down for a while and you turned the ESP on, it would fail to find your AP and then after that would require reconfiguration before being able to connect again.
Or is there a parameter to fix that somewhere?

<!-- gh-comment-id:290995471 --> @andysc commented on GitHub (Apr 2, 2017): It also seems that once it has failed to find the AP that was configured (i.e. if you turn the access point off), and it goes into config mode, if you don't set up a new association, it forgets the old AP settings and makes hardly any attempt to connect to them if you power cycle the ESP. Thus, if your network was down for a while and you turned the ESP on, it would fail to find your AP and then after that would require reconfiguration before being able to connect again. Or is there a parameter to fix that somewhere?
Author
Owner

@andysc commented on GitHub (Apr 2, 2017):

*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 0
*WM: SET AP STA
Entered config mode
192.168.4.1
GlowOrb
*WM:
*WM: Configuring access point...
*WM: GlowOrb
*WM: AP IP address:

... note the connection result 0, which comes up immediately.

Is there a way to find out what AP the ESP is hunting for?

<!-- gh-comment-id:290995512 --> @andysc commented on GitHub (Apr 2, 2017): *WM: AutoConnect *WM: Connecting as wifi client... *WM: Using last saved values, should be faster *WM: Connection result: *WM: 0 *WM: SET AP STA Entered config mode 192.168.4.1 GlowOrb *WM: *WM: Configuring access point... *WM: GlowOrb *WM: AP IP address: ... note the connection result 0, which comes up immediately. Is there a way to find out what AP the ESP is hunting for?
Author
Owner

@tablatronix commented on GitHub (Apr 2, 2017):

WiFi.printDiag(Serial)

<!-- gh-comment-id:290996225 --> @tablatronix commented on GitHub (Apr 2, 2017): WiFi.printDiag(Serial)
Author
Owner

@andysc commented on GitHub (Apr 2, 2017):

aha :) thanks - I also found:
Serial.print("Looking for ");
Serial.print(WiFi.SSID().c_str());
Serial.print(" / ");
Serial.println(WiFi.psk().c_str());

If you get to the captive portal landing page and click Configure WiFi - that seems to be the point it erases the old SSID and password.
They're coming up as blank in my debug.

<!-- gh-comment-id:290996892 --> @andysc commented on GitHub (Apr 2, 2017): aha :) thanks - I also found: Serial.print("Looking for "); Serial.print(WiFi.SSID().c_str()); Serial.print(" / "); Serial.println(WiFi.psk().c_str()); If you get to the captive portal landing page and click Configure WiFi - that seems to be the point it erases the old SSID and password. They're coming up as blank in my debug.
Author
Owner

@andysc commented on GitHub (Apr 2, 2017):

OK - so my point about network failures was not valid... as long as you don't go into the configuration page, your settings remain intact.

<!-- gh-comment-id:290997114 --> @andysc commented on GitHub (Apr 2, 2017): OK - so my point about network failures was not valid... as long as you don't go into the configuration page, your settings remain intact.
Author
Owner

@andysc commented on GitHub (Apr 2, 2017):

I've gone back to the longer SSID now (GlowOrb-1234-5678) and it seems to connect after a couple of tries, so I don't think the length was significant. SSIDs should be OK up to 32 chars, according to the spec. Whether all the ESP and library buffers are up to that, I don't know :)

<!-- gh-comment-id:290997611 --> @andysc commented on GitHub (Apr 2, 2017): I've gone back to the longer SSID now (GlowOrb-1234-5678) and it seems to connect after a couple of tries, so I don't think the length was significant. SSIDs should be OK up to 32 chars, according to the spec. Whether all the ESP and library buffers are up to that, I don't know :)
Author
Owner

@tablatronix commented on GitHub (Apr 2, 2017):

There are several known bugs these are both known. I cannot recall the loss of credentials one at this time.

<!-- gh-comment-id:291006017 --> @tablatronix commented on GitHub (Apr 2, 2017): There are several known bugs these are both known. I cannot recall the loss of credentials one at this time.
Author
Owner

@andysc commented on GitHub (Apr 2, 2017):

@tablatronix OK - thanks - the loss of credentials is not as I suggested - it's only if you go to the wifi config page but don't select or save any new credentials. I think that is a bug, but not as bad as I thought ;) Thanks for your help!

<!-- gh-comment-id:291008357 --> @andysc commented on GitHub (Apr 2, 2017): @tablatronix OK - thanks - the loss of credentials is not as I suggested - it's only if you go to the wifi config page but don't select or save any new credentials. I think that is a bug, but not as bad as I thought ;) Thanks for your help!
Author
Owner

@andysc commented on GitHub (Apr 2, 2017):

OK, I've found the problem with the wifi credentials getting deleted when you go into the Wifi config page...
in WifiManager.cpp, handleWifi calls WiFi.scanNetworks() to scan for networks.
in ESP8266WiFiScan.cpp, scanNetworks checks the current connection status, and if it is not STATION_GOT_IP or STATION_IDLE, then it calls WiFi.disconnect(false);
If the ESP can't find the AP it's looking for (which is what causes it to enter AP config mode in the first place), the status will be STATION_NO_AP_FOUND (3), so it will call disconnect.

WiFi.disconnect() deletes the currently stored SSID and password.

Now, whether the correct fix is to look at other options before calling disconnect, or whether calling disconnect is the wrong thing to do at all, I don't know, but I commented out the call to WiFi.disconnect(false), and it all works fine :)

Now the credentials don't get wiped if you go to the AP config page but don't save a new AP.

I'll leave others to work out the best fix, but I'm happy with this for now :)

<!-- gh-comment-id:291021341 --> @andysc commented on GitHub (Apr 2, 2017): OK, I've found the problem with the wifi credentials getting deleted when you go into the Wifi config page... in WifiManager.cpp, handleWifi calls WiFi.scanNetworks() to scan for networks. in ESP8266WiFiScan.cpp, scanNetworks checks the current connection status, and if it is not STATION_GOT_IP or STATION_IDLE, then it calls WiFi.disconnect(false); If the ESP can't find the AP it's looking for (which is what causes it to enter AP config mode in the first place), the status will be STATION_NO_AP_FOUND (3), so it will call disconnect. WiFi.disconnect() deletes the currently stored SSID and password. Now, whether the correct fix is to look at other options before calling disconnect, or whether calling disconnect is the wrong thing to do at all, I don't know, but I commented out the call to WiFi.disconnect(false), and it all works fine :) Now the credentials don't get wiped if you go to the AP config page but don't save a new AP. I'll leave others to work out the best fix, but I'm happy with this for now :)
Author
Owner

@andysc commented on GitHub (Apr 2, 2017):

BTW, that bit in connectWifi, where it says
*WM: Connection result:
*WM: 0
i.e.

  int connRes = waitForConnectResult();
  DEBUG_WM ("Connection result: ");
  DEBUG_WM ( connRes );

is greatly improved by adding this bit of code:

  // interpret connRes code
  switch(connRes) {
        case WL_NO_SHIELD:
                DEBUG_WM ("NO SHIELD");
                break;
        case WL_IDLE_STATUS:
                DEBUG_WM ("IDLE STATUS");
                break;
        case WL_NO_SSID_AVAIL:
                DEBUG_WM ("NO SSID AVAILABLE");
                break;
        case WL_SCAN_COMPLETED:
                DEBUG_WM ("SCAN COMPLETED");
                break;
        case WL_CONNECTED:
                DEBUG_WM ("CONNECTED");
                break;
        case WL_CONNECT_FAILED:
                DEBUG_WM ("CONNECT FAILED");
                break;
        case WL_CONNECTION_LOST:
                DEBUG_WM ("CONNECTION LOST");
                break;
        case WL_DISCONNECTED:
                DEBUG_WM ("DISCONNECTED");
                break;
  }

Sorry, I don't yet know how to do a pull request, so someone else will have to put it in if you want this ;)

<!-- gh-comment-id:291021555 --> @andysc commented on GitHub (Apr 2, 2017): BTW, that bit in connectWifi, where it says *WM: Connection result: *WM: 0 i.e. ``` int connRes = waitForConnectResult(); DEBUG_WM ("Connection result: "); DEBUG_WM ( connRes ); ``` is greatly improved by adding this bit of code: ``` // interpret connRes code switch(connRes) { case WL_NO_SHIELD: DEBUG_WM ("NO SHIELD"); break; case WL_IDLE_STATUS: DEBUG_WM ("IDLE STATUS"); break; case WL_NO_SSID_AVAIL: DEBUG_WM ("NO SSID AVAILABLE"); break; case WL_SCAN_COMPLETED: DEBUG_WM ("SCAN COMPLETED"); break; case WL_CONNECTED: DEBUG_WM ("CONNECTED"); break; case WL_CONNECT_FAILED: DEBUG_WM ("CONNECT FAILED"); break; case WL_CONNECTION_LOST: DEBUG_WM ("CONNECTION LOST"); break; case WL_DISCONNECTED: DEBUG_WM ("DISCONNECTED"); break; } ``` Sorry, I don't yet know how to do a pull request, so someone else will have to put it in if you want this ;)
Author
Owner

@andysc commented on GitHub (Apr 3, 2017):

I've made 3 small changes, which seem to help a lot...
Again, I'm sorry I don't know how to do a pull request, but here are the changes...

  1. in startConfigPortal use pure AP mode rather than AP_STA mode (@tablatronix suggested this in his PR)
  //WiFi.mode(WIFI_AP_STA);
  //DEBUG_WM("SET AP STA");
  WiFi.mode(WIFI_AP);
  DEBUG_WM("SET AP");
  1. also in startConfigPortal, go into STA mode before trying to connect with new credentials...
      WiFi.mode(WIFI_STA);
      DEBUG_WM("SET STA");

      // using user-provided  _ssid, _pass in place of system-stored ssid and pass
      if (connectWifi(_ssid, _pass) != WL_CONNECTED) {
        DEBUG_WM(F("Failed to connect."));
      } else {
        //connected
        //WiFi.mode(WIFI_STA);
  1. in connectWifi, do a wifi_station_disconnect before trying to begin wifi with new credentials, as we do before trying with old credentials.
  if (ssid != "") {
      //trying to fix connection in progress hanging
      ETS_UART_INTR_DISABLE();
      wifi_station_disconnect();
      ETS_UART_INTR_ENABLE();

     WiFi.begin(ssid.c_str(), pass.c_str());
  } else {

This has made connecting to the AP and bringing up the captive portal far more reliable on a Mac, and also made it more reliable at connecting to the new network when you've configured it.

<!-- gh-comment-id:291107656 --> @andysc commented on GitHub (Apr 3, 2017): I've made 3 small changes, which seem to help a lot... Again, I'm sorry I don't know how to do a pull request, but here are the changes... 1. in _startConfigPortal_ use pure AP mode rather than AP_STA mode (@tablatronix suggested this in his PR) ``` //WiFi.mode(WIFI_AP_STA); //DEBUG_WM("SET AP STA"); WiFi.mode(WIFI_AP); DEBUG_WM("SET AP"); ``` 2. also in _startConfigPortal_, go into STA mode before trying to connect with new credentials... ``` WiFi.mode(WIFI_STA); DEBUG_WM("SET STA"); // using user-provided _ssid, _pass in place of system-stored ssid and pass if (connectWifi(_ssid, _pass) != WL_CONNECTED) { DEBUG_WM(F("Failed to connect.")); } else { //connected //WiFi.mode(WIFI_STA); ``` 3. in _connectWifi_, do a wifi_station_disconnect before trying to begin wifi with new credentials, as we do before trying with old credentials. ``` if (ssid != "") { //trying to fix connection in progress hanging ETS_UART_INTR_DISABLE(); wifi_station_disconnect(); ETS_UART_INTR_ENABLE(); WiFi.begin(ssid.c_str(), pass.c_str()); } else { ``` This has made connecting to the AP and bringing up the captive portal far more reliable on a Mac, and also made it more reliable at connecting to the new network when you've configured it.
Author
Owner

@MarcFinns commented on GitHub (Apr 3, 2017):

You should:

  1. clone the repository so that you have your own private copy (1 click action)
  2. update the files in your repo as above
  3. submit it as pull request to the author so that he can pull the changes into the main branch
<!-- gh-comment-id:291111388 --> @MarcFinns commented on GitHub (Apr 3, 2017): You should: 1) clone the repository so that you have your own private copy (1 click action) 2) update the files in your repo as above 3) submit it as pull request to the author so that he can pull the changes into the main branch
Author
Owner

@andysc commented on GitHub (Apr 3, 2017):

@MarcFinns thank you :)

<!-- gh-comment-id:291116291 --> @andysc commented on GitHub (Apr 3, 2017): @MarcFinns thank you :)
Author
Owner

@tzapu commented on GitHub (Apr 3, 2017):

HI Andy, thanks, if you try to make the pull request, make sure you start and submit it to the development branch

cheers
alex

On 3 Apr 2017, at 14:26, andysc notifications@github.com wrote:

@MarcFinns https://github.com/MarcFinns thank you :)


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/tzapu/WiFiManager/issues/296#issuecomment-291116291, or mute the thread https://github.com/notifications/unsubscribe-auth/AC2FkIk9vkEZ57ZZYuO6qVFdZ8ZKm4aRks5rsNdJgaJpZM4LlJg_.

<!-- gh-comment-id:291136143 --> @tzapu commented on GitHub (Apr 3, 2017): HI Andy, thanks, if you try to make the pull request, make sure you start and submit it to the development branch cheers alex > On 3 Apr 2017, at 14:26, andysc <notifications@github.com> wrote: > > @MarcFinns <https://github.com/MarcFinns> thank you :) > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub <https://github.com/tzapu/WiFiManager/issues/296#issuecomment-291116291>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC2FkIk9vkEZ57ZZYuO6qVFdZ8ZKm4aRks5rsNdJgaJpZM4LlJg_>. >
Author
Owner

@MarcFinns commented on GitHub (Apr 3, 2017):

@tzapu-good to hear you are still evolving it!

<!-- gh-comment-id:291221835 --> @MarcFinns commented on GitHub (Apr 3, 2017): @tzapu-good to hear you are still evolving it!
Author
Owner

@andysc commented on GitHub (Apr 3, 2017):

GitHub n00b time again - sorry...
I've changed the files. Done a

git commit -a

Not sure what to do next. I think it's a

git push

but I'm getting

remote: Permission to tzapu/WiFiManager.git denied to andysc.
fatal: unable to access 'https://github.com/tzapu/WiFiManager.git/': The requested URL returned error: 403

maybe git push needs some parameters?

<!-- gh-comment-id:291316026 --> @andysc commented on GitHub (Apr 3, 2017): GitHub n00b time again - sorry... I've changed the files. Done a ``` git commit -a ``` Not sure what to do next. I *think* it's a ``` git push ``` but I'm getting ``` remote: Permission to tzapu/WiFiManager.git denied to andysc. fatal: unable to access 'https://github.com/tzapu/WiFiManager.git/': The requested URL returned error: 403 ``` maybe git push needs some parameters?
Author
Owner

@MarcFinns commented on GitHub (Apr 4, 2017):

Easiest way is to drag and drop the files via website...

<!-- gh-comment-id:291410843 --> @MarcFinns commented on GitHub (Apr 4, 2017): Easiest way is to drag and drop the files via website...
Author
Owner

@andysc commented on GitHub (Apr 4, 2017):

@MarcFinns I think your 3 step instructions missed out "click fork"...?
I'm getting the hang of this slowly.
Can't drag/drop files as I'm not authorised

<!-- gh-comment-id:291436491 --> @andysc commented on GitHub (Apr 4, 2017): @MarcFinns I think your 3 step instructions missed out "click fork"...? I'm getting the hang of this slowly. Can't drag/drop files as I'm not authorised
Author
Owner

@MarcFinns commented on GitHub (Apr 4, 2017):

You are authorised in your own rep!! (Not the original that you cloned)

<!-- gh-comment-id:291450241 --> @MarcFinns commented on GitHub (Apr 4, 2017): You are authorised in your own rep!! (Not the original that you cloned)
Author
Owner

@gsemet commented on GitHub (Apr 4, 2017):

You can find a lot of documentation online about the github workflow. I like this one.

<!-- gh-comment-id:291465468 --> @gsemet commented on GitHub (Apr 4, 2017): You can find a lot of documentation online about the github workflow. I [like this one](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
Author
Owner

@andysc commented on GitHub (Apr 5, 2017):

Thanks @Stibbons that was quite helpful (though missed out some crucial steps!).
I now have a PR #349
Thank you all for your patience :)

<!-- gh-comment-id:291952316 --> @andysc commented on GitHub (Apr 5, 2017): Thanks @Stibbons that was quite helpful (though missed out some crucial steps!). I now have a PR [#349](https://github.com/tzapu/WiFiManager/pull/349) Thank you all for your patience :)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/WiFiManager#247
No description provided.