Have browserfied the softap-setup-js and from a device (Photon running 0.4.6) in listening mode have successfully achieved the following:
-can read the device info.
-can ask the device to scan the local AP’s and report them.
-can retrieve the device’s public key
But I can not successfully complete configure() after the user selects a local AP.
I see in the provided example (basic-setup.js), the order of operations is:
-setClaimCode() Do I need to do this? What is the claim code?
-publicKey() I understand this is needed to encrypt the password?
-scan() To select the AP
-configure() to set the credentials in the device
-connect() to actually use the credentials
When I drop the basic-setup example into an .html page it does not get past setClaimCode().
My simple web page does:
-scan()
-waits for the user to select an AP
-publicKey()
-waits for the user to enter a password
-configure()
…but configure never calls its completion handler, which contains connect(). No errors are generated. The browser console log does capture my last log statement which is embedded in softap-browserfied.js in the configure() function just before it executes:
This is a pretty well-documented issue at this point, and a lot of people have butted their heads against it.
Barring any obvious javascript errors (unlikely given that you’re using the examples), it’s almost guaranteed you’re seeing this problem.
Turns out the configure-ap HTTP request is sometimes sent by the browser as two packets, but the Photon’s internal web server can only handle single-packet transmissions.
The end result is everything up to the configure-ap step works, and then it fails silently.
This is most common, it seems, on iOS devices followed by Safari on Mac.
This is a firmware bug, not a JS bug. AFAIK there is no real satisfactory fix but I think what we’ll probably see sometime in the near future is (hopefully) an implementation of the configure-ap step which uses a different HTTP verb to avoid packet fragmentation as a stop-gap solution (until WICED gets their shit sorted).
I am always trying to get softap-setup-js browserfied working, but I don’t get… I seams that you had success and so I would like if it is possible to get your help for this? If I try it, I will get the following error:
TypeError: undefined is not an object (evaluating 'opts.keepAlive')
I encountered problems on iOS after updating to iOS 10.x.x and logged the problem on github:
There is no solution as of this moment for soft-setup-js browserfied. The thing with that library is browserfy turns it into about 40,000 lines of code. I took the example of embedded softap setup (putting the web pages into the Particle device)
and rewrote it using jQuery (which most people are using anyway). So you can do the whole thing in about 250 lines of javascript (not counting the RSA library)
It’s alive! Sort of. I can read things from the device (comparing with my browser to figure out what I’m seeing. For example: 192.168.0.1/version returns a JSON object {“v”:2}. Which is all good. So I know to use json.v. And so on.
But I’m not sure what to write back in. There are a few functions which support writing stuff.
set, which is used to POST stuff to 192.168.0.1/set. I have no idea what that is actually for?!
configure, which allows you to send in an object (opts), which has a large number of members, but I don’t know what they are or what they should be set to.
connect , which is more straight forward. It tells the device which of the discovered networks to use.
setClaimCode calls set and sticks in the claim code (maybe that’s what set does?)
You see if you can contact a hotspot connected particle. If so you ask it to scan for what networks it can see.
Then present the user the options, they choose a network
Based on their choice you update the UI. These days I simply tell the user that the security is automatically chosen though give them the option to override
They type in a password
They click go
You ask the particle to connect with the user’s password. It needs to connect, exchange keys, provide particle the password to hash with the keys and then finally actually connect to the wifi AP. Those functions are effectively chained together as callbacks.
Checkout the parent particle repository that i forked to see the original help docu.