Any updates on implementing this on Android? I can create the customer on my server and I get the access token back, but then I can’t skip the Particle Login screen.
I would also be interested in an update on when this initialisation method is going to appear in the Android SDK, as I am currently working on a project that requires a local implementation of spark-server, and therefore, I do not need (or want) end-users creating accounts.
Any updates on this process of customers connecting a photon to wifi without needing a user login. I plan to give customers only the device ID and Access Token. So that I can maintain control of the photon.
@rocksetta Did you ever get a reply on this? This thread is still unresolved?
One way of implementing a single WiFi setup (photon can store 5 WAPs) is to use the SoftAP example code given in the documentation.
You need to implement a way of starting the setup process on your product - i.e. a wifi setup button and probably a LED to show that the device is in wifi setup mode and when it has successfully connected to the WiFi and Cloud.
With this approach you do not need to expose the device ID or Access Token to end customers and there is no need for iOS nor Android mobile App development.
Hi @armor. I have not had a great answer yet to this situation. What is the process for making a request that the Particle APP includes a non-login Wifi setup?
@rocksetta You can refer to the documentation https://docs.particle.io/reference/firmware/photon/#softap-http-pages - the approach depends upon whether you have a screen on your device or just LEDs.
When wifi setup is requested I set a runState = GOTOWIFISETUP. [runState is declared as global int.]
From the loop() this calls a function to handle wifi setup that then sets the runState = WIFISETUP and exits, the loop then calls wifiSetupController() which just waits for the credentials to be set. If this happens then wifi has been setup successfully and this will set the runState as SUCCESSWIFISETUP which stops listening. There is a timer for timeout from listening and a controller to handle that (I haven’t included the timer handler here). The softAP web page needs a little bit of editing to suit your application but is adequate. You use a mobile device to find the photon’s WAP (you can change the WAP name) and once connected point a browser to 192.168.0.1 and follow the instructions on the web page.
void goToWiFiSetupController()
{
setupLEDcontroller(SLOWFLASHING); //flash setup LED
if (WiFi.hasCredentials())
{
bool result = WiFi.clearCredentials();
}
timertimeout.start(); //start setup timeout timer
WiFi.listen();
runState = WIFISETUP;
}
// wifi setup state logic function
// entry from: runState = GOTOWIFISETUP
// exits to : runState = TIMEOUTWIFISETUP (if timer ends) or SUCCESSWIFISETUP (if setup successful)
void wifiSetupController()
{
delay(100);
if (WiFi.hasCredentials())
{
runState = SUCCESSWIFISETUP;
}
}
// transition state logic function
// entry from: runState = WIFISETUP
// exits to : runState = GOTOSTANDBY
void successWifiSetupController()
{
timertimeout.stop(); //remember to stop timeout timer if success
WiFi.listen(false);
runState = GOTOSTANDBY;
}
// timeout in wifi setup logic function
// entry from: runState = WIFISETUP
// This exits listening mode after a timeout. Listening mode is stopped
// exits to : runState = GOTOSTANDBY
void timeoutWifiSetupController()
{
WiFi.listen(false);
runState = GOTOSTANDBY;
}@armor thanks for contributing here!
I’m also trying to figure out customer’s WiFi setup flow for our product and I’m hoping you might be able to fill the gaps in my understanding.
I originally started following the softap-setup-page instruction for Serving SoftAP pages externally, but I’m realizing that might not be a great option as it will force a user to download an HTML page to interact with the SoftAP API.
Similar to @rocksetta, I’m trying to create a setup where the customer gets a device, then enters the SoftAP WiFi setup flow via an HTTP page served by the P1, not my webapp server. Now this is great in theory, but the order and code is a bit confusing. Here are my questions:
- The device will need a claim code that corresponds to the customer, won’t it? How does the device get that information by the time the customer is trying to configure their WiFi settings?
- Assuming that isn’t a problem, I’m still unable to serve a page from the device following the SoftAP HTTP Pages documentation. Is there some trick that I’m overlooking?
Any information that you can provide will be useful. Thanks!
1 Like
@gemfarmer Apologies the delay in replying. I will explain what we do and then you can figure out if it suits your setup - I can’t follow what your specific issue with softAP is.
The process we follow is a factory setup where the photon with headers is taken out of the tray they arrive in from Particle. We then load the OS and application software (which contains a Product ID) via USB flash, then Particle Setup is run by any member of the team (who has a Particle account). The photon will then appear in the Product Devices in the console. As part of running Particle Setup they will enter the credentials for the factory wifi. The photons then get built into the products and before shipping (after burn-in period) the factory wifi details are removed. The web app in our case isolates the end user customer from the device ID and access tokens. We have moved now to Product Bearer Tokens one for each Product. Customer views of only their devices is handled by the web app.
I should say that the products have a screen and 4 buttons plus an admin menu which is sufficient for the wifi to show if credentials are stored and clear all credentials if required and lastly to initiate the softAP process and give feedback on it to the user. Once started there is a timeout after 3 minutes, we have found this is sufficient in almost all cases and user abilities. The on-screen instructions are like this, these have been user tested.
We have made some limited changes to the softAP html and javascript to improve the instructions and tailor to our products. There are a few other refinements we could do with making but I have found the javascript is dense and not that easy to understand. Hope that helps.
Thanks for the reply, @armor! It looks like you have opted to go the device-served SoftAP route. Cool.
I think I have a better understanding of how this will work since my previous post, but for clarification purposes, how do you give the device-served page at 192.168.0.1 the product-scoped claim code? Do you pass it from your webapp as a query string parameter?
Any info will be helpful. Thanks!
@gemfarmer, the device’s ‘index.html’ IP address is specified / hard coded in the softAP javascript - it could be anything you want but 192.168.0.1 is a typical address for device served web pages - for example; routers. Why do want to pass this from your web app? At wifi setup the assumption is there is no connection to wifi and the internet.
@armor my goal is to allow a user to claim a device and set up wifi within the same user flow. It will also allow them to complete this process on their laptop or mobile device, which will likely a better interface than our product’s screen and encoder. They would still be interfacing with the device-served page at index.html, but would get there via a click. Am I making sense?