Photon softAP usage?

@nexxy, @mdma, can you please summarize what is the final functionality we can expect ? Specifically:

  • will there be a web page in the Photon firmware, allowing for easy WiFi setup using just a browser (like in @mebrunet’s firmware) ?

  • will there be a possibility to have both WiFi client and AP on the Photon ?

  • will the web browser app (served from external server) based on softap-setup-js work with Photon Soft-Ap (the CORS problem mentioned in the thread) ?

  • how about the https://github.com/spark/firmware/issues/396 ?

Thanks

1 Like

@kefir135,

Hey! Surely. Here is what I know about our current plans for SoftAP Setup — which may be subject to change, especially given feedback (such as your own)!

  • Not that I am aware of although I am interested in what @mebrunet is doing as well!
  • The Photon is obviously able to operate in both client and AP mode, but as for it doing so simultaneously I don’t believe so. @mdma may have more to say on this.
  • Yes! After we find the right solution for CORS configuration, it will work.
  • I think this is still something we plan on doing but I don’t know an exact timeline.

Sorry I don’t have all of the answers, but I hope this helps! I’m happy to answer any other questions you have, and I’m sure @mdma will pop in when he comes up for air.

@mdma

I’ve got a simple HTTP setup page working. The final step is to serve it from the Photon. My original plan was to minify it to a single line string and serve it with WICED_STATIC_URL_CONTENT. (The same way you served the response to /hello) It’s a bit of a hack I know, but I just need something working ASAP.

However, when I take that approach the request seems to hang unfinished if that string get’s too long. (i.e. I can serve simple html/javascript page, but by the time I’ve emebbed all the RSA encryption stuff it’s just too long). I could keep hacking and spread the page over several WICED_STATIC_URL_CONTENT endpoints… but that starts to get really ugly. I would much prefer to use WICED_RESOURCE_URL_CONTENT to serve static pages, as Broadcom does in their WICED SDK example apps. But my C++ is rusty and their documentation about how to do that is almost non-existent. So I was wondering if I could get some of your help.

I’ll be sure to get the solution online and documented when finished.

Sounds cool! Can you try the latest develop code - it contains a fix that increases the stack size of the HTTP service which can stop it crashing.

I’m happy to help - please submit a PR and we can work on this together. :+1:

Okay thanks, I’ll give that a shot this afternoon. What’s a PR?

A PR (Pull Request) is a way to submit code via github - we can both work on the same code and have a discussion.

This might help.

1 Like

Haha kk, thought you were referring to something internal to Particle. Thanks.

@mebrunet,

This sounds really cool and I’d love to try it! Thanks for your help! :smile:

Hi Everyone,

I’ve finally managed to prototype a solution for this. It’s still ugly and buggy, but working (for me - Chrome v44). The Photon serves a simple HTML/JS page and walks the user through the connection process. Get code and further instructions here.

Cheers!

3 Likes

Screenshot of the latest version. It’s working pretty well now! I’d hand this out to clients as beta.

@mdma & @nexxy - I noticed that the develop branch of the firmware adds Access-Control-Allow-Origin: * headers. That’s great! But the Photon still doesn’t seem to accept OPTIONS requests, so while I can GET anything cross origin, I still can’t POST. Are you guys working on that? It would be great to host this page off-device!

7 Likes

Looking great!

@mebrunet,

That is absolutely awesome! Great work!

@mdma will be the one to fix OPTIONS requests, so I will defer to him on that!

Thanks!

Another issue I’m facing is compatibility with the develop branch. Right now I can host this by tweaking photon_043. My basic strategy is to add a bunch of new WICED_STATIC_URL_CONTENT endpoints in softap_ip.c , change the size of the page array in softap.cpp accordingly, then compress all my web pages into strings (but nothing too long… haha or the request hangs).

However, I can’t seem to add new WICED_STATIC_URL_CONTENT endpoints in the same way on the develop branch. I’ve diffed those files and can’t see why it won’t work, any hints? @mdma ?

1 Like

Nothing comes to mind. The only change to HTTP for a long time was the addition of the XHR header and increasing the stack size for the HTTP server.

Regarding HTTP OPTIONS, I’m not sure that’s supported by the wiced HTTP server. Can someone provide more details about what’s needed since we might have to code this ourselves.

Okay I’ll try v 0.4.4 and see if I have more luck.

RE. OPTIONS: Come to think of it, I remember going over WICED documentation a few weeks ago… I’m pretty sure it specifically states it can’t handle OPTIONS :frowning: . Rather than coding that from scratch, why don’t you also get accept a GET and we can pass the ssid, pwd…etc. in the query params? Kind of hack, but not terrible, the password is encrypted, and it’s AJAX so the 330 chars required won’t actually show in the url…

Could you make a PR to our repo with your current changes, against develop, and we can discuss firmware development there? Cheers! :smile:

1 Like

Will do. Also, according to this acticle I can avoid the OPTIONS preflight with the right headers…

First off, from someone who also requires this functionality, I appreciate the hard work everyone has put in on this!

Preflight/Options shouldn’t be required if POSTing one of these content types:

  • application/x-www-form-urlencoded
  • multipart/form-data(
  • text/plain

although I’m just now getting started on this piece and I’m not sure what content-type the Photon is expecting. if it’s application/json I don’t believe there is a way around the preflight.

It seems like there are a couple of options(no pun intended):

  • add support for preflight/options
  • make the POST a GET(@mebrunet)
  • change the content-type
  • anything else?

The photon doesn’t really care about the content type, so feel free to set it to text/plain.

@mdma, Thanks for the info.

@mebrunet, I used the example from your GitHub repo and was able to get it working with just a minor change in the content type, “text/plain” vs “text”.I was also able to render the page from a remote server, toggle my wifi to connect to the Photon’s AP, and configure the WIFI on the Photon via HTTP. That being said, I don’t believe there is an issue with CORS.

1 Like