8

I'm building a connected device without a screen that needs to be connected to home Wi-Fi. WPS is not an option. The device will have a Bluetooth module in addition to Wi-Fi hardware. QR codes can be done as well.

I'm also building an iOS app to walk the user through the steps of setting up the device and giving it access to the Wifi setup. Can someone please help with the technical details around the best communication protocols to leverage to:

  1. Have the device connect with the app so that the user can use the app to setup the device

  2. Use the app as the screen for the device to select from available SSIDs, enter password and connect to home Wi-Fi

I've considered the two options below:

  1. Use BLE to connect the iOS app with the device and then use BLE to pass Wi-Fi SSID list, login credentials between device and app.

  2. Use Wi-Fi only to connect with the device and pass Wi-Fi SSID list, login credentials between device and app

How do they compare in terms of user experience, reliability (completing in first attempt) and effort (lower effort to build)?

4

WiFi

If you're using Wi-Fi you'll connect to some sort of access point set up by your device with your phone, pass on the necessary information and reconnect your device (and your phone) back to the Wi-Fi you actually want to connect them to.

There's not really a way around that if you're using Wi-Fi. Entering the information of your home Wi-Fi is app UX and a bit off-topic for this question.1 So let's focus on how to first establish the access point of your device and second connect to it in the most comfortable and secure way possible?

Establishing the access point

  • Access point is available only after factory reset. (Does your device have a factory reset?)
  • There's a physical button that enters access point mode.
  • You have some wireless way to trigger access point mode. (Not advisable from a security standpoint.)

Initial access point credentials

  • There are none. (You can imagine the security reviews.)
  • They are printed in the manual on the device and are the same for each of your devices. (Ok if the time the access point is active is short enough.)
  • They are printed in the manual on the device and are different for each of your devices. (Better but does require some production effort.)
  • They are printed in QR-code fashion (or other smart device camera readable way) on your device or in the manual. (Same as the above just more comfortable.)

I'm mentioning the manuals because not every device might have enough space to have a QR code even if yours has. Also designers really hate QR codes. On the other hand manuals tend to get thrown out.

BLE

Honestly I don't like the BLE pairing process as it can be quite easily listened to in the way it's generally used. (Cf. This question on Security.SE, this blog about BLE security or this whitepaper or more information about BLE security here or here). The protocol offers some more secure modes but those only work with at least BLE 4.2 which reduces the compatible smart devices and all the additional development effort to implement secure pairing. Maybe even look at BLE 5 but you might run out of compatible devices if you use the new security features. My understanding of your device is that it does not use BLE in normal operations which means a lot of development effort you could use for other stuff invested in BLE security.

It is usually more comfortable to use BLE than connecting to Wi-Fi access points though. To be honest though in my projects Bluetooth is almost always already excluded for these and other reasons. From both cost and security perspective there's not much use in having an interface that your actual use case doesn't need. Another big drawback is to explain to the user why you need to set up Wi-Fi after you just set up BLE. That's UX hell.

Sound & Light

Basically you can use everything where your device has a sensor for to transmit credentials. You could morse your Wi-Fi password via the smartphone LED if your device has a camera or use a sound encoding (optimally not in non-human-hearing ranges) to transmit it if you've got a microphone. Don't include these components for the set-up process alone. People find it really creepy to find microphones or cameras in stuff that's not supposed to have those capabilities.

Some general advice:

  • Think about when your device accepts Wi-Fi credentials
  • Keep that time short
  • Have a recognizable trigger for the user for this time span
  • The less the user has to bother with the transfer of the credentials the better.

1 Apps are tricky since it's a bit hard to read out the Wi-Fi password of the current Wi-Fi which is probably the set of credentials you want to transmit to the device. It's what makes the UX often very painful and it's more painful on iOS because you can't even get the list of Wi-Fis easily. Android let's you get more information that you can pass on afterwards. But that's another UX which everyone out there is battling with.

  • 3
    I thought BLE was designed to make pairing easy and safe - are you saying they only made it easy? Maybe I'm thinking of something future? – Sean Houlihane Nov 12 '17 at 21:04
  • 3
    @SeanHoulihane well BLE 4.2 was marketed as having solved the biggest holes in the protocol, that's true :) – Helmar Nov 13 '17 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.