I had a Photon connected to battery power running a simple app that played a pretty pattern over an LED strip, which slowly drained the batteries and died completely without my intervention but whilst I watched it sadistically. After this, once I powered the Photon on via a reliable power (eg, USB), it went into “listening mode” with the blue flashing light. I went through the steps to reconnect to the device to my WIFI again via the iPhone app and it went through everything with ticks, but then at the end showed an error saying that the device is offline and to try again.
Have tried several times, also tried using various different power sources, putting into safe mode, restarting the process, etc. In desperation, I have already begun playing Enya mega-mixes on repeat whilst I consider that my only remaining option is suicide, but thankfully my enduring hunger is keeping me optimistic of a future beyond this terrible grief.
I just flashed the same app to a different Photon and it has started up and is working fine (powered by same USB), so it’s unlikely to be a problem with my app code. (can provide code sample if needed).
My gut feeling (because all good engineering decisions are best made on assumptions), is that it had something to do with the device running down into a low power mode whilst the batteries were dying. I’ve read this can be bad.
Awesome, thanks @ScruffR - is this something I can do via serial monitor with the device connected?
I could never get the particle CLI setup working on OSX, mostly because I am retarded, but also because it is not trivial and I drowned in issues with Node/NPM so eventually gave up.
If only we had a nice standardised Docker image we could use to sandbox stuff in…
You could do that via dfu-util and some API calls, but I wouldn’t do that.
I’d definetly advise to get Particle CLI installed.
Maybe you have more luck now. Or you just find a Windows machine
I have hit a wall trying to get particle-cli installed on OSX, it seems an impossible task and a bottomless rabbit hole of issues and solutions.
I’m going to try installing a Ubuntu image on VirtualBox on my mac, see if I can get particle-cli installed on that.
It’s a massive turnoff to the platform after experiencing the combination of how easy the Photon got into this “semi-bricked” state and how insanely difficult it is to fix it, to be honest.
Hey @ScruffR yes thanks for the follow up. Thanks to the patient and generous efforts of @kennethlimcp I now have the particle-cli running on OSX. I can now try and run the particle-clip commands you mentioned, so will try that and post back here.
Trying to keep issue threads isolated and not crosspost.
Okay so after a few hours with your community help it was possible to get the particle-cli working on OSX\
It wasn’t obvious, but to find the device ID I used the Particle console to find the device by the name that I last assigned it (https://console.particle.io/devices).
After that, I fed that ID into the following CLI command;
pete:Desktop noofny$ particle keys doctor [photon-device-id]
Found DFU device 2b04:d006
Found DFU device 2b04:d006
New Key Created!
Found DFU device 2b04:d006
Found DFU device 2b04:d006
Saved!
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID 2b04:d006
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "DCT Flash "
Downloading to address = 0x00000022, size = 610
Download [=========================] 100% 610 bytes
Download done.
File downloaded successfully
Saved!
attempting to add a new public key for device xxxxxxxxxxxxxxxxx
submitting public key succeeded!
Okay! New keys in place, your device should restart.
The device restarted and immediately went into normal operation,.
I hope this serves as a help to others. Even more, I hope that someone updates the docs so that every other n00b doesn’t have to go through the rubbish I went through, which ended up relying on several elites and hours of time, just to get a “semi-brick-state” back to a normal state.
I think it’s fair to say there was something very important to learn/document here in order to progress this platform towards actual maturity.
What can I do to help in this case, apart from capturing all this in this thread?
Another way to obtain the device ID is via particle identify with your device in listening mode
The install issues are relatively hard to get around from Particle’s side, due to the unpredictable state of peoples heterogenous OS states (including privileges, pre-installed SW, …)
For Windows this was a big issue till the arrival of an installer
We could all get around the problem of getting particle-cli working by containerising the thing, creating a nice little Docker image with a small *nix, node and the particle-cli module installed would be neat and would solve the problem for everyone on most platforms.
Have you guys already looked into this and hit a wall, or is it just a matter of time? The problem I immediately see would be addressing USB/COM ports from a virtual OS. I might try and take a look and see if I can get something working and publish it to the Docker community hub if I get success.
