The best way to set up a new product for a customer, not just my preference, but the best solution overall (unless you want them to setup a particle account) is the softAP setup page. This allows the customer to setup Wi-Fi credentials almost exactly like they would connect their phone to a new Wi-Fi. The UI for this is very simple, intuitive, and familiar for anyone to use.
@dheerajdake why would you not want to claim the P1? Having it in your devices gives you complete control, if you find a firmware issue in 6 months, you can make the necessary changes and reflash OTA.
Right. That’s not a bad idea for one of my two projects where I only produce a few boards at a time (for now). For the other project I’ll soon get 200 devices at a time, so I really want to automate anything I can, including the functional testing, claiming and registration with our services. Due to the bug mentioned above, I cannot seem to get around this without adding wifi manually for 200 devices…
I haven’t tried yet, but I’m sure that’s almost a days work of pointless typing?
(I’d really not do that)
Did the JSON file technique I mentioned above not work?
Oh my… Clicking the link here on the site only took me to the last reply. I didn’t catch that there were multiple. Gimme a second here to test
That looks super-awesome! Just what I need!
@Mjones I don’t remember why I wanted that option. It was an year ago when I wanted to do this.
I’m using CLI Version 1.25.0 on OSX Sierra and I get error messages when trying this:
particle serial wifi --port /dev/tty.usbmodem1451 --file defaultwifi.json
Using Wi-Fi config file: defaultwifi.json
Attempting to configure Wi-Fi on --port
! Something went wrong: Error: Error: No such file or directory, cannot open --port
I have a P1 in listening mode on port /dev/tty.usbmodem1451. If I omit the --port part of the command I get the following error:
Using Wi-Fi config file: defaultwifi.json
Attempting to configure Wi-Fi on --file
! Something went wrong: Error: Error: No such file or directory, cannot open --file
Ah! I just omit the --port part and keep the path to the device like this and it works!
particle serial wifi /dev/tty.usbmodem1451 --file defaultwifi.json
Perfect! Now I can script this!
I’ll see if I can find the relevant page in the docs and add this on a pull request, since I can’t find it anywhere in the Docs.
I think when you upgrade to 1.29.0 or later of the CLI it will require the --port option before the port name. But I’m glad you have a suitable workaround now!
Is CLI 1.29 released? I think CLI Version 1.25.0 is the latest available for OSX that I can seem to download using:
npm update -g particle-cli
I’ll post a simplified version of my setup here when I’ve got it working well. Looks like I’ll use a combination of Bash and Expect.
If it comes back as /Users/YOUR_USERNAME/bin/particle you have the CLI installed with the Particle CLI installer for Mac or Linux and you should instead upgrade it using:
The npm update is probably updating the wrong one, which is why the version isn’t changing.
In general, the best thing to do on the Mac now is to uninstall the npm -g one:
sudo npm uninstall -g particle-cli
and then use the Particle CLI installer. If you try to use the -g version on High Sierra it will eventually stop working with unfixable permission errors (unless you installed all of node as your own username not using sudo).
bash <( curl -sL https://particle.io/install-cli )
Here’s the new device Setup script that I’ve come up with. It’s based on Shell and it’s been rock solid. It only takes 30 seconds per device, so I think I’ll head into my office tonight and claim those 60 devices
Here’s what the script currently does:
- Query the computer (OSX or UNIX) for the relevant USB port
- Set the device to listening mode (if required)
- Query the device for the deviceID
- Set the Wifi Credentials using credentials stored in text file
- Claim the device (make sure you’re logged in with the correct user!)
- Set the device DFU mode, so we can upload firmware
- Flash our device test & setup firmware via Serial
I’ll also add some Project specific calls using curl to it also that will simplify the process even further for me, but this should be a good start for others needing something similar.
I’ve always used:
sudo npm install -g --unsafe-perm particle-cli
Without having any issues.
Nice script, but stty works differently on Linux than it does on Mac. I’ll probably be forking this to make some improvements.
Would be great if we could make it work on both platforms!
Originally we tried sudo npm install -g --unsafe-perm particle-cli as it works great under Linux, and it helped on the Mac. However, under High Sierra it didn’t always solve the problem. That’s why we switched to a non-root node.js and particle-cli.
Here is my version of the script:
When it briefly didn’t solve the problem for me I was able to fix it with:
sudo npm uninstall -g --unsafe-perm particle-cli sudo npm install -g --unsafe-perm particle-cli
Great improvements and quite a lot of them too! Much more flexible than my first version
Sorry I didn’t see notifications.
My approach was adding the JSON file option to the Particle serial wifi command and it was eventually accepted by the Particle team. Squeaky wheel works!
It seems your script does pretty much what do. For interests sake I’ll take some quick notes on mine:
- List out the ports, find the particle or spark devices manufacturer
- Get the device ID
- put in DFU
- set the SSID prefix
- update the software via flashing manually with dfu-util the relevant part1 & part2. So so so much faster than using particle update commands
- find the port number again (yes, it changes often after changing base firmware)
- run the serial wifi with the relevant JSON file of wifi creds
- claim the device (my products belong to me in terms of claiming)
- rename the device with a prefix, dateformat, and 3 random short words (makes it so much easier to spot , ie
sdb-180124-wiry-cue-ghost [3b0052001851353530333xxx] (P1) is offline
- flash software .bin file to device using standard particle flash, i don’t do this via DFU and --usb because strangely it was unreliable, can’t remember exactly why
- run diagnostics via calling functions on the new device to check its reading the universe correctly and the PCB is working