Hello Community,
We have a product based on the P0 with a few thousand users. The setup process is a pain point for a lot of customers, and I’d like to ask people here if they have thought of tips for streamlining things to make it as easy as possible for the end user.
Note, we use softAP and React Native. I’m happy to write a detailed description of what we do now if that will help, but first I’ll open up the topic to see if anyone has anything to add.
Regards,
Aaron
We are using Photons in our products which are all used indoors. We use softAP in a similar manner but rely on use of a mobile device browser rather than a mobile app. We also have a screen and buttons on all products so a user can see instructions and gets feedback on the device about the progress of setup (there is a timeout) and also whether the setup is successful or not. We have also found that the setup process using softAP is very sensitive to having enough available memory and so this is checked before the WiFi setup is started. If there is insufficient memory the user is asked to restart the device which always will recover the memory.
This works fine for most users but recently we have large universities and some schools who have WPA Enterprise and the extra data entry and memory requirements have meant that we have had to look at other methods to enter data - either on a memory card or via a spinner control on screen (which is tedious). Typically though the product will only have the WiFi details entered once and items do not get moved around.
I think you main problem is with having a headless device with only a single led and a few buttons as a user interface. Another idea might be to try BLE with a GEN3 device (Argon) and do the setup via bluetooth or even BLE from your sensor in the hive to a gateway device. I have been asking for the BLE setup APP template from Particle 
Will,
Thank you for the detailed reply. Your insight about memory management is appreciated. In fact, we removed the website and kept the softAP setup flow in-app for that reason. We’re meeting with the Particle team next week, and if we learn something that would be of value to the community, we will share it.
Regards
Aaron
The add-on I would suggest for Gen3 is NFC type4 comms which would allow WiFi setup via NFC from a Smart Phone - that is a must have for us to move to Gen3/Argon. Certainly interested to hear back from your discussions with Particle.
Just a though outside the box: Have you considered a two stage setup?
First you get the device to connect to a "standard" WPA AP which allows it then to communicate with the Particle cloud and/or a dedicated setup page on your own server.
Once that connection can be established you can provide any data you need for the WPA Enterprise via this route.
I haven’t thought of that approach - however, organisations who use WPA Enterprise generally don’t like connecting ‘devices’ to their guest (WPA2) WiFi or they have a captive portal which doesn’t work.
It doesn’t need to be any of their networks.
It could be a temporary “onboarding” WiFi even of a mobile phone.
This way you could even ditch SoftAP and preset onboarding credentials with the instructions to temporarily create an on-boarding network with any device.
You would need to explain a bit more about how to ditch ‘SoftAP’ - I really need to save the 20K that it takes up in flash.
Providing SoftAP is only used to provide the WiFi creds, which wouldn’t be needed for WPA Enterprise anyway there should be no need for SoftAP.
If it’s also used for other settings your on-boarding “server” would need to provide that functionality too, of course.
Would you be saving those 20k if you would use a mobile app? Curious...
You’d definetly safe a lot of flash memory as you wouldn’t need to host the HTML/JS for SoftAP and you’d be in control of how you implement the communication for on-boarding.
So you’d definetly gain back some - if not most - of the ~20K.
Perhaps I could test the steps and dependencies to see if I understanding this?
Dependencies:
Process
Basically, just for Process 3. I’d use the Particle cloud for secure transfer not unencrypted HTTP and for Dependencies 2. it wouldn’t need to be a fully fledged mobile app but could be a mere web page and the user should be capable of creating a hotspot with the given credentials without a dedicated app provided by you.
For usability reasons it is likely that a mobile app of some type would be needed. I am a little unclear about exactly how what you are proposing would work - is the mobile device merely a convenient (and temporary) access point? If it is then how does the user of the mobile app entry the credentials to travel via the Particle Cloud without being logged in as a user?
Exactly! Only needed during the onboarding.
That depends on how your product is meant to be used and who will be the owner of that device. Hard to tell without knowing these details (and slightly wiggling some of these "constraints" might open other options and make things easier or harder).
One possible route might be this:
If it is tied to a shadow user you could use a QR code (or other means) to access the device via that shadow user and device ID.
since a mobile app requires going through the app stores and that increases cost and pain, could it be that one can use a javascript app wrapped in a desktop app like ElectronJS does it?
Are your customers close to a computer when they configure the wifi of your devices?
Thanks
There is already an app on Apple Store and Google Play so it is just a question of getting a new feature added into the release plans. This is a fairly recent development hence historically why SoftAP was used. Currently we use the SoftAP and the WiFi setup code almost vanilla for someone to use their SmartPhone to connect to the device AP and then point the browser to the device setup page IP.
Are you talking here about the Particle apps or your own apps? thanks
Own apps