mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 09:05:56 +03:00
[GH-ISSUE #165] Use EEPROM to store additional parameters ? #130
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#130
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 @RudolfLapie on GitHub (May 9, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/165
I think WifiManager stores the SSID & Password by default in EEPROM. I would like to use the rest of the EEPROM for my own application. What part of the EEPROM is 'safe' to use or said differently, which bytes/offsets are used by WifiManager ?
@kentaylor commented on GitHub (May 9, 2016):
WiiManager does not store SSID and password in user space.
@RudolfLapie commented on GitHub (May 10, 2016):
Thanks Ken. That resolves it for me as it means, I can safely use all of the EEPROM for my device.
@pieman64 commented on GitHub (May 10, 2016):
Out of curiosity am I correct in thinking SPIFFS that WiFIManager uses for parameters (not SSID and PWD) is different to EEPROM?
@kentaylor commented on GitHub (May 10, 2016):
There is a memory map at https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map . While firmware and system data is in the same EEPROM as user data it is ROM from the point of view of a user sketch.
@pieman64 commented on GitHub (May 10, 2016):
@kentaylor looked at your notes for your fork.
I use @tzapu's original version quite a bit and none of my ESP's have ever bricked. I find the original to be very reliable.
Where does your version store additional parameters?
@kentaylor commented on GitHub (May 11, 2016):
@pieman64 When you say you have used the original "quite a bit" and found it to be "very reliable", I'd respond, you must have been lucky.
As of yesterday it was firmly established that there is a fault in the underlying Espressif SDK that has caused WiFiManager to be unreliable and corrupt memory. It is this memory corruption that was causing the bricking I referred to. There were quite a few reports from other applications but it was WiFiManager failing and the ability of the Espressif developer @igrr to reproduce the failure that allowed the fault in the Espressif SDK fault to be identified. You will see that testing from @tablatronix shows both versions of WiFiManager failing but it is complicated. It is a developing situation and I'm not sure @igrr has sorted all of the issues yet. For example bricking was rare for me but an inability to connect to WiFi without rebooting was much more common. This doesn't involve writes to memory that could have caused corruption but maybe it only occurred when memory had been corrupted by previous writes. Follow the sequence of events at esp8266/Arduino#1997 .
Both versions store WiFi parameters in the same memory locations via Espressif SDK functions. The WiFiManager library doesn't store other parameters in non volatile memory. There are example sketches in both versions that do but I haven't looked at them much. This is one https://github.com/kentaylor/WiFiManager/blob/master/examples/ConfigOnSwitchFS/ConfigOnSwitchFS.ino was contributed by @battika .
@tzapu commented on GitHub (May 11, 2016):
@kentaylor i don't think he was that lucky, for most people WiFiManager seems to be just fine. I myself have got around 6 modules running at all times, with power cuts, routers and internet going down that seem to be just fine. a mix of battery and mains powered as well. Some have been running for almost a year, if not more. (none on 2.2.0 though)
At the same time, there have been users having connection issues, but judging by number of downloads, the number of people reporting issues, has been really really really small... Don t have other data to support this though, i can't know how many instances are in actual use.
I have had the umm_malloc bricking happen only once and had to erase the flash with esptool, and after sdk 2.1.0. Links helped me work through it then and added a patch to umm_malloc that seems to not sort it completly though. these issues are more likely to appear in development i think, when you keep switching settings, etc. "production" modules would be fine. I have to say i haven't done much development under sdk 2.2.0, so maybe the issues are a lot more prevalent now.
also possible is that people did not update from SDK 2.0.0 and do not have these issues
also, @kentaylor , thank you very much for all your help, much appreciated
@tablatronix commented on GitHub (May 11, 2016):
Yeah it always worked fine for me, the trouble with development is you do the same thing over and over with latest dev versions,
@mihino commented on GitHub (May 5, 2019):
Would be nice to have it directly in WiFiManager lib, but till then: check this post for EEPROM with WiFiManager: https://homecircuits.eu/blog/esp8266-wifimanager-eeprom/
@MasTerYoDa-60 commented on GitHub (Feb 28, 2023):
So good!! Well, where this data is storage??? Thank you!!