Photon: Failed to claim device, server said: [object Object]

Troubleshooting
21

Hi, I have the same problem as above, so rather than creating new thread, hope someone can help me on this. I have device which not connected to the cloud (blinking cyan). I have done:

  • Run the particle keys doctor your_device_id successfully.

  • Log in to my Particle account using CLI.

  • Run particle setup wifi successfully.

  • But when I try to add device to my account, having same error as above:

    particle device add 3800****
    Claiming device 3800****
    Failed to claim device, server said: [object Object]

Still blinking cyan (not breathing cyan). Any help?

22

Is it blinking cyan only, or are there other colors in between as well, most notably orange?

23

No, from reset it just normal green, then seems to be connected to WiFi for quick period (solid green) then blinking cyan.

24

Is it really the same issue, since the root cause for the OP was an ā€œincompatibleā€ router?
Have you got the same brand/model router?
If so, you might be out of luck (see the linked thread) unless Particle can actually find out where the incompatiblity comes from.

25

Iā€™m in the office, so the only option is this corporate wide WiFi (which has been used for a while without issue) and Android phone access point. I will go home to check if that is ok on my home router, but would be useful if any other potential issue raised.

Just to add history on this devices (two photons behave the same), we do use it for local development using dfu, running firmware that not connected to particle server. But I assume the keys doctor should take care of any key problems.

27

Hello, Iā€™m still having issue with three out of four photon I have. Try with many different routers making no different.

As I said before, these three Photons has been programmed using DFU and running code that never connect to the cloud, I wonder if some kind of expiration, so particle cloud now refusing them, and repairing the key also not solving the issue.

28

Now Iā€™m confused
You ā€œcomplainā€ that your devices donā€™t get to breathing cyan yet you say the code they are running does not connect to the cloud anyway.
If the code does not use/connect to the cloud why should they go breathing cyan (=connected to cloud)?

In order to rule out a device issue, donā€™t run any of your code but flash Tinker or even an empty sketch and see how things go then.
Only after you got the device connected and claimed successfully flash your own code.

29

The three problem devices does not breathing cyan when I want it to connect to cloud by setting the device in to programming mode (led blinking magenta).

In order to me to be able to flash anything, I need to own it, now I havenā€™t got this phase yet due inability to connect to cloud.

So if there is any way to own the device without having it connected to the cloud, please let me knowā€¦

Additional information, when I use DFU to try to flash tinker:

particle flash --usb tinker-0.5.1-rc.1-core.bin
running dfu-util -l
Found DFU device 2b04:d006

Error writing firmware...Incorrect platform id (expected 6, parsed 7357), use --force to override

So could be someone (my colleague) flash it it incorrect platform ID, therefore these devices are not a valid Photon anymore?

30

If your devices are Photons you won't want to flash a Core firmware.
You need to target Photon if you are programming a Photon.

And you can always program a device without having it claimed locally, but you won't be able to do OTA updates or use any of the Particle cloud features.
And claiming requires the device to be online and Particle connected at least once while doing it (there might be hacky ways around that tho')

31

As ScruffR said, that binary image is for the Core only. However, the Particle CLI knows how to flash tinker without needing a binary image. With the Photon in DFU mode (blinking yellow):

particle flash --usb tinker
32

Ah I see, well I can only see core tinker on the download pageā€¦ ok anyway I know what you are saying, I donā€™t need these to connect to particle cloud, or need OTA update, or any particle cloud feature.

Now I move back to use Particle Dev setup and CLI to prorgam these photons, I manage to flash the code in to them, and seems to be running. But now I have a nother problem which seems to be very related. I use Blynk library to get the data across to blynk Apps.

The same code flashed to the working Photon, it works fine and connected to the blynk server and apps (remember I still have one working photon). Now if I flash the same binary to the three non working photons, it would refuse to connect to Blynk serverā€¦ I know you are going to say ask Blynk, but because these three Photons also refuse to connect to Particle cloud, it must be something wrong with the communication stack somewhere.

Let just assume, my ex-colleague, has been tinkering with these three Photons, accessing the multithreading support from the OS, and change some OS parameters perhaps, as well as WiFii stack parameters. Surely there is a clean update that can override all what heā€™s done?

33

No we won't promise :wink:
As it seems your devices not even make it to the network.
Could you post a short (about 30-40sec) video of the color codes a device with Tinker flashed is showing on power-up.
But before wipe all current WiFi credentials (hold SETUP 10+ sec till rapid blue flashing), add only one set of valid WiFi credentials and reset the device.

Another trick someone might have played on you was to select the ext antenna and/or set a static IP
To counteract this, flash this sketch

SYSTEM_MODE(MANUAL)
STARTUP(WiFi.selectAntenna(ANT_INTERNAL))
void setup()
{
  WiFi.on();
  WiFi.useDynamicIP();
  WiFi.connect();
  waitUntil(WiFi.ready);
  Particle.connect();
}
void loop()
{
  Particle.process();
}

And you can always reflash the system too (see instructions in this link)

34

Let see if this link is working: https://goo.gl/photos/bq2jqCPbAVkyQV1AA
That is after flashing with default tinker as instructed above.

I then try to wipe out the wifi setting (10sec setup press), no different, and then try to set internal antenna explicitly also no different.

Then I do the dynamic IP setting, and this is SUCCESS!!!

Well perhaps good idea to add particle CLI equivalent to ā€˜pingā€™ to check the internet connectivity. Many thanks!

Still have one with bad key (bursting red/orange within blinking cyan), but for another dayā€¦

35

Just as a general question, why does the particle need to be online in order to claim it? I believe you can unclaim an offline device, so why would it need to be online to claim? AFAIK, itā€™s the cloud that does permission checking before forwarding commands to the device, so theoretically it could just be an offline process.

36

Invalidating a connection can be done from either side. Once one side is ā€œbrokenā€ the connection is invalid.
For validation both ends have to match up to create a valid connection.
So offline unclaiming doesnā€™t imply offline claiming has to work too.

37

Sure, but what exactly needs to be ā€œvalidatedā€ by a live running device that the particle cloud doesnā€™t already know about? Or is there something stored in persistent (EPROM?) memory on the device?

38

This might help you understand the procedure
https://docs.particle.io/reference/api/#create-a-claim-code

39

I have a difficult photon device claiming, but I do not know if it will help you.
(ā€» [SOLVED] Photon Device claiming failure)