A customer is trying to connect a P1 to the home network he is running: https://www.cox.com/residential/support/panoramic-wifi-from-cox.html .
He is running into issues where the device communicates with his smartphone (can scan for networks) but has never connected after submitting a password. The device will flash fast light blue, trying to connect but eventually fails every time.
I have spent time trying to change the settings from 802.11g/n to 802.11b/g/n since these are the network requirements that are stated here https://store.particle.io/products/p1. However, this option is not available on this router. Do you think this could be causing the issue?
I’m at a loss. I’ve troubleshooted over 100 of these devices in the field and this is the first time submitting a password has never worked like this.
Is there anything I can do to get more information that may help shed light on this issue?
Here is an image of the router settings in case this helps:
Once the device has managed to get past the green state it is connected to the local WiFi.
Cyan blinking indicates that the device is trying to connect to the Particle cloud.
When it fails duing that handshaking phase it’s most likely a firewall or keys issue.
Are there any other colour flashes happening during the rapid cyan blinking?
Thanks for the reply @ScruffR ,
I’m sorry, I should have stated earlier that we have mapped the default LED patterns to the following:
In our case blinking cyan could be the result of one of the two following states:
Is there documentation that exists for common reasons to get stuck in these states. Alternatively, do you have any experience troubleshooting these states?
First off, I'd have a
SerialLogHandler logAll(LOG_LEVEL_ALL) instantiated and then have a look at the device OS logs.
If this doesn't already provide enough info about the possible reason I'd use this
BTW, mapping multiple states to the same colour code is probably not the best choice
Thanks for the reply. As this is a unit that is already in the field, CLI commands are out of the question.
However, would it be possible to expose the log data and have it available via json @ 192.168.0.1/device/network-debug for example? I was hoping to create a debug ifdef which would activate or deactivate the log.
If this is possible, then it won’t be too hard to build a network debugging mode that can be accessed by a customer in the field.