I have a Photon and an Electron that are both powered and running the same version of my firmware. I record the time (Time.now()) in a cloud accessible variable whenever setup() is run; thus I know the time that the device was last reset. I noticed (today) that both devices were last reset at exactly 10:43 pm on 3/28/16.
The spooky thing is that these two devices are 2 miles apart and located in totally isolated (from each other) environments. Both devices are physically accessible only to me and I did not mess with either one anywhere within hours of this time. Likewise, only I have the password to my Particle account and I did not flash code or do anything to cloud access either of these devices anywhere within hours of this time. There is nothing whatsoever in the firmware that (explicitly) causes a reset (no System.reset()) nor a call to setup(). There is nothing in the firmware outside of setup() that stores anything into this cloud variable. So only a reset can store the time, and the two devices were reset at precisely (within a few seconds) the same time.
There was no power failure at this time, at least not one where the Photon is (where I am and I have various indicators if the power fails). The Electron is 2 miles way and it woudl take a large area power failure to lose power to both devices. Anyway, if power fails on the Electron, there is a battery backup via the LiPo for quite a while. So, absent a power failure reset, a push of the reset button, code to cause a reset, or remote access to the devices (e.g. to OTA flash firmware), what could possibly account for this? Does anyone have a theory??? It’s pretty spooky!
The photons in front of me sometimes disconnect from the Wifi network without any reason. Most importantly, they should be able to reconnect without any intervention.
My issue is that resets blow away my data log, which is stored in RAM. The data is there, of course, but the pointers are reinitialized. The log is a circular buffer of Strings, which cannot be placed in Backup RAM. If this happens too often, I may have to re-code the whole thing using C strings, but the String class is so much handier for string building and modification.
My real preference is to publish the data and record it elsewhere, e.g. a Google sheet. I have been doing this using IFTTT, but sometimes the Google sheet is missing entries (the logged data is sequenced with a one-up number, so I know if an entry is missing) and often it takes a long time for the data to get to Google (timeliness is very important). The latter may be an IFTTT issue, but the former seems to be a Particle issue, per another thread on this forum. Rather than rewriting the firmware to use C strings, it might be better for me to subscribe to my own publications, as suggested on the other thread, in order to make the publication mechanism robust.
My purpose here, then, is to report so that others can be informed about this issues and perhaps the Particle folks can improve the inherent reliability, to everyone’s benefit.
@BobG Bob I tried sending data to Google Sheets in the past also and it would miss data the same as your experiencing. I would look at Ubidots.com as a place to push your data to to be graphed and logged. It’s free.
@RWB: thanks for the info about Ubidots. I was wondering if you have information about the reliability of the Ubidots library for getting events data to their sire, vs particle.publish(). Also, do you have timeliness information - how long it takes (worst case) for a new event on Photon/Electron to get to the Ubidots database from the library call on the device. These are the two issues that we have experiences with IFTTT/Google sheets.
@kennethlimcp: The Core would generally (but not always) reset after losing WiFi connectivity. The Photon (with the RTOS) is a lot better about this, but I could still get it to reset occasionally in forced error testing (by unplugging my WiFi router). I don’t know about the Electron because it is all new and uses UDP vs TCP to connect through 3G cellular.
Ubidots has been super reliable from my testing and its fast. I don’t see it as any less reliable than Particle Publish. You will probably have more data consumption when sending data via the Ubidots method vs the Particle Plublish method which means more Electron Data usage. But they are working on Electron Specific code to reduce the data used when send them data.
I have no idea about TX to RX times but it feels instant.
@aguspg Is part owner of Ubidots so he is probably a better person to ask for answers to technical questions.
How does your circular buffer with String work?
Heavy use, resizing, transfer of String instances might cause heap fragmentation and eventually lead to a hard fault as @kennethlimcp suspected.
Recently I had two Photons and one Core start resetting over and over.
These devices are located many miles apart. No power failures were reported in these different cites.
Starting at 22:34:15 3/28/16 Mountain Time, all the devices went though several re-boots.
Each device has an sms notification when these device boot up so my phone went crazy.
After 3-4 resets, all devices are functioning normally. Data collected was wiped due to the boot.
At this time I had no internet access so I could not have flashed these devices.
@chipmonk: My resets were at 22:43 PDT. Of course, this is the last reset - there might have been several before this time (I would not know from what I record on the devices). If you are somewhere that does not observe DST (e.g. Arizona), then your mysterious resets happened just about the same time that mine did! And we are hundreds of miles apart. So it is beginning to look like something happened in the Particle cloud around then. What else could explain all of this?
@ScruffR: It is an array of Strings and yes, heap fragmentation can occur. We found this out on the Core, where the RAM is much more limited. However, the strings are limited in size (25 chars), so once the array fills, it simply overwrites (circular buffer) and I do not believe that any more RAM needs to be allocated from the heap, since the new strings are the same size as the previous ones. On Core, we can only run a buffer of about 40 Strings without risking heap fragmentation and red SOS errors (8 flashes - out of RAM); on Photon and Electron (which have much more RAM), 100 Strings works just fine (I have not tested to find the upper limit, but it is > 100 for sure). This has been stress tested on 7 Photons in the course of almost a year, so it would not explain the resets. In any event, the Electron only had about 55 entries in its circular buffer and the Photon only had 3 entries in its circular buffer when the mysterious reset happened. Also, I can guarantee that the Photon had no data going into or out of its buffer anywhere within hours of the reset (both ways), because the Photon unit is on my bench for testing and development and I wasn’t doing any testing or development anywhere near this time. The Electron is in a remote environment and it is unlikely that there was any buffer entry/access anywhere around the reset time, although it is not possible for me to say for sure. BTW: I did test the Electron filling up the buffer on the bench (along with a host of other stress tests) prior to deploying it to site, so differences between Photon and Electron system firmware does not cause fragmentation problems on Electron either.
I would assume that there are record logs for everything that happens on the Particle cloud and if there is @Dave should be able to look into the resets that happened to @BobG & @chipmonk
@AndyW: Flashing firmware OTA, of necessity, causes a device to reset. I would imagine, therefore, that the Particle cloud can issue specific commands to reset a device. Just to be clear, we are saying that the firmware suddenly executed setup(), without the owner specifically doing anything to make this happen.
Understood - but you did not initiate any such operation, therefore, it should not have happened.
I get that local events (e.g. power loss in the case of the photon, etc) can cause resets, but there should be no gratuitous events from the particle cloud adding to the mix (not saying that’s what’s happening, but these sure are some interesting data points…)
