Have made some nice progress with these hobby-project weather and surf IOT gizmos, I'd like to gift them to some friends. However this raises another obvious gap in my skillset.
What do you guys do so that a MKR1010 (or Uno Wifi Rev2) based device could be moved to a new location and a non-arduino-programmer-person could use their laptop (or smartphone?) to configure it with the usual info in the "secrets.h" tab of all the code examples?
I could probably figure out how to make it wake up on bluetooth, use that connection to query somebody, then shut down bluetooth, start wifi and get on the network. But that's a lot of rigmarole, and wouldn't necessarily store the info between reboots (??).
There's probably something I should google here, but I don't even know the search to do.
A common solution is to have a way to put the device in configuration mode. When in configuration mode, the device is a WiFi AP (access point). The user connects their mobile device or computer to the AP of the device and then opens the configuration web page in their browser. The web page allows then to configure SSID, wifi password, and any other configuration settings you might need. Once the device is configured, it switches to STA (station) mode and connects to the WiFi router using the SSID and password that was provided.
To make things easier, set the device up as a captive portal when it's in configuration mode so no matter what page the user opens in their browser after connecting to the device AP, it loads the configuration web page.
Yes that's it. I can certainly add a "configure" button to my creations, and go there when pressed, or while pressed during an init() or something like that. Some noob questions after that though:
Use Wifi.BeginAP() and something like the example code to ask the user for their wifi name and password, right? Is there a more complete example you could point at that involves entering strings and responses to HTML based user prompts?
Once the info is entered, it has to be put someplace in NV memory right? Otherwise this has to happen on every power up and/or init(). And that's not ideal. Thing is, I missed what the method was for storing a couple of variables in some NV location that can persist between power cycles, as I have always had things like UID and passwords hiding in secrets.h and thus stored in NV as code... again, is there an example of how to do this somebody might point to?
Given my cluelessness about #1 and 2, I'm sure you can guess that I didn't quite understand the suggestion to set up a captive portal. Perhaps it gets more obvious as I muddle though the first two?
ZainS:
Is there a more complete example you could point at that involves entering strings and responses to HTML based user prompts?
There's a really nice library for doing this:
unfortunately, it's only for ESP8266 (and beta support for ESP32). However, the API of the MKR WiFi 1010's WiFiNINA library is very similar to the API of the ESP8266WiFi library, so a lot of the code will still be relevant.
2. Once the info is entered, it has to be put someplace in NV memory right? Otherwise this has to happen on every power up and/or init(). And that's not ideal. Thing is, I missed what the method was for storing a couple of variables in some NV location that can persist between power cycles, as I have always had things like UID and passwords hiding in secrets.h and thus stored in NV as code... again, is there an example of how to do this somebody might point to?
[/quote]
That's exactly right. You can use this library:
ZainS:
3. Given my cluelessness about #1 and 2, I'm sure you can guess that I didn't quite understand the suggestion to set up a captive portal. Perhaps it gets more obvious as I muddle though the first two?
The WiFiManager library sets up a captive portal so the code for it will be somewhere in that library.
I've only ever set this sort of thing up on the ESP8266. Unfortunately, at that time the WiFiManager didn't support custom configuration fields and I needed them, so I just wrote my own code. I didn't know about the captive portal trick at that time, so I've never done this.
It would be great if support for the WiFiNINA library was added to the WiFiManager library, or a new library created for WiFiNINA. It's the sort of thing that practically every WiFi project is going to need, so perfect for a library. I'm not aware of such a thing, but it very well might exist.
pert:
There's a really nice library for doing this: GitHub - tzapu/WiFiManager: ESP8266 WiFi Connection manager with web captive portal
unfortunately, it's only for ESP8266 (and beta support for ESP32). However, the API of the MKR WiFi 1010's WiFiNINA library is very similar to the API of the ESP8266WiFi library, so a lot of the code will still be relevant.
2. Once the info is entered, it has to be put someplace in NV memory right? Otherwise this has to happen on every power up and/or init(). And that's not ideal. Thing is, I missed what the method was for storing a couple of variables in some NV location that can persist between power cycles, as I have always had things like UID and passwords hiding in secrets.h and thus stored in NV as code... again, is there an example of how to do this somebody might point to?
I've only ever set this sort of thing up on the ESP8266. Unfortunately, at that time the WiFiManager didn't support custom configuration fields and I needed them, so I just wrote my own code. I didn't know about the captive portal trick at that time, so I've never done this.
It would be great if support for the WiFiNINA library was added to the WiFiManager library, or a new library created for WiFiNINA. It's the sort of thing that practically every WiFi project is going to need, so perfect for a library. I'm not aware of such a thing, but it very well might exist.
Per, can you try if the WIFiNina enables to remember the ssid and password in esp32? a sketch with WiFi.begin() would connect to last used ssid
Although the documentation for the WiFiNINA library claims there is a WiFi.begin(), this is a lie. You always must specify at least the ssid parameter, and that is only for connecting to an AP without password.
pert:
Although the documentation for the WiFiNINA library claims there is a WiFi.begin(), this is a lie. You always must specify at least the ssid parameter, and that is only for connecting to an AP without password.
and without begin() status() doesn't return WL_CONNECTED?
Along the same lines as the above, what is the difference between WiFi.disconnect() and WiFi.end() ? They both have descriptions that suggest they are how to terminate WiFi.begin and WiFi.beginAP().
I'd like to be sure to do the right thing when my code (eventually, still working on it) needs to switch between AP mode and serving a web page for a user to input wifi credentials, and when that is done and the unit switches to being a regular WiFi client.
If my code started up with Wifi.beginAP(), followed by server.begin and so on, is the right thing to do to
WiFi.disconnect()
WiFi.end()
wait a bit
then
WiFi.begin()
etc etc...?
ZainS:
Thanks so much. Off to get lost on this for a while. Will likely shoot up more flares as I get off track...
Z
Hi ZainS,
Did you get the WiFiManager library to work with MKR Wifi 1010, so that it is set in configuration mode and a new SSID and password can be set? I'm trying to achieve the same, but it is not compiling (for MKR Wifi 1010) when including the required libraries as specified here: GitHub - tzapu/WiFiManager: ESP8266 WiFi Connection manager with web captive portal