Using Soft AP example - can't connect to HTTP


Probably easiest to read up on how the JS works here ->

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 :frowning:


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… :open_mouth:

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…


#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:

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.

Who out there has successfuly launched a product on Particle?

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 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 :blush:

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!


@Nemiah, have you tested with the web setup?


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 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. :wink: