Hi there,
I am using a P1, functions from the softap-setup-js https://github.com/spark/softap-setup-js, and pieces of http://mebrunet.github.io/softap-setup-page/src/ that I’ve integrated into my own pairing flow.
I am running into some inconsistent and unpredictable issues when handling INCORRECT WiFi passwords submitted by our users.
In some cases when a user enters an incorrect password, their smart device (phone/computer) gets booted from the P1 (Photon-XXXX network) and the LED will continuously flash green, waiting for the user to put the P1 back into listening mode (blinking blue).
In other cases after entering an incorrect password, their device gets booted from the P1 (Photon-XXXX network) and the LED will continuously flash green, but this time will switch back to listening mode automatically (blinking blue) after about 20-30 seconds. Slightly less desirable but I could work with it if it was predictable.
Lastly, and worst of all, in some cases when entering an incorrect password, the device DOES NOT booted from the P1 (Photon-XXXX network) and the LED will continuously blink blue. This is what I call the blue mode of death, as I can still connect to the hotspot but my softAP functions can no longer be called and I can no longer submit scan/credential functions. In production this scenario is very hard to handle since the user can still see and connect to the photon network, yet the results are different than what is expected. From my softAP, I get ‘net::ERR_CONNECTION_REFUSED’ when trying to ping the device with the following softap-setup-js function from a browser:
var sap = new SoftAPSetup({ protocol: ‘http’ });
sap.deviceInfo(callback);
function callback(err, dat) {
if (err) { throw err; }
console.log(“Device ID: %s, claimed: %s”, dat.id, dat.claimed ? “yes” : “no”);
};
For now power cycling the unit is the only option for the 3rd mode, but I’d like to avoid it all together since I haven’t figured out a way to programmatically identify when this scenario has occurred in an efficient way.
What is the typical behaviour when handling incorrect WiFi passwords for the DEFAULT firmware shipped on the P1? Is the device supposed to flash green continuously after an incorrect password is entered, or should it eventually make it’s way back to listening mode (blinking blue). Lastly, has anyone ever seen similar issues related to my third point when handling incorrect WiFi passwords submitted to the P1?
Thanks,
Bruno