Probably easiest to read up on how the JS works here -> https://github.com/mebrunet/softap-setup-page
In essence, you load the webpage while the device is connected to the web, you then connect to the Photon AP and the page you are already on continues to load the softAP setup directly from the photon.
Once again Iām baffled by the results. Nothing has changed, Photon hasnāt been flashed, all other software and hardware and environment remain unchanged. After several hours of consistent behaviour, I have just managed to get it to work twice.
My next step is to run wire shark and start inspecting packet data to see if I can see any difference in the requests that work and those that fail, but I canāt see how the requests could be any different. Iāve also ordered two new photons.
The only thing that has remained consistent so far is the inconsistency of the Photons 
do you have a shit-ton of other WiFi networks in your area?
The only time I've had problems is when we were doing a demo in Hong Kong... there were literally over 100 WiFi networks in range. Office workers have to use Ethernet for laptops but all those mobile phones looking for WiFi... 
We pulled off the demo but it was a real nail-biter...
One other thing to consider might be other 2.4GHz interferences. Iāve got one crappy Bluetooth keyboard/mouse combo when connected to my device which also should talk to the Photon connection is very flakey. Once I switch that thing off the device connects in no time.
Thereās a few WiFi networks around and Iāve got a ZigBee mesh, but none of the other devices in the house have any issues. I have several photons that operate lighting in the house and work perfectly day in/day out.
The thing thatās baffled me so far is that the errors/issues havenāt been entirely random, although plentiful. e.g. Iāve had it so it works in chrome but not in FF on the same machine. The thing where it works when accessed directly but not via xmlhttp was consistent until just now.
I will however try all this again in a remote location with no other 2.4GHz interference just out of interest.
Iāve got some interesting results from Wireshark but unfortunately, my knowledge only extends to HTTP protocol Iām not as familiar with the underlying TCP layers. Can anyone else shed any light on thisā¦
#Working
#Not Working
I suggest you try 0.7.0-rc.6, as there have been a number of bugfixes/enhancements introduced to SoftAP/HTTP server implementation in 0.7.x versions: https://github.com/particle-iot/firmware/pull/1362
Your wireshark logs look quiet similar to what I was seeing when the web browser was bombarding Photon with several concurrent HTTP requests and it couldnāt handle that properly.
After speaking to another dev we came up with a possible cause, but not checked the docs to see if thereās anything about it. A possible security measure could be causing this behaviour.
How about if once a request has been made to /public-key all subsequent requests to the API (but no the user firmware generated pages) must have the same IP, MAC and User/Agent.
That would mean that once one device has started the connection/claiming process, no other device could take over/confuse the process.
It would also explain perfectly why it fails to work on different devices, but in isolation works perfectly on a given device. It would also explain the scenario where it works if you manually open /public-key but not via xmlhttp request in the same browser. I think the user/agent string would be different (from memory).
Iām going to put this to the test, but itās gone midnight here, so it will have to wait until tomorrow.
Todayās updateā¦ not even sure if thatās the case or not as I now canāt connect to either photon full stop. AP works, ping works, but no HTTP.
Just to go back to basics, Iāve taken my laptop and a photon to my parentās house with one existing WiFi AP and no neighbours, made no difference.
Updating the firmware to the latest RC next.
Hey there @Nemiah ā Iād like to make sure you get support from our internal firmware team if you believe there may be a bug that exists within Particleās system firmware.
Can you provide us with the most up-to-date instructions for replicating the issue and I will make sure we get a GitHub issue created in order to track the investigation and resolution of the problem?
Thanks @will TBH at this point I couldnāt even tell you how to consistently recreate the error as it keeps changing.
Iāve ordered 2 new Photons from a UK reseller, I will flash them with the latest firmware and the soft-ap demo. Take them to a location with few 2.4GHz networks and run some tests.
The only thing I can say for certain so far is that the 2 photons I have will not respond to HTTP requests intermittently around 50% of the time. There is no logic to when this happens so far. Tested with Chrome & FF on Win10 laptop and Chrome on Android 8 on a Pixel 2.
After more tests on the new Photons, Iāll post my results.
@Nemiah, if you are running with SYSTEM_THREAD(ENABLED), do you consider the fact that the user thread will run while in listening mode (ie SoftAP is running)? As in WiFi/Cloud is not available to the user thread.
Iām just using the example code from the git repo, SYSTEM_THREAD has not been set, so it will be in its default state (donāt know what that is from memory). loop() is just blinking an LED anyway in this example.
So the new photons have arrived today. As a control, I have taken it out of the packet, powered up using an OEM Sony USB charger and attempted to configure using the Particle Android app. It connects to the Photonās AP, but cantā configure the device.
I manually tried to get http://192.168.0.1/public-key and this also timed out.
Iāve tried several times, after resetting and itās still the same. Thinking back to pairing other Photons and Cores in the past Iāve always found the process to be somewhat unreliable but I always put this down to the firmware etc not being 100% stable and things like when there were different apps for core/photon etc. I just assumed there were bugs.
Iām going to try the same test in a different location as the answer is either the environment is causing the issue or the device is buggy/faulty.
But either way, it still brings me back to the original issue, which is I wouldnāt expect a consumer to have to go to all this trouble. Letās just say it is the environment, my question(and the consumerās) would be why do all my other WiFi/ZigBee/Bluetooth devices work fine?
Iāll report back when I have more information.
Iāve just done a quick video on the off chance Iām missing something really obvious here. I know the video only shows one attempt, with one device but I didnāt want to bore everyone to death!
So far I have tried both Photons, with a Pixel 2 and a Windows Laptop and tried various different methods of configuring WiFi (without connecting via serial). None have worked. Iāve tied powering via a good quality USB power supply and via USB port.
PS: I do have an ESD protected workbench but I had to film this at my PCās desk
This video is quite good to rule out other things but unfortunately this leaves us (at least me) at the stage where we start stabbing in the dark 
Could it be that your phone is running some app in the background that prevents switching WiFi networks?
I know what you mean, but I just wanted to make sure that Iām not missing something really basic. All previous tests and info above still apply. Assuming there arenāt multiple bugs you can rule out the app not working because I get the same results if I manually connect a laptop or phone to the Photonās AP and then try and request the public key.
We can rule out the Photon being at fault as I now have 4 that behave in the same way, 2 being brand new.
We can rule out the environment as I get the same results in places that have much less 2.4GHz traffic.
My plan is to put together a spreadsheet of tests and see if any patterns emerge when changing Photon/Firmware/Device used to configure/Location/Power supply.
Iām also thinking of taking them down to my local hackspace and letting different people have a go at setting them up with the default tinker app and flashing an LED, just to see if they fare any better. (Iāll do this one at a time of course!)
Hereās the testing that Iāll be doing, Iāll update as I go. If anyone can think of anything else to add, let me know!
I hadnāt seen this before. Funnily enough, itās exactly how I was going to write my own setup script once I got it working.
Itās still based on the same principle as the other setup methods though, it just polls http://192.168.0.1/device-id via JS xmlhttp but I will add it for the sake of completeness.
@Nemiah, let us know how your tests go with the web setup. Yes it does poll the same way but the application doing so is different. 
