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

I will try that but as I said I did exactly the same in DFU mode with my Core and that works just fine. Can the hardware be faulty?

Just ran it again with a different cable: same result.

Considering the LED is still working, I doubt that it’s a hardware issue. Yesterday or so I noticed that getting a decent connection while the photon was in an internet button was a lot harder than without it. Hence the suggestion to take off external circuits, and try other power supplies/cables :slight_smile:

@Moors7, Thanks, I now realize I miss posted here. I tried the keys doctor again and it work this time around. Before posting I had already tried the keys doctor a few times before but it didnt work. Not sure why it worked now but its now connecting to the cloud.

1 Like

It is sitting on an empty breadboard, any other suggestion?

I looked at my router log and there is no entry of the MAC address of the Photon. Anyone seen this before?

So tried different cables and re-flashing without any success.
Do I have to assume the Photon has a HW issue?
Is there a warranty on the Photon?

I just created a new topic: Photon does not connect to ATT U-verse 3801HGV router
because the Photon works just fine in another Wifi network.

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?

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

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

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.

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.

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.

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.

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?

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’)

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

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?

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

void setup()
void loop()

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


Let see if this link is working:
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…

1 Like

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.