There have been forum discussions lately about running a webserver on the Photon and providing WiFi configuration directly on a webpage running on the Photon. Devices like the D-Link DIR-505 provide this functionality right out-of-the-box so it should be possible one day.
I thought I would mock-up some webpages of how I imagined it could look. In a lot of ways its like a router configuration page.
Login page with username and password :
Default installed Tinker app. Currently installed app shows as the leftmost tab.
Page to show the current Particle variables and functions. Could provide very fast refresh if you need to see live data.
Wi-Fi configuration
Ability to add and remove connections and also change the connection attempt order.
Firmware and updates page
Custom Page on the device
Really up for something along these lines - would make implementing Photon in products for end customer set-up much more do-able. When can we have it?
Well I think there are some technological hurdles which need to be resolved by Spark 
Particle first.
Some of the functions needed are not available yet, such as reading and managing the list of SSID’s currently stored in the Photon.
Also, I think a function to retrieve the wireless networks currently available to the Photon would be helpful.
(ScruffR: Edited Spark to Particle 
)
I have seen quite a number of forum posts along the lines of my Photon is flashing xyz color and I dont know what it means. I think that having webpages available directly on the Photon out-of-the-box would allow for much more detailed information about what is going on, such as “No Keys Found” etc.
This is a really interesting idea. Seems like a combination of dashboard and dev with a wifi config thrown in.
We actually do have some pages that give detailed info about “what is my photon doing, it’s colors are so weird!” in the new docs. I still need to add video and visibility to some of these.
I just wanted to throw out the idea of using a web application that is hosted elsewhere (eliminating the need for special firmware on the Photon itself).
Once SoftAP HTTP support is available (coming soon™), you should be able to manage your Photon from any web application that can access the Particle API with your access tokens.
Unless I’m missing something, it seems like this could be a more reliable/flexible approach.
The problems I was hoping to solve with this I think would be difficult to achieve with an externally hosted website.
Managing Wi-Fi connections. For example giving the Photon to your friend and saying the Photons website password is this. They take the photon home and with no additional info can access it and connect it to their own network. You cant do this with an externally hosted website since it would not be accessible at the persons house. You could achieve this by unclaiming, claiming, reclaiming but I think this solution is simpler.
What do these breathing / blinking leds mean ? The Photon hosted website could be accessed before there is even a Wi-Fi connection established to the internet and provide an explicit error message. You could also access detailed information like the firmware loaded / mac addresses which is useful. This also helps the 8% of men who are color blind.
Custom Apps / Particle variables. This would enable very fast viewing of data (every couple of seconds). This could allow realtime data viewing without needing to build a screen into your hardware. I have found that with network latency it is pretty difficult to get realtime data on an external website, also once you have a bunch of devices the load on the external website can get high just due to the volume of requests.
Ah, yeah I see what you mean.
An embedded app would definitely be sweet for that kind of use case!
HI there @Rockvole! This is an interesting idea, but I must admit I’m not sold on this. Sorry!
managing WiFi connections - that’s the most pertinent use case here, but doesn’t require a web app UI implemented in the Photon - simply exposing the softAP setup controls via HTTP will make it possible to launch a local http server (such as part of particle setup wifi) to provide a setup UI. Keeping the UI out of the firmware will make iteration and development much faster, and updates simpler, and the UI would undoubtedly be more refined, being able to use more resources than the 100Kbytes available in the Photon plus leverage existing webapp frameworks in Node.
I feel information on the LEDs is best maintained in the documentation where we can more easily update resources and provide better resources than there is room for in the Photon, such as high quality images and videos.
Custom apps/particle variables. You can already do this by rolling your own web server using the Webserver library, but of course not having to roll our own and instead use a tested solution would be better. So, to make this simpler for application devs, I would instead put the functionality in a new library that provides a ready-built solution for exposing variables via HTTP.
The system firmware has about 100K of free space, which we plan to use for features such as multithreading, AP/WiFI Direct, TLS sockets, UDP cloud protocol. Adding a webapp in there could easily use up all of that space and even then the UI might not be as refined as we’d like it to be.
I wish I could be more upbeat about this. On the face of it is seems like a great idea, but digging deeper, I feel there are better ways of solving the problem of Photon AP setup than embedding a webapp in the photon, at least for the cases outlined here.
Cheers 
,
mat.
Hi @mdma,
Having a local Http server wouldnt help in my situation - none of my friends which I pass the device to are running a local Http server. Also connecting to the local server would require getting the WiFi password into the Photon somehow.
I wasnt suggesting any documentation on the Photon regarding flashing LEDs, but the precise message which the flashing LEDs refer to such as “lost connection to the Particle cloud”.
Yes you can roll your own server, but if Particle provided a template then it would be simpler to plug your custom page into that template and provide the wifi connection tab etc to anyone you give your Photon to.
I didnt imagine this would be custom firmware, but it would be installed much like tinker is now. Then the user can choose to flash their own firmware as before or link in the Particle template if they want those features.
The Photon webpages template would reduce the problems I had lending the core to my friends.
Friend 1 problem :
Met him in a restaurant to pass the core to him. He had a blackberry so couldnt run the app.
Solved by : Buying a Dlink DIR-505 and pre-connecting the core to that router to let him have that also.
Friend 2 problem :
I took the core to his house and tried connecting my phone to his WiFi network. It didnt work because his WiFi password was 7 digits long which was not permitted by my Samsung phone. (8 chars minimum). He didnt want to change his WiFi password on all his devices since the router was owned and installed by the local telco.
Solved by : Providing him with another Dlink DIR-505
This also allowed him to pass the device to his neighbour.
Friend 3 problem :
Meet him in a restaurant. I dont want to buy a third Dlink DIR-505.
Plan to solve by :
I am getting a laptop for my birthday so I plan to put the Spark toolchain on that and then I can program it in the restaurant with him typing his Wifi details into Particle cli.
Friend 4 problem :
He lives overseas and is very non-technical.
So I will see if he will give me his wifi connection details. If that doesnt work out I will have to unclaim the core so he can type in his connection details. If I need to update the firmware I guess the trouble will start then since he definitely wont be able to install the Spark toolchain etc.
I believe that Particle have solutions for larger deployments, I think that may be a lot of work for just a handful of devices for testing.
Some of these issues could be overcome relatively easily I think:
Friend 1&2: what was he planning on doing with the device? Was it a finished product, or were you lending it to him to try it out and program with it? If his intentions were to reprogram it, I think it’s reasoable to assume he can get a serial connection up and running (use putty). No CLI or app needed for the wifi credentials.
Friend 3: I like to think of the tool chain as everything that’s needed to build locally. The CLI isn’t nessecarily part of that. Neither are needed to configure wifi credentials, like I mentioned above. Any serial terminal will do just fine.
Friend 4: I’m not sure why you’d have to unclaim it so he can insert his credentials, if you could just put it in listening mode as well.
Also, I’m not sure what your non-technical friend would want the toolchain for? He could just use the web IDE?
I know there are some solutions in the works to make it easier to setup and manage devices, that will be part of the dashboard. Hopefully they’ll make your life a bit easier in that regard. But personally I don’t see the advantage of running a webpage from the photon, it’s way too resource intensive, and really doesn’t pay off. With the upcoming http softAP, you should be able to simply open a webpage and manage the credentials. This way, all efforts are being made outside the photon, leaving more room for more useful features.
I am just lending them sensor devices so they can view the results of the sensors.
None of my friends want to get into programming this, even if some of them are
capable they just want to try the sensors out.
Friend 4 : Are you saying that anyone can install the Spark App and they will be able to
put the device in listening mode and change the wifi credentials ? I assumed
the device would not allow anyone except the person who owns the cores to
change the credentials ?
Fair enough 
Yes, that's possible. I wasn't entirely sure myself, but I just tried it with a different account on both the Core and the photon, and it seems to work just fine
It works for the Core too, although it doesn't have those fancy messages.
How exactly would you imagine that to be possible? You can reset the credentials using your finger, there's no way to really verify that's the true owner. Also, you add the credentials when it hasn't yet got an internet connection. It's bit hard to verify with a server that you're the owner if the exact purpose of the change is to reach that very server...?
Oh I see, my knowledge is out of date. This is the way I thought it still worked with security measures to jump through :
But once the new owner claims it I would no longer be able to update it over-the-air for them, or change any of the Particle functions / variables for them ?
I thought the Photon was around 10x faster than the core so running web-pages on it would be possible. My current code doesn't do much, just loop around reading sensors and sending them every 10 mins so I think I would have plenty of remaining space for webpages. It also would have been nice to run webpages so that I don't have to integrate a screen for faster sensor readings every couple of seconds.
Yes, but they can only claim them if you have unclaimed them. For updating the credentials there's no need to claim anything. You're only giving it new information so it can get online, nothing more. That's what the seconds screenshot says. "We managed to give it credentials, but since it isn't yours, we can't connect with it to check if that was successful."
Long story short: you stay the owner, they just feed it new credentials. Nobody gets hurt 
It's not that it isn't possible, but that it would eat so much resources, while providing so little additional benefit. It's great that you can log in from a webpage on the device, but is that really necessary (considering the app will work, as will a serial connection, as will the CLI, as will Particle Dev, as will HTTP softAP in the future)?
Like MDMA suggested in point 3, you can do that. But, rather than cooking it into the firmware, use a library which will allow you to do that. That way, the Photon stays 'clean', but you can still have your desired webpage.
"every couple of seconds" isn't really 'fast'. A roundtrip to the server and back takes less than 500ms on average. That would allow you to updates things twice a second, which is already faster than "every couple of seconds"
Not having to integrate a screen is a bit questionable, since you'll still need a screen to see that page. Rather than the page being hosted on a micro controller, which main purpose is to control things (as the name suggests), I'd rather host that page on a webserver, made for that very purpose. A simple raspberry pi would suffice for that, or a NAS server, and would all provide so much more functionality than the Photon could ever hope to offer.
I personally have a raspberry which I intend to use to collect, store, analyse, and visualise data with, from my particle devices. That's something I can't, and rather not, do on the Particles themselves.
Hi Rockvole, I can't agree more about this being an essential feature for and unsophisticated end-user. Maybe I'm missing something, but any company that would require a user to run a local http server to set up credentials rather than through a photon based website is at a severe disadvantage (Imagine if Nest was to do this). Although it is resource intensive on the photon, is it safe to say it will be possible to provide wifi credentialling website like the Dlink DIR-505?
I have to disagree here. It does provide that much benefit, if I am understanding everything correctly. If an end-user of a commercial product can not set up the wifi in 10 minutes with simple instructions (i.e. a webpage that doesn't require an app download or 10 additional menus), their first experience with the product will be awful. From a business standpoint, this is likely a necessity and would be worth the extra resources.
Here is a link to someone experiencing a similar issue