I would like to use an ESP8266 (which I already have) to trigger push notifications using the Pushover service. Actually, I have that part working, but all the credentials are hard-coded in the sketch. I would like to use WiFiManager to eliminate the need to ever recompile the sketch.
I'm currently running IDE v1.8.8 in portable mode, with ESP8266 package v2.5.2. I see things suggesting that I should be at IDE v1.8.19 and some later version of the ESP8266 package, and that the WiFiManager library by tzapu maybe isn't the best version to use anymore - something about SPIFFS vs LittleFS, and maybe other things. But I have no experience with WiFiManager, so it would be helpful to know what to use..
To provide the info for the push notification, in addition to the WiFi credentials I also need to provide the app key and a user key, as well as a person's name that will appear in the notice text. So that would be three fields in addition to SSID and password.
If WiFiManager goes into setup mode, would the three fields be pre-populated with whatever the latest saved versions were? Also, if the Wifi part still works fine, how do I get it to go into setup mode anyway when I need to change some other field.
I've tried watching videos, but they all seem to assume a level of knowledge and experience that I don't have. So any guidance on this would be appreciated.
I have used WiFiManager by Tzapu many times, mainly on ESP32 projects, and still do.
I wouldn't worry about SPIFFS vs LittleFS for credentials. I think Little FS is preferred for data that changes oten, because of the added wear leveling when writing often.
You can always use "Preferences" for that if needed.
Yes, you can pre-load data in the fields and do much more.
I use a button to force WiFiManager to re-open. Examples for that are in the documentation.
Leo..
Only in v 1.8.19 of the IDE were the bugs in the network ports properly fixed, so if you want to use OTA updates, that version is the correct one to use. Better in fact than v 2.x.x which in my case still doesn't recognize ESP8266 network ports, but does recognize ESP32 network ports.
v2.5.2 of the ESP8266 is rather old and if i remember correctly had some bugs that were not acceptable to me (probably related to ESP8285) I still also use v 2.4.2 which is good, but any version below 2.7.4 (i think) does not support https secure connections, and i think LittleFS was not supported in core version 2 at all and SPIFFS deprecated from there on.
If you are using a small flash size board like i do in some cases (1MB) and you want to have OTA updates + some SPIFFS then using an older core version can be helpful since the newer versions result in bigger binary file size. Otherwise the newest version is the way to go. There are bugs in the older versions that could cause issues.
My v2.5.2 works fine for secure connections, meaning that it does an https connection on port 443. But I have always used the setInsecure() function to bypass dealing with the server's certificate or fingerprint. That has worked with both IFTTT and Pushover, and it means I don't have to know the current time either. Apparently "they" want to take all certificates down to a life of 30 days or less (not clear why this is a good idea), and if that happens, setInsecure() will become really handy because when the certificate changes, you don't have to do anything. Of course, it's not secure since someone could pretend to be IFTTT or Pushover, but I think that's not a big risk for most embedded stuff.
Well, thanks for the responses. I think I will use the latest ESP8266 package, but will stick with the regular WiFiManager.
@Juraj, thanks very much for the link to your project. It looks like it's the perfect example for me to study.
I have another question about using WiFiManager with the ESP8266. I have updated to IDE v1.8.19, ESP8266 boards package v3.1.2, and WiFiManager v2.1.17. The latter two are the latest versions.
If the ESP8266 has been directed to remember WiFi credentials, then when WiFiManager opens the access point to get new data, it displays the most recent SSID in that box. But in the Password box it displays "**********". To me that implies that it has also populated that box with the remembered password. But that's not the case. If you don't type in the correct password, the attempted connection to the SSID will fail.
Is there a way to make WiFiManager pre-populate that password box with the remembered password, or if that's insecure, if the password box is left blank, then can it use the remembered password that goes with the remembered SSID (without disclosing it)?
I would need to do this in the sketch, not by changing the library. Well, I can't find anything like that, but wondered if anyone knows of an example of it being done.
The Password "********" placeholder is just text defined in wm_strings_en.h:
const char S_passph[] PROGMEM = "********";
I don't think there's any way to change that to something like "enter password" without changing the library.
But mainly I want it to use the password it remembers if that box is left blank. Is there a way to make that happen?
I am not that familiar with that particular library to be honest. I use my own system and UI on all the boards i have.
Well you could just do that. On the other hand you could first investigate the library files and see where that is actually used. The 'find' tool should be able to help you out with that. I could do the searching for you, but i actually suggest you use notepad++ to open all of the library files and do a search through all open files and see where it shows up. There is a chance that it is somehow overridable somehow. Also there is the author of the library that could support you, possibly by starting a discussion on github.
The reason i decided on my own system is of course exactly that i want it the way i want it and i want it to look the same way as the rest as well. In HTML there is a so called 'password input that show as input as * . If the correct password is not remembered but the SSID is, then something is not quite right. Either in the library or in the way you are using it.
?
WiFiManager only opens when it can't connect to the stored SSID/PW.
You can of course force WiFiManaf=ger to open (by turning the router off or use a button).
But you only would be doing that if something needs to change.
It won't remember/store special data from extra custom fields in WiFiManager unless you select SSID and enter PW again. Maybe that's good for added security.
Leo..
Hmm well i think the Author actually used to be active here on the forum in the past.
Yeah that is quite a lot, obviously the author is busy with other stuff.
Actually looking through some of the issues, it appears no actual maintenance is happening, but there is an active collaborator. I do suspect that a lot of those issues aren't actual issues, but rather support requests, and they just never get closed even if resolved (saw that in a few) .
So i guess you could just open another issue and see what happens. That said, what @Wawa said is what it says in the documentation, so maybe if you post your code we (or he mainly) can have a look and see if something you have done is not the way it should be done.
No, you can bring up the access point any time using startConfigPortal() even if WiFi is fine. This was added because the same portal can be used to bring in other data, like various keys, that are stored in LittleFS. So the WiFi may be fine, but you need to change a key. However, it still won't save the data and exit properly without first testing the WiFi connection, and that requires that you type in the password - even though it already knows the password if you haven't changed the SSID. I guess it's a security thing as you say, but it seems it could use the password it remembers if that field is left blank.
Later....
Ok, I found setShowPassword(), and it does indeed show the remembered password in that box. But ---- it doesn't use it. You still have to type in the password or the connection will fail. Rats!
So basically, the remembered password is just a placeholder in the box instead of the "******" string. But it's not really "entered" as the password. The SSID, on the other hand, is used without having to select it from the network list or type it in. So I need to go back to the source code and try to find where this is all done, and figure out what's different about how the two fields are handled.
well i guess that is the English versions of it. Hmm i think the must be a script somewhere.
type='password'
so i guess that is ok. Ah look it's somewhere. You i believe this is actually the thing that turned me off from it. Not so much that particular thing, but the complete lack of transparency in the code to me. HTML is not something i do every day, and the way the pages are created ar not the way i would do this.
I looked at your code before, but concluded it was above my pay grade. It had HTML, which I know nothing about. But I will look at it again.
I'm puzzled by your picture of the config screen with "SAVE" at the bottom. It doesn't show the wifi credentials at all, which is where I'm having the password problem. I don't have a problem with the other fields. Can you explain?
the html is for drop-down-list selection of values for the parameters. WM doesn't support it natively. you can ignore the *ComboBoxHtml parameters in my sketch
My problem is specifically with the Password field of the wifi credentials. I don't see anything in your code that suggests that field would be handled differently from my code. In fact "password" doesn't appear anywhere in your repo except the LICENSE file.
I want to report that I've solved my problem with the password field. I didn't know it existed, but Google's AI provided the "setBreakAfterConfig(true)" setting. That causes the attempt to connect to the specified network to be skipped unless new text is entered in either the SSID or Password blocks. So while setShowPassword() shows the current remembered password, it doesn't matter that it isn't really entered in the box because no attempt is made to use it to connect.
Of course if someone really wants to switch to a new SSID, they would know that they need to type in the new password as well.
The only minor snag is that BreakAfterConfig makes startConfigPortal() return "false" even though the other data is retrieved successfully. But I get around that by just not checking the return boolean, and saving the other data in LittleFS regardless.
Thanks to everyone who offered suggestions and comments.