Hey ,
I have been doing a pilot launch of a product with the Particle P1 chip. I have an issue with a beta tester across the world who cannot get pass verifying product ownership stage of the setup process. I have this issue before with the photons and I have just used the CLI to set it up. However, in this case the customer doesnt have knowledge of CLI and that process can get quite messy for a customer. How can I resolve this issue?
Here is a screenshot of the console.
You haven’t explained your product setup model. When you say a customer/beta tester can’t get past product ownership stage does this mean you ship the P1 unclaimed and the device unnamed? Unclaimed isn’t good practice - from a security viewpoint. I guess the device is also not cloud connected before shipping and the customer does this? Do you add the device ID to the product using the console?
Yea they are shipped out unclaimed and never connected to cloud. I add the device ID by console in a text file.
I thought as soon as you connect them to the cloud they are charged.(after 100 devices).
@ScruffR Do you have any input on this matter? How should I handle this?
I’d have to defer this question to @mstanley as I’m not up-to-date with the ins and outs of product development and accounting (as I’m not a Particle employee).
Thanks for pinging me @ScruffR
It should be the case that all associated devices that are added will incur charges past 100 devices, so you are correct that adding your unsold devices would incur additional charges each month. Therefore, I can see why you would want to avoid this.
With that said, we do have libraries available to handle new device setup. You could consider building an app for your user to setup the device through their mobile phone, making using of our provided Android or iOS SDKs. This would not require them to use the CLI for setup purposes and also opens the doors to simple-auth and other functionality that would allow you fleet style management as the device owners, but creating a white-labeled experience where your customer is working through your ecosystem, rather than Particle’s directly.
If you went with a mobile application route that handles the setup of Particle through the SDKs, the devices could still be unclaimed in this state and it would allow you to prevent premature billing for ownership of the devices.
Thanks for the reply,
We actually have an app for Android and IOS using the SDKs. This issue is happening using the app. The last step of the setup process on the app is failing (aka “Verifying Product Ownership”.
Gotcha. In that case, would you be able to provide specific debug logs of the failures that are occurring? I can see about pinging our respective engineers on the SDKs to see if they might have some additional insight.
The product is in a different country from me. I have asked them to ship it back then i can give you specific debug logs.
Hi Div,
Thanks for keeping me posted. My apologies on the inconvenience of having to ship the device back, but comprehensive logs will certainly be helpful in identifying this issue at its root.
Hey @mstanley. Bit of change of situation but i think you can still help. So the controllers that were causing the issue seemed to work fine in the country where i am. However, I am in a different pickle currently. One of the users couldn’t get past the 1st setup process check “Configure Wi-Fi Credentials”. We are getting that controller also shipped to our country.
(We have checked that the user has been putting the right credentials)
This problem looks like an issue with Particle chip.
My question to you is if you know if the debug logs are automatically enabled or do i need to do some extra step to enable them.
Thanks for your help.
Hey Div,
Great question.It’s my understanding that all the releases on our device-os repository have additional debug logging available in their binaries from a DEBUG flag being set–but the ones that are OTA do not.
If you have any sort of assembly line process that pulled from our device-os Github repo, they should have debug logging accessible. If not, you’ll need to flash your device OS from the Github Device OS repo.
Once you have the Github Device OS binary, your user application will want to have SerialLogHandler logHandler(Serial, LOG_LEVEL_TRACE); set in it. From there, you should be able to have verbose you can read from the serial connection.
Hey, just got the product back today. I used the log trace and this is what it is showing.
**Serial connection closed. Attempting to reconnect...**
**Serial monitor opened successfully:**
0000001038 [hal.wlan] INFO: Using internal antenna
0000001048 [hal.wlan] TRACE: connect cancel
The trace doesnt show anything while the device is being setup and the setup shows this after failing on the first check (configuring Wifi). I have entered the correct Credentials.
Those logs seem particularly short. I’m wondering if there’s a sleep or something else interrupting he log trace. Are you using particle serial monitor --follow, by chance? The --follow flag should persist through any disconnects.
Yea I am using --follow. Always Hahaha 
. That what i thought too. What other steps can I take?
Just to confirm, is this an issue with multiple devices, or just a select one or two? I’m starting to wonder if this is possible just an isolated, defective unit. There’s nothing routine here that sticks out to me, and it seems like there’s some hiccup on readout/trace behavior and potentially an issue establishing a connection.
It is currently happening with one unit. But I am scared that it might not be an isolated one and if we go into full production, then this issue might arise again.
If you think its isolated then i would like to have some sort of check that my production team can do before they are packaged up. Do you have any method to test this sort of thing without connecting to cloud and getting charged for it.
Cheers
@mstanley I dont think that was a one off situation. It had happened again and now I want to get to the bottom of this.
I am using the android SDK to run the setup process, (Note: I am using the two step authentication). The P1 successfully gets claimed but if I run the process again it fails (Works half of the time). I am sure it has nothing to do with the User firmware on the P1 (running a minimal program) but maybe the SDK.
Im not sure what is going on but I logged the CheckIfDeviceClaimedStep.java file in the SDK and see that when it is successful, it is able to get the list of devices connected to my account back. But when it fails it was unable to. Image below shows both scenarios.
@rickkas7 Do you have any input regarding this matter?
Hi @Div_IoT,
My apologies on the delay here. If I understand your issue correctly, you are noticing intermittent failures when trying to claim a P1 device through the Android application? Initial claim attempts fail but follow up attempts will work fine (without need to restart the app or device). Do I understand that right?
