I’ve lost track… Have you tried particle keys doctor <DeviceID> and particle keys server? The red flash might indicate a key issue, although I wouldn’t expect it to come online with bad keys.
Is there a list of ports and/or ip addresses that must be allowed to communicate?
CoAP port 5684 needs to be open.
particle keys doctor e00fce6866a3f9b7ddae1e##
New Key Created!
Saved!
Saved!
attempting to add a new public key for device e00fce6866a3f9b7ddae1e##
submitting public key succeeded!
Okay! New keys in place, your device should restart.
particle keys server
Okay! New keys in place, your device will not restart.
power cycled....still a very long about of blinking cyan.
No change in how it acts.
I want to confirm that you’re still seeing the occasional red flash, correct?
Correct
It will be flashing (fast on/off) cyan then I will get a single red flash. Then it will begin a fast cyan.
When it finally gets to a breathing state it will randomly start fast flashing. Sometimes it appears to go through a boot cycle randomly.
Thanks. I replied in the associated support ticket.
I have a very similar challenge. And I get the single red flash as well.
Any solution, or is it still being investigated?
Are you running Device OS 0.9.0? Did you try the Have you tried particle keys doctor <DeviceID> and particle keys server?
Also, if you put the Argon into Safe mode, does it start to behave (e.g. be pingable/signal-able)?
Device OS 0.90, yes.
I’ve done the Particle keys repair numerous times.
It’s not constant. And many times, rebooting the Argon will allow the Xenon to connect properly.
I’m really getting tired of trying to make my Particles just work. I’m not throwing in the towel, but it would be so nice if we didn’t need to debug the mesh portion of things.
Today, I have my Particle Argon v0.9.0 that had been running my application successfully for a week prior to the weekend, but when I came to it this morning it was breathing Cyan, but unresponsive to pings, signal, web flashes, etc.
I reset several times with no change. Always breathing cyan after 20 seconds or so of fast flashing while getting connected.
My application puts the connectivity into the background using SYSTEM_THREAD(ENABLED); and it has an NFC tag reader that queues messages into the PublishQueueAsync which is seemed to be doing, but none of the messages were reaching the Particle Cloud.
I put the device into safe mode and I was able to ping and signal the Argon. I then reset the Argon and when the Argon started breathing cyan again, the device responded to pings, signals and my application successfully sent the many NFC tag reads that were persistently queued up. The application code was unchanged.
Any insight into how I can avoid the need to enter safe mode to repair connectivity is appreciated since I’m preparing to deploy this specific Argon into the field.
Hello,
Question? When you say reset, is it a powered down reset? or press reset button reset?
I have experienced Boron LTE v0.90 breathing cyan but unreachable until I powered off and back on. I didn’t press reset button…The device is in an enclosure.
Regards
Press the button reset. My enclosure can be opened for physical maintenance. The device is powered by USB from a wall socket and a Particle battery plugged into the battery connector.
I will try the power down reset if/when the problem is observed again.
I have experienced the same with the Argon on the same release. Only power cycling got it running again. The difference is that after the update it seems to have taken weeks to get into that state, where before the update it could happen after a few days.
I have observed the same behavior in three more Argon devices. Two were recovered by power cycling, the other by safe mode. The problem is reproducible on all of my Argons. I left each device idle for days without interaction, however, they power on and off a couple of times per day.
Two of my Argon devices went to sleep for the night and woke up this morning breathing cyan, but unresponsive to a Web IDE signal and unable to publish a message until I power cycled. Both of those devices were working last evening before their 12 hour nap.
0.9.0 on one
1.1.0-rc.1 on the other
So it seems the problem remains with the new release candidate.
I have the same issue on all three devices and is worse for the Xenon’s as when first connected thru either the Argon or the Boron works great, then over time they all show they are connected to the cloud tho no response when you try to retrieve variable data and or try to ping them. I have one Argon and five Xenons in a network and only have access to the Argon and one other Xenon. This has been the same with the Boron and 4 Xenons tho I couldn’t get a response from the Boron tho it was supposedly connected to the cloud, Xenons show as connected also. The Boron and Argon are only end points.
Is this a Keep Alive type issue???
I have another network setup with one Boron and one Xenon. I can always ping the Boron. The Xenon however only communicates with the Boron over the network when ever it wakes from sleep. This has been working for nearly a week with no issues…
Same experience again with a stand-alone Argon running 0.9.0. Was about to update it.
Again a hardware reset does not get it online. Surprisingly the EN pin did not get it online either …
In both cases the Argon restarts and blinks green for a few seconds then signalling that it is online breathing Cyan. But the console show it as offline - even after reloading. Can’t ping or signal. Also it is not performing it’s function (AC control).
After a short while the Argon blink cyan for a few seconds and then breathes Cyan but it still not online.
If I cycle power removing it, the Argon jumps online happily again for true.
Lesson learned looking for a reliable watchdog concept for a new always online product based on Argon/Boron:
- LED and particle.connected() can not be trusted even right after a restart.
- Neither the RST pin or the EN pin alone with a HW watchdog is sufficient recovery
Sounds like this problem: Over 20 Devices just went down
1 Like
Thanks it worked for me.