Raspberry Pi WLAN setup (opens in new tab)

Long story short:

1. RPi broadcasts via BLE the wifi networks it can see

2. A ReactNative App lets the user choose the wifi network to connect to, pre-selected is the wifi network which the mobile is connected to

3. User enters wifi password

4. App sends it to RPI, still via BLE

5. RPi responds with IP address when successfully connected or with an error, all via BLE.

6. App can now talk to Pi via IP

7. BLE server on Pi shuts down. Done.

Advantage: user never needs to mess with changing to any ad-hoc wifi. Awesome UX.

I wrote exactly the same thing as a library, to allow user setup of the WiFi network from within an app as part of a hardware prototype - main difference being it was just a Go daemon running on the Pi. Didn’t end up using it or open-sourcing it but I will re-visit that, since it looks like there are a couple of use-cases.

I'll definitely give this a try.

Code is highly modular and maintainable.

Prior to stretch the wpa_supplicant.conf file needed to be modified in the main Raspbian partition which is inaccessible on the unix machine without setting up a virtual linux box and creating a vb disk image linked to the sd card. It was a bit of a pain.

With Stretch you can just add a wpa_supplicant.conf file and an empty ssh file to the boot partition which is accessible and you should be ready to go.

This still solves the pain point of there being lots of outdated headless instructions out there telling you to modify wpa_supplicant.conf in /etc/wpa_supplicant on the main partition. Would have saved me a ton of time that's for sure!

Looks nice and clean as well, design wise.

Typically I actually just mount the partitions and chroot with qemu-arm, upgrade packages, and do all of the setup before the SD card is ever inserted in a real Pi. proot[0] makes all this a walk in the park.

  mount /dev/sdX2 /mnt
  mount /dev/sdX1 /mnt/boot
  proot -q qemu-arm -S /mnt

> Download the BerryLan flavoured Raspbian image and flash the SD Card. We recommend Etcher to do that.

I’m curious. Why would anyone recommend people download and run a multi-100mb electron app instead of just using dd?

Especially for projects like this aimed at medium technical people.

My first idea was to put an OLED and a rotary encoder on the box. That way they can do a special dance on the button to enter setup mode, scroll through a list of wifi networks, and then tediously scroll through letters to enter the wifi password. I found a 1" OLED for cheap, and already needed a button for other things, so this was a cheap, effective solution.

But having to tediously type out a password with a knob sounded very user unfriendly.

Then I realized I could bring out a USB port, and they could plug in a USB keyboard! So I worked on that for bit. It's a lot easier to use. And the whole keyboard + tiny OLED idea was kinda fun.

But then I remembered the idea of doing a WiFi AP dance. That's where the device broadcasts as an AP, you connect with your phone, browse to a webpage to tell the device your Wifi network's info, and done! It's a solution that doesn't require an OLED or for me to bring out a USB connection. Cheaper and less mechanical engineering.

To that end I found Mozilla's IoT project which, conveniently, has RasPi compatible code for doing just that dance: https://github.com/mozilla-iot/gateway-wifi-setup (By the way, Mozilla's IoT project is neat and worth checking out).

That setup is quite similar to OP, except it doesn't require a separate app. Its downside is requiring the user to mess with the wifi settings on their phone. Not a huge deal (for my target audience) but can be annoying. (Hence why OP's project uses the Bluetooth connection; Smart!)

I've been tinkering with this on and off for about two weeks. While I wasn't thrilled with the solution, it was at least usable, cheap, and easy. ... then I realized I was dumb.

I have a camera on the device. I could just have them go to a website, punch in their wifi info, encode that as a QR code, and have them show it to the camera... (It'd be a secure website I set up, so no security hygiene problems). Same benefits of being cheap and easy, while being easier to use. Using `pyzbar` to do real-time QR detection I had something working within an hour. Just hold your phone in front of the camera and it'll automatically detect, decode, and setup the wifi settings.

The only downside to this approach is that I can't conveniently display a list of nearby wifi networks; so they have to type their SSID manually.

Figured I'd share my comedy of errors in case someone is looking for ideas for wifi setup solutions. Obviously if you're just setting up a RasPi yourself it's easier to just pop a wpa_supplicant.conf on the SD card. (Though I wish Raspbian also had a way to configure hostname, authorized_keys, and disable ssh password authentication through boot files. Only way to do that today is by mounting the root filesystem which isn't convenient on, e.g., a Mac)

https://github.com/cimryan/teslausb

(Props to Cim and Ray who are doing a ton of work making the project go, also!)

The goals/advantages, vs just using a USB thumb drive:

- will connect to your wifi network (when detected) and copy off your saved dashcam files (over CIFS, SSH, others) - fixes any FAT filesystem errors on the virtual USB drive (presented to the host using g_mass_storage) automatically; some Tesla software versions had/have a bug that left the filesystem dirty on shutdown, rendering some thumb drives unreadable until formatted again

- (in process testing) uses BTRFS to keep the drive online while taking snapshots to do the file copies (and other neat things I have planned, like extending the 1-hour rolling buffer that Tesla uses by copying off files older than 1 hr into a secondary backing store on disk to be copied off later)

- automated (headless) setup by putting a configuration file in /boot (including wifi setup)

- quite a few more ideas to come; love to hear more brainstorms too. Maybe with a little more work it's worth its own Show HN? :)

I've learned a lot about how little I remembered about bash, how Raspbian images are built, setting up Jenkins for automated builds, even controlling the LED on the Pi to show progress of headless setup. (Sometimes it's the little things...)

On the to-do list was something exactly like this post: provide a way to get to the files if you are away from your home network, and/or don't have a computer with a USB or SD reader handy. Say, if you had just gotten in an accident and wanted to get to the files pronto. So, a way to trigger the Pi popping into AP mode was my next area of exploration; timely! I was actually exploring having your phone make a BT connection that would cause the host to switch configs (either automatically, or using BT PAN. (And a web UI to grab files, make settings changes, etc.) Good thoughts on security in some of the comments, and glad to see others have thought through this.

Thanks to OP and others; I think there's a solution one way or another in several of these project ideas! And, as customary, PR's welcome :)

Just started using rpi with my underwater robots. Obviously the wifi cuts off when they dive, but doesn't reconnect always when they come back. Will definitely try this out.

[1] https://www.raspberrypi.org/documentation/configuration/wire...

On the other hand, I could see this being useful as an additional software package that gets run when the Pi can't find or join its usual network.