mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 17:15:53 +03:00
[GH-ISSUE #106] Blynk and V pins #82
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#82
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 @scropion86 on GitHub (Feb 16, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/106
it's a question not an issue actually
thanks.
@tzapu commented on GitHub (Feb 16, 2016):
hi, you could do it by issuing a
wifiManager.resetSettings()from the virtual pin and then with a delayESP.reset() or ESP.restart()you will of course loose ssid/password so would have to enter them again. If you have other settings saved to FS those will be ok
@tzapu commented on GitHub (Feb 16, 2016):
see here for a blynk sample, this is as far as i got, it s also not tested
https://gist.github.com/tzapu/a909c357175fd8f08ce6
@pieman64 commented on GitHub (Feb 16, 2016):
@tzapu I notice with ESP's that many sketches with reset have delays before AND after the reset. I can understand the delay before the reset can be used to give users time to see the system is being restarted but I can't understand the delays after the reset. Generally my Wemos D1 mini responds pretty well to a reset but it is far from 100% effective. What is your understanding of the delays after reset and any particular time frame (I see 5 seconds regularly)?
@tzapu commented on GitHub (Feb 17, 2016):
well, in my case, some time ago, i would just have the module not restart if there was not a delay after.
similar to how deep sleep needs a delay after it to work.
the 5 seconds is arbitrary, it doesn t wait that amount of time anyway. it could possibly work just as well with 0 or 100 ms
since it s not hurting anything, i guess it s better to just leave them there and forget about it :)