mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 17:15:53 +03:00
[GH-ISSUE #308] configPortalTimeout improvements #259
Labels
No labels
📶 WiFi
🕸️ HTTP
Branch
DEV Help Wanted
Discussion
Documentation
ESP32
Example
Good First Issue
Hotfix
In Progress
Incomplete
Needs Feeback
Priority
QA
Question
Task
Upstream/Dependancy
bug
duplicate
enhancement
invalid
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/WiFiManager#259
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @tablatronix on GitHub (Feb 7, 2017).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/308
only timeout configportal if ap has no client
@tablatronix commented on GitHub (Feb 8, 2017):
pr
https://github.com/tzapu/WiFiManager/pull/310
@tablatronix commented on GitHub (Feb 8, 2017):
My fix was simple and to keep configportal open if a client was connected to AP. Essentially ignore timeout if someome is connected to AP.
This avoids dealing with last request timestamp bumping and all the problems that creates and fails to solve for.
This may require a new timeout fallback to prevent someone from just sitting on configportal and it never timing out.
I do see how this could create a problem with not a way to timeout a user stuck in webportal....
I was trying to address 2 things
AP is not found, unit gets stuck in configportal...
so implement a short configportaltimeout, so that it keeps retrying AP, but then when you are using the configportal you can timeout in the middle of using it.
I think the only perfect solution is to implement some keep alive when someone is on the web portal.
configportaltimeout is pretty unusable if you can get kicked out of the portal at anytime..
@tzapu commented on GitHub (Feb 8, 2017):
in my mind, the timeout should be paused or reset if there is a client connected to the ap or maybe just increase the timeout interval with 30 seconds (for example) each time the loop happens, it has not timed out yet and there is someone connected... this should give in effect a timeout that will happen 30 seconds + whatever was left of the timeout after the client disconnected...
a bit hacky maybe, but not bloated i think
@tablatronix commented on GitHub (Feb 8, 2017):
So just add a static global timeoutbuffer variable and add it to the timeout calculations ?
Probably do not want to modify user timeout variable, nor the configportalstart timestamp variable, unless we rename it to something more logical , but someone might be using it.
Maybe we should extend the timeout from disconnect, This way a user knows exactly when a timeout will occur, not a fan of the black box timeout buffer.
configPortalTimeout = timeout after last user disconnects, or if no user connected.
seems simpler.
unless user clicks cancel ?
see this just gets more and more complicated use cases. hmm
@tablatronix commented on GitHub (Feb 8, 2017):
hows this?( I also abstracted it so it can be enhanced in the future )
@tzapu commented on GitHub (Feb 8, 2017):
that looks brilliant to me, thank you very much
@tablatronix commented on GitHub (Feb 8, 2017):
pushed to PR
@tablatronix commented on GitHub (Feb 8, 2017):
In the future maybe implement a keep alive headers or a microajax keepalive, and use that data to determine page access.
@tablatronix commented on GitHub (Feb 20, 2017):
It looks there might be a problem with this solution.
Depending on how the client disconnects, wifi_softap_get_station_num continues to report client connected.
@tablatronix commented on GitHub (Feb 21, 2017):
This seems to be caused as with a ton of other problems, by bad sta connect while trying to run softap, it seems it causes issues with dhcp as well.
I was able to stabilize this a bit by
WiFi.disconnect(true);before enabling softap if not connected.setting
mode(WIFI_AP)was not enough.Ill keep testing
@FernandoGarcia commented on GitHub (Apr 6, 2017):
Hi @tablatronix @tzapu!
After this update the portal never goes to timeout even without any client.
Best regards.
@FernandoGarcia commented on GitHub (Apr 6, 2017):
I'm sorry was my mistake I don't know the reason but I changed the timeout from seconds to milliseconds. :D
So my timeout was 300 000 seconds.
@tablatronix commented on GitHub (Feb 8, 2018):
added webclient checking to bump timeouts, good enough until I decide to add js and ajax keepalives.
1c4011bfb4both can be toggled