I'm exploring different ways for end users to onboard their devices to their own accounts in a frontend system.
So far, I've seen the following two methods:
Scanning a QR code or serial number during the onboarding process
Using BLE with a mobile app for configuration
I'm looking for additional onboarding methods that would make the experience simple and seamless for users. Goal here is to ensure a smooth onboarding process, whether users are tech-savvy or not.
Do you have any suggestions for alternative methods?
Has anyone implemented different approaches, such as Wi-Fi Direct, an Wi-Fi AP, or anything else that worked well for end users?
Soft AP: in case the product is based on a M-SoM, perhaps it could run a small web server. But since the Photon 2 users almost the same MCU, I suspect the M-SoM will not be able to do this either.
Curious. What do you see as the pain points or frustration that end users have regarding QR codes? What about BLE? What’s the problem you are trying to solve? Is it complexity on you when commissioning new devices before shipping or minimizing friction/frustration of the end user/customer when they have to claim said device.
I personally use QR codes today. I think most customers find it acceptable. I use a web app today that can access the mobile devices camera. They go to the claim devices page, click the scan button, scan the QR and that’s it. If they happen to scan the QR code from the camera it navigates them right to the claim devices page if unclaimed or device settings page if already claimed.
I assign my own 10 digit hexadecimal value, print my own QR stickers on a Brady printer. I scripted my device commissioning to scan Particle device, scan QR code and it adds the device to my backend/database and loads the firmware.
One thing I’m considering is for LoRa nodes, have the hub enter an “auto claim” mode such that any node that it hears from when in that mode it would auto claim those devices. I guess the equivalent could be send out BLE message from the Particle device when it turns on. A phone can listen to that includes all data needed to claim it to the account.
I think some people use NFC as well. I’m a bit naive on NFC but my understanding is it’s just a new version of a QR code.
Soft AP is not possible on the M-SoM (or P2/Photon 2). While the RTL872x hardware theoretically supports AP, it does not currently fit any common uses cases and is unlikely to be implemented. BLE is a significantly better method of configuring the device from short distances wirelessly.
Regarding QRs, it's the complexity on the product side, where each device has to get a QR and it needs to be associated to the Particle deviceId or serial number in a system somewhere.
For BLE, well, I'm just not so sure how solid or frictionless the process looks like today. I remember onboarding Particle devices via BLE some years ago and it wasn't as solid as one would want it to be. Perhaps that was because of all the steps involved in the process, which might be less in an end-user product, since you already assigned the device to your Particle account at manufacturing time. Also, the fact that Particle made the move to a wired onboarding system with https://setup.particle.io/ makes me hesitant of the BLE route. Phones get in the way too and phone issues are hard and expensive to troubleshoot.
I was aware of the first part, but sending the user to the settings page if already claimed is a nice touch. Thanks!
This is why I come out here and ask the community: someone may have a different view and are willing to share few aspects.
Thanks Jeff!
We are utilizing the M404x board, which supports both cellular and WiFi connectivity. Users initially set up their devices by scanning a QR code or entering the coreID found on a sticker inside the device. Upon first setup, the M404x automatically connects via cellular network.
Through their user interface, users have the option to add WiFi credentials and to enable or disable WiFi. When they update the WiFi settings, a Particle function transmits the new credentials to the device and reboots it with the updated settings, and uses wifi.prefer for automatic connection management. Even when WiFi is preferred, the cellular connection remains as a failsafe. This method has been effective for us.
When WiFi is disabled, the WiFi module is powered off to conserve energy.
The reason BLE setup wasn't great for mesh was that it also flashed Device OS and Tinker over BLE, which is large and slow. And mesh setup for Xenon was extraordinarily complicated. The example BLE setup for Gen 3/Gen 4 is significantly simpler if you already plan to have a mobile app, since it basically only sets the Wi-Fi credentials.
The reason setup.particle.io uses USB setup instead of BLE is that in order to develop with Particle, you pretty much need to have a computer. By eliminating the mobile app component, we would no longer need to maintain iOS and Android apps, which are not integral to the development experience. Since setup flashes Device OS and Tinker, doing it over USB is significantly faster and more reliable than BLE.
If you don't plan on having a mobile app and USB is acceptable, you can host a lightweight Wi-Fi configuration tool from your web site. It's described in the Wi-Fi setup options page.
For M-SoM, configuration of Wi-Fi over cellular is a good way to eliminate the need for a mobile app as well.
Hey Jeff, any reasons why you do not use the Particle device ID for this?
I see Graham is using it.
@rickkas7 do you see anything against using the Particle device ID for the QR code?
As as pro, I see that using the Particle device ID directly eliminates the need for an extra mapping layer between your serial number and the Particle device ID. This reduces complexity in both manufacturing and the system's backend.
Utilizing Existing Identifiers:
The System-on-Module (SoM) of the M404 board already contains the coreID and other essential values necessary for device identification and management.
CoreID Display: I design a sticker that prominently displays the device's coreID.
QR Code Inclusion: Alongside the coreID, the sticker includes a QR code that encodes the same coreID. This QR code facilitates easy scanning during the initial device setup.
Sticker Placement: The completed sticker is securely placed inside a custom enclosure of the M404 device. This ensures that the coreID and QR code are readily accessible for users during the setup process.
This is what I also do for users to configure WiFi for any P2 device. So far it works well. I had one customer try and use a non-data USB cable that I had to help them through but that was it. Going forward I just include a proper USB cable with it.
A few reasons:
If a user wants to physically type in the device_id, maybe they don't have a mobile device to scan it in? It's a PITA to type in the full unique GUID/device_ID. Mine is only 10 digits from 0-F.
Having less characters, the QR code is also easier to scan in from a camera. The more characters in a QR code, the more detail it is and the crisper the image or larger the QR code needs to be. Also to be clear... my QR code is NOT just the serial number. Rather it/s MyWebAppURL.com\QR{SerialNumber}. In that \QR{SerialNumber} URL endpoint within my own web app, I peel off that URL parameter to extract the Serial Number. I then look up the device in SQL and then re-direct the user to the proper URL based on if it's claimed or not. If it's not claimed, I just populate the form entry for them.
I have non-particle devices as well LoRa devices. I didn't want to use a different convention and produce different QR codes based on each device type (Particle or non-particle) in the onboarding/claiming process. This way I can just print a bunch of the exact same Serial Number stickers.
I guess I already have the full SQL backend where I needed to add the device in the devices table so adding an additional field for the Serial Number was easy. I also have a custom Web App, so redirecting the user if they scan in QR code was easy. With the right programming, I bet I could auto claim any QR code that the camera sees and streamline that even further.
Here is my walkthrough on claiming a Particle Device to give you a little better perspective.
