Improve WiFi setup and management

The WiFi setup and management process is one aspect that we know is not 100% yet.

Desired outcome:
A robust wifi setup and management solution that works across a broad range of network configurations, and reports clear success and failure messages.


As a bit of background, the Mark II currently uses a fork of the Wifi Connect package from Balena.

Known bugs include:

  • If you enter an incorrect password, the access point (AP) sometimes does not get restarted. It works most of the time, but occasionally just hangs and we haven’t yet delved into why.
  • Some users have reported that their SSID isn’t showing up in the list presented. Possibly this only occurs in locations with a lot of networks, and may be simply that only so many networks are presented.
  • Very occasionally the AP doesn’t get generated at all. Might be a Raspberry Pi firmware issue, or EM interference based on that users environment, or something else entirely. Needs more investigation.

In each of these cases, the work around is to restart your Mark II as they seem to be intermittent issues.

Limitations / improvements:

  • How long should we attempt to connect to an existing network before triggering WiFi Connect setup again? Eg is the router just rebooting after a power outage, or is the network actually gone.
  • Support for hidden SSID networks
  • Better UX for passwordless networks - you can submit an empty password but that’s not obvious to users
  • Support for networks that utilize MAC address filtering. Eg how do we surface the MAC address of a device to the end user if its needed, and before it is needed (ie before it gets on the network).
  • Support to connect to networks with their own captive portals eg hotels, universities, etc
  • Better status messages based on different behaviour - eg when invalid credentials are entered we know that it failed, but would be great to tell the user why.
  • Sort presented SSID’s by signal strength so that the most likely network is at the top of the list. Particularly important in busy apartment buildings.
  • The ability to join a new network. Currently the setup will not run if the device can connect to the internet.
  • The ability to modify or remove existing configurations.

Thanks to @mickcoyne for prompting this feature request.

If you see other issues with the Wifi setup, or have other suggestions for improvements, please let us know here.

One issue I ran into was that going to start.mycroft.ai on my tablet did not work after connecting to the mycroft access point. I realized right away that this was because I have both DNS-over-HTTPS enabled in my browser as well as “Private DNS” enabled at the OS level in Android, both of which can cause the device to completely ignore the DNS configuration provided by the DHCP server. I had to do some sleuthing and guesswork to figure out what IP address to connect to before I could continue the process.

At least some Android devices have private DNS enabled by default, and browsers are getting more and more aggressive pushing privacy features like DoH so it’s possible that some non-technical users could find themselves stuck at this step. A possible solution might be to use the IP address instead of start.mycroft.ai, or at least display the IP address on the screen in case the domain doesn’t work.

edit–actually a better solution (in my opinion) would be to use the touch screen to let the user select an access point, and present a virtual keyboard to type the password directly without needing a separate device.

2 Likes