Provide option to skip or turn off automagic WiFi setup

[jnm2]

Our company is never going to want a Photon to operate on the same WiFi network as the machine that is setting it up.

The downsides to simply waiting for the automagic WiFi setup are:

1. Long wait time
2. When it fails, it goes into 'multiple nearby photons' select mode even though we want to set up over USB, not WiFi. As it stands, it seems to be impossible to do a manual WiFi setup over USB like we did with the Core. I'm not able to set up a Photon either on the public cloud or our local cloud.

[kennethlimcp]

@jnm2 ,

• Place the Photon in listening mode
• particle serial wifi

To switch between ☁️ , instructions are clear here: https://github.com/spark/particle-cli#particle-keys-server-ip_address

[KarbonDallas]

hey, @jnm2!

I'd love more details on your use case! I'm happy to make a fix for you to make it into an easier workflow.

[jnm2]

@kennethlimcp Thank you, that was helpful. I was following the instructions at https://github.com/spark/spark-server.

@emilyrose We are hosting a private cloud because the network where they will be deployed does not have internet access. The workflow consists of setting up the local keys, setting up the WiFi, then registering the device on the local server for over the air updates. Previously setup did the last two items.

A really cool setup function would:

1. Flash the deep update, if it's a Core.
2. Ask if you are using a local server and if so, instruct you to put it in DFU mode and automatically handle the keys.
3. Ask if you want to automagically set up WiFi and if not, do what particle serial wifi does.
4. Add the device to the local server. (This could also be optional.) It should be smart enough not to trip up over this issue.

As it is, I'm putting together a document detailing each step of the process. We had it down for the Core, but the changes threw me for a loop until @kennethlimcp made me aware of the reference.

[jnm2]

@kennethlimcp I think there must be more to it than just keys server. I have flashing cyan and the local server console does not show anything. In the past I used keys doctor, but this fails. I started an issue because it involves some of the DFU operations failing.

[kennethlimcp]

If there is nothing showing up on the server console.log then the device did not even connect to the local ☁️ .

You might want to check that the IP is correct etc.

Once particle keys server public_key.der 192.xxx.xxx.xxx is executed, it is sufficient to switch to the ☁️ and see some stuff.

[KarbonDallas]

@jnm2 this input is very helpful. Thank you for taking the time to explain it so well!

I've also been wanting to refactor the way keys work as well, so this is helpful to consider.

[jnm2]

@kennethlimcp I flashed 0.4.3. Now when it connects to the WiFi, it flashes brief red a few times. When the Photon flashes red, the server says Handshake failed: plaintext was the wrong size: 214. This makes me think the Photon is not using the correct public key. The keys server command is certainly using the default_key.pub.pem that the server generated on first run, and since the server is now showing the message it's certainly connecting. Do you think the problem is that the DFU commands are failing, specifically keys doctor?

[kennethlimcp]

@jnm2 see: particle-iot/spark-server#45

[jnm2]

Okay, got it online with the local cloud breathing cyan.
Since that thread says OTA update is unavailable, I flashed our application binary using flash --usb and got the same DFU error I mentioned earlier. Now the core is breaking cyan but with the red led breathing with it. Tried putting tinker back on, got the same DFU error. Still breathes cyan with the red led breathing. Hopefully I haven't broken it?

Since OTA is unavailable and DFU isn't working, I can't flash any binary. Looks like we can't start using the Photon until one or the other of those issues is resolved. (OTA is very much preferable!)

[brycekahle]

This feels like a duplicate of #61