Initial device setup for products - 10-20 borons

[jgskarda]

Is there a decent tutorial or guide about the initial setup devices for products. I’m not mass scale but doing more than a few. In the past I’ve always did the steps one at a time which seemed a little clumsy. I’m sure there are ways to streamline it. Wondering what are the possible ways. Here is roughly what I do today:

1. unpackage it from the box and plug into USB port
2. Run Particle USB List to find the Device ID
3. Add this device ID to the list of Products and them activate the SIM. (I think this is all one step but it’s been several months and forgot how the sim gets activated).
4. Add this device ID to my SQL backend.
5. Flash the code and device OSfirmware
6. Run “particle usb setup-done” command to set the setup done flag
7. wait till the device SIM is activated and connect it to the cloud
8. claim the device under a demo account I have and confirm basic device functionality.
9. unclaim the device so it can be claimed by the customer once they receive it.
10. package it up and ship it out.

Don’t get me wrong, it’s not bad or hard but doing each step one at a time for say 20 Borons gets a little tedious. Wondering of easier/quick ways to accomplish this. I’m using VS Code and already have it setup as a product in the Particle Console. Any guidance, tips, or references to a tutorial would be appreciated! I did some searching on here and read through the product tutorial again but nothing stood out. Thanks!

[gusgonnet]

@jgskarda

• claim the device under a demo account I have and confirm basic device functionality.
• unclaim the device so it can be claimed by the customer once they receive it.

Hi,

I think I read somewhere that you do not necessarily need to claim a device under a product, so perhaps these two steps can be spared.

Best,
Gustavo.

[ScruffR]

You can import Device IDs and SIM ICCIDs in bulk by uploading text files that provide the info for all your devices at once.

Console | Tutorials

SIM Management | Tutorials

and you can also “auto-approve” new devices that are running your product firmware

Security | Tutorials

You can also use your firmware to set the setup-done flag (although that should not be executed on each device boot-up)

Device Blinking Dark Blue

[jgskarda]

@gusgonnet

I think I read somewhere that you do not necessarily need to claim a device under a product, so perhaps these two steps can be spared.

The reason I was having customers claim a device was they can call functions on the device. I.E turn this on/off, take readings, etc. by having them claim the device it adds a little security in that they can only control the devices they have claimed. That way I pass their particle token with the api call so their token only controls their devices. I’m sure I could of done this in my own backend and maybe that would of been cleaner but that’s the reason I was having them claim it. Possibly something I can clean up and simplify in the future.

[jgskarda]

So I am understanding this as I can configure it to auto approve the devices running my firmware to eliminate the device ID import step but I still need to import the SIM cards. Seems quick and easy via WebCam maybe. I don’t have a boron box in front of me but I’m assuming the ICCID is on the outside of that box that I can just scan? Or maybe I’ll have to dig back through my emails when I ordered them all originally for the list.

Then I can just set the device setup flag via CLI, flash my firmware via USB and the device should connect and be added to to the product tab.

Question though, if I’m able to set the device setup done flag through firmware but it is not recommended to do it every execution of setup(), then when would someone do it via firmware? Especially if it’s easier to do it via the CLI instead of loading two different versions of Firmware. Is the Firmware approach meant for non Boron devices?

[ScruffR]

@jgskarda

if I’m able to set the device setup done flag through firmware but it is not recommended to do it every execution of setup(), then when would someone do it via firmware? Especially if it’s easier to do it via the CLI instead of loading two different versions of Firmware. Is the Firmware approach meant for non Boron devices?

You can store your own setup-done flag in EEPROM and on startup you check whether it has been done already or not. If not, do it and reset.
This way you will only need one version of your firmware that does all you need plus the optional task of setting the flag.

[gusgonnet]

@jgskarda

I was having customers claim a device

Yes, please continue to have your customers claim the devices.
However in steps 8 and 9 it's you claiming them, and that i think can be spared.

[jgskarda]

Yeah ok. That makes sense. Thanks!

[gusgonnet]

perfect, also, steps 2~6 could perhaps be automated with a script (bash, python, something).
That’ll be an investment, and if it’s worth or not may depend on how many devices you have coming.
Cheers!
Gustavo.
PS: if you do not mind, please post at the end of the thread what worked for you so others can find your fine-tuned process and potentially use it - thanks!

[jgskarda]

@gusgonnet

steps 2~6 could perhaps be automated with a script (bash, python, something)

Haha. I was tempted to add an “admin” page to my web app specifically designed to commission new devices. I.e scan the ICCID on the box, scan the QR code I put in the outside of the enclosure as my own serial number, have an API call to particle to activate the SIM and add the device id to the product, add the device to my backend SQL, then call each “function” and all results are within an expected range it passes. Most of what I do outside of particle is in Python already so I like your idea of a Python Script. Hopefully eventually I’ll get to enough devices that it’ll warrant the time to build but not for 20 devices. Although maybe I’ll do aspects of it just for the fun of it in the next few months.

And yes, I’ll be sure to document the steps I take to commission the 10-20 I have coming. Maybe even take a video and post to YouTube to help others out. Might be 2-3 weeks out yet I’m just doing some early planning.

[armor]

@jgskarda

• claim the device under a demo account I have and confirm basic device functionality.
• unclaim the device so it can be claimed by the customer once they receive it.

The advice I have received from Particle is that for a Product ownership is not required and in fact is the preferred way to go, however, I believe you initially need to claim ownership to be able to load your product software? Certainly after that we remove the ownership. We have +1000 devices and 10 products, they are not customer claimed and always remain on a product scoped access token. Customers interact over the internet via a web app. In summary, somewhat different from your devices. Being able to manage devices via the console is an absolute must though. Good Luck.

[jgskarda]

@armor

Customers interact over the internet via a web app.

Thanks for the info and guidance. I also have a Web App for the user interaction and I use two legged authentication. When a user logs in to the web app, I also refresh their individual token with Particle. I save that token to their cache. When the user wants to say “turn on the lights”, the web app reads the token from cache and makes a direct api call to Particle given the device ID and their specific token. Since the token is only scoped to the devices they own I thought this was a safer way to go.

If the devices are not claimed to a user, in your web app, does it make an API call to your own backend and then your back end makes the API call to Particle? How do you ensure a user can only control the devices they own if they never claim it. I assume your checking that user is the owner against your own Database before passing off the request to the particle API?

Maybe I’m just over thinking it and it’s such a minimal risk as somehow they would have to know the Device ID of someone else’s device.

What I do like about your approach is you never have to worry about conflicting by data of who owns what device. In my current setup, I manage it in SQL but obviously Particle does too. It’s possible these get out of Sync with my current approach. Right now I’m only playing with 10-15 devices but hope to grow from here.

[armor]

It might be but there is more chance for error and our users (IMHO) don’t want to get involved with Particle or the complexity in this. They need to be ID’d by the web app of course.

[jgskarda]

Yeah makes sense. I’m sure I’m over thinking it in some areas. If my customer base grows I may migrate to your approach on my next backend and front end overhaul. I’m tentatively planning on that being a summer 2021 project anyhow just a matter of what is the scope and what all needs to change/be updated. Thanks again for the guidance!

[jgskarda]

So I was able to do 8 devices in about 75 minutes using these steps. I did have a few questions though for the community. Here are my refined list of steps:

1. unpackage it from the box, attach antenna and plug into USB port
2. Run Particle Identify to find the ICCID and device ID
3. Add the SIM from the Particle Console given the ICCID from step 2.
4. Use the Device ID from step 2 as a parameter to and execute a stored procedure to add to my SQL backend.
5. Run “particle usb setup-done” command to set the setup done flag
6. Run Particle: Flash application & DeviceOS (Local)
7. Wait until device is connected. Device is setup to auto join the product family once cloud connected.
8. Rename the device in the Particle Console
9. Claim the device under a demo account from my Webapp
10. Run basic tests from the web app for functionality and proper sensor readings
11. unclaim the device so it can be claimed by the customer once they receive it.
12. Power it off, package it up and ship it out.

A few “tweaks” I hope to make to the process to save some time which also prompts a few questions to Particle:

1. Can we not use the “scan ICCD” from the Particle Console for GEN 3 devices or is that interface only for the traditional SIM card that comes with an Electron? It would be easier and quicker if I could simply wave a QR code in front of my computer camera to scan in ICCID or serial number vs having to run Particle Identify to obtain it. I couldn’t find the list of ICCIDs back when I ordered them so had to run Particle Identify to obtain it.
2. Using VS Code - Workbench, why does Particle: Flash Application & DeviceOS (local) always have to compile it? I was expecting it would simply flash the binary it already has and I’d use Particle: Compile to actually create a new binary when needed. If I could just load the new binary without compiling every time this would save some time. Is there a single command I can do this from the CLI that would just take the existing .BIN and flash it with the device OS vs having to recompile it each time?
3. If I don’t add the SSID, oddly enough, the device still connects to the cloud and the device shows up under my product devices. However, the SIM card never was added. This was a bit unexpected behavior I thought. Would the SIM eventually have been transferred to my account automagically or what would of happened? If SIM cards could also be auto approved, that would make that process a little easier and remove a few steps.
4. I know Python fairly well from a web application, interfacing with SQL and making API calls, anyone know what it would take to run Particle CLI commands from a Python script? Is that possible. I think a lot or nearly all of these steps could be automated with API calls and some scripting but wasn’t sure how to actually run the CLI commands from Python. Not something I’d work on anytime soon but would be would be a fun challenge to create something sometime.

[nrobinson2000]

@jgskarda

I know Python fairly well from a web application, interfacing with SQL and making API calls, anyone know what it would take to run Particle CLI commands from a Python script? Is that possible. I think a lot or nearly all of these steps could be automated with API calls and some scripting but wasn’t sure how to actually run the CLI commands from Python. Not something I’d work on anytime soon but would be would be a fun challenge to create something sometime.

This is one of the features of neopo. It provides an encapsulated particle-cli installation that can be used from the command line with neopo particle or used inside python with neopo.particle.

Examples:

from neopo import particle

particle()
particle("list")
particle("serial monitor")

particle("usb setup-done")

args = ["flash", "--usb", "firmware.bin"]
particle(args)

@jgskarda

Using VS Code - Workbench, why does Particle: Flash Application & DeviceOS (local) always have to compile it? I was expecting it would simply flash the binary it already has and I’d use Particle: Compile to actually create a new binary when needed. If I could just load the new binary without compiling every time this would save some time. Is there a single command I can do this from the CLI that would just take the existing .BIN and flash it with the device OS vs having to recompile it each time?

Using neopo you can compile and flash application and deviceOS for a project with:

$ neopo flash-all

When compiling for boron on 3.0.0-beta.1, the deviceOS binary can be found at:

~/.particle/toolchains/deviceOS/3.0.0-beta.1/build/target/system-part1/platform-13-m/system-part1.bin

The application binary can be found in the target/boron or target directory in your project.

Using particle-cli, you could place each device into dfu mode and flash the system and application binaries with something like this:

from neopo import particle
import os

# Resolve system-part1.bin
system_part1 = "~/.particle/toolchains/deviceOS/3.0.0-beta.1/build/target/system-part1/platform-13-m/system-part1.bin"
my_system = os.path.expanduser(system_part1)

# Flash system-part1.bin
particle("usb dfu")
particle(["flash", "--usb", my_system])

# Flash application
app_name = "YOUR_APP_NAME"
app_path = os.path.join("target", "boron", app_name + ".bin")
particle(["flash", "--usb", app_path])

Since you mentioned it, I'll look into implementing a way for neopo to flash existing binaries if possible.

@jgskarda

Can we not use the “scan ICCD” from the Particle Console for GEN 3 devices or is that interface only for the traditional SIM card that comes with an Electron? It would be easier and quicker if I could simply wave a QR code in front of my computer camera to scan in ICCID or serial number vs having to run Particle Identify to obtain it. I couldn’t find the list of ICCIDs back when I ordered them so had to run Particle Identify to obtain it.

If you run particle identify in a subprocess you could capture the stdout and get the ICCID automatically in python.

---

Standard disclaimer: Neopo is awesome, but it is not an official Particle tool.

[gusgonnet]

@jgskarda

anyone know what it would take to run Particle CLI commands from a Python script? Is that possible.

Hey Jeff!
I do a lot of python at work and when we needed to call scripts on the command line we used a library called plumbum and you can find it here:

plumbum

I think it has everything you need.
Cheers
Gustavo.

[jgskarda]

Wow… Awesome! What I am building is very seasonal in nature, my focus right now is that and I’ll stick with my manual process for now. But once that season is over, I’ll be sitting down and diving in to this. on the surface neopo and/or plumbum seems to be exactly what I’m looking for. I’m not a Python or programming expert by any means but with a package like these I can almost always figure it out.

Thank you both @gusgonnet and @nrobinson2000 for all the great info! I’m excited to give it a try. As mentioned, it’ll be 2-3 months before I can carve out time to give it a try but when I’ll do I’ll be sure to post my learnings back here and maybe even be able to share my Python script I end up using. Great stuff!