How to connect headless Pico to WIFI?

[MarByteBeep]

It's a typical chicken egg story; how to connect to the router, without being able to enter ssid/password?

It kinda baffles me that after all these years, there doesn't seem to be a standard to safely connect a IoT device to your router. At least, I cannot seem to find it.

Sure. There is the access point and captive portals "solution". Set pico in AP mode, capture all traffic and redirect user to a simple HTML in which they can enter WiFi credentials. But this approach is notoriously user unfriendly and very though to setup. I have found no working example out there yet.

And WPS support (press button on router and let pico scan for it, which arguably seems the easiest and user friendliest solution) seems non existent in the network library of micropython 😔

So how do people connect their Pico to WiFi? Please tell me that there is a better solution than manually adding a SSID/password in some python file? 😄

[mendenm]

Adding the SSID/password in a python file is how I do it. Since I don't consider my home WiFi password to be super-secret, this works. If you have stronger requirements, it might not. I actually have a dictionary of SSID/pass pairs, so I scan for all SSIDs and then see what matches a known pair.

[MarByteBeep]

I wonder if this is feasible. Have a device running an AP, with the Pico initially connecting to that AP using hard coded credentials. It then opens a secure link to the AP (e.g. MQTT over TLS) and retrieves the credentials of the network it really wants to connect to. The link to the AP, and the AP itself, could be downed.

This is basically the idea of a captive portal. The secure part isn't needed, since the password+ssid still need to be stored on the Pico in plain text.

I glued together some working prototype for that (extended from the phew! repo). But captive portals are tough to code. Problem is that they most likely aren't future proof either, since they rely on DNS redirection. And this already fails on PCs because of multiple DNS fallbacks.

[andrewleech]

I feel like WPS is surprisingly unpopular, never quite took off the way it possibly should have.
It does seem like it should be a good system for IOT devices in general, though I never really see it used in off the shelf products, but maybe that's just me. It's essentially the same as the standard process for pairing zigbee devices which works well.

The captive portal approach is popular, even if it's just a semi-standardized hack of a workflow that usually works ok.
There's a couple of libraries I've seen for micropython providing this, such as https://github.com/graham768/MicroWiFiManager - this one includes the dns redirect to make it an actual captive portal. Note their instructions are still based on the now-deprecated upip tool, so the manual install approach is probably best for now.

[MarByteBeep]

The key is your comment about that it "usually" works 😊 I've spent the last two days trying to hack together a captive portal solution based on a few repos out there. The one you proposed I did check out as well. But all these libraries are fiddly to work with. They have problems with memory management, and/or don't cleanup resources after usage. Sockets are left open. Tasks in the event loop are not removed. It's such a mess. And the test cycle is very slow, so it's hard to make progress.

To me WPS sounds like the best solution. But for some reason even after 5 years, no effort has been made to merge that PR into the micropython library.

And it begs the obvious question: why? Why don't we have a proper solution for this? I mean it's not like no one needs to have internet access on the IoT device. It's literally in the name 😊

[mendenm]

@MarByteBeep I'm not disagreeing with you about alternatives. However, I have used the microdot web server on a Pico-W with months of uptime, and no memory management issues. I think they got it right. And it has the ability to gracefully shut down (or just leave it running... I don't think it takes too much RAM to keep a stub open).

[andrewleech]

microdot isn't the problem mentioned here, the lack of stable captive portal / wifi manager is.

That WPS merge request isn't merged because no one who wanted to use WPS has finished a cross-port working solution suitable for merge.