Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

No way to tell if Exit has been pressed when using (non-)blocking startWebPortal() #1452

Closed
nullstalgia opened this issue Jul 13, 2022 · 8 comments
Labels
bug Validated BUG

Comments

@nullstalgia
Copy link

Basic Infos

Hardware

WiFimanager Branch/Release: Master

Esp8266/Esp32: ESP32

Hardware: ESP32-WROOM

Core Version: ESP32 PlatformIO Core V5.0.0

Description

  • This is also an issue stating that if you use startWebPortal() with blocking enabled, the sketch continues at that point and the web server is unreachable. So I turned blocking off and use process() in the loop()

After the user clicks Exit on the UI, wifiManager.getWebPortalActive() stays true, and wifiManager.getConfigPortalActive() stays false.

abort seems to be the only variable that does change in line, but it is private. I threw in a getAbort() so I could get my project working the way I intend, but hopefully these issues can be addressed in a smarter way. :)

tablatronix added a commit that referenced this issue Jul 14, 2022
Possible fix
@tablatronix
Copy link
Collaborator

Yeah makes sense, exit for webportal is undefined

#1353

@tablatronix
Copy link
Collaborator

tablatronix commented Jul 14, 2022

I added a WebPortalActive=false fix, as it seemed to be missing, and should get stopped

Another workaround is to override the server->on(WM_G(R_exit), callback.

I guess the ideal solution is to add a exit callback and disable this stuff in non blocking, not sure

@tablatronix
Copy link
Collaborator

tablatronix commented Jul 14, 2022

Another solution would be to add enum returns to process() instead of a bool.. for more useful states. I might do this anyway

@tablatronix tablatronix added the bug Validated BUG label Jul 14, 2022
@nullstalgia
Copy link
Author

Great, this seems to work! I think once I had it stuck on 0 across reboots before this patch, but a quick test did not reproduce that issue... Could be user error there.

I'll let you close the issue if you wish to use it as a marker for the process() enums.

But I had a quick question: Is there a reason the parameters can not be set in the web portal? It does not affect my use case, so I don't mind, but I was just wondering.

@tablatronix
Copy link
Collaborator

Not sure I understand, can you elaborate what is not working with parameters?

@nullstalgia
Copy link
Author

When connecting to the AP from autoConnect(), the parameters appear in the Setup WiFi page.

When connecting via the local IP when using startWebPortal(), the parameters do not appear in the Setup WiFi page. I assumed this was intentional.

@tablatronix
Copy link
Collaborator

Are you sure its not just because your params are out of scope?

OekoSolveMG added a commit to OekoSolveMG/WiFiManager that referenced this issue Jul 15, 2022
@nullstalgia
Copy link
Author

You are 100% right. That totally went over my head.

Thanks again for the quick help and great library!

tablatronix added a commit that referenced this issue Jan 13, 2023
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
bug Validated BUG
Projects
None yet
Development

No branches or pull requests

2 participants