[quote=“mdma, post:25, topic:15121, full:true”]If you can still call functions, then the device isn’t really offline, even though the cloud says it is. OTA updates should still work also. cc: @Dave
I guess that’s what I’m trying to say - the device lists as offline on the Web IDE, CLI, Android API, and everywhere else, even though I can OTA, call functions, monitor variables, etc. The main headache is the android API because it throws exceptions when trying to call functions on an offline device, checked real-time.
Thanks, I definitely don’t want to lump these things together if they aren’t related. My user code is humming along, so intensely in fact (pushing data out as fast as possible over SPI) that it’s almost never not doing something.
Looking at the actual SPI transfer functions, there is a call to __disable_irq(); immediately prior to the data transfer, followed by an __enable_irq(); This is getting called very frequently, transferring 300 LEDs worth of data over WS2812. Might this be affecting the background Photon processes?
I might add some kind of heartbeat event just to test the ability to publish data.
One more data point - publishing events is unreliable from both the Core and Photon. “Status” events are transmitted every 5 seconds, but only appear to make it to the cloud every 10-30s from either… Dashboard shows 2 events from the Core for every 1 from the photon… and then the photon goes offline and stops sending the events.
However, using CLI to “monitor” a variable on each system in a 5 second loop results in more consistent event publishing and neither system showing offline. Going on an hour now with both listed online as expected.
(edit: typo - both systems are still online, somehow external polling keeps the cloud on life support)
Hey dave… I resolved the problem as you suggested. I cam cup with a little trick as well that was not documented. I would document this trick ( which I kind of forget how to do but can review notes ) if I was confident that you have more issues like this out there in the field. If there are no devices with old firmware out there, then probably not worth the effort.
I am submitting more questions if you get a chance to look at them… basically, I want to see if I can add an RFID reader and a GPS. any samples. Any examples for mifare tags?
I am also interested in distance data for WiFi… and if I can increase the distance. Ideally, I do not mind a slow network but I would like to get a mile or half mile transmit receive… even if I have to add an antenna.
Make sure you’re calling Particle.process enough if you’re not running in automatic mode. The online / offline state changes based on if your device is responding to pings from the cloud, but the cloud will still try to send commands anyway in the event that isn’t working to help recover from this kind of scenario.
Not being able to OTA is no indicator for being offline either.
If your application firmware starves the cloud tasks of processing time you are technically still online but not responsive enough to perform a successful OTA update or other tasks while other online tasks (like variable retrieval or publish) might still work.
That’s an interesting observation @ScruffR. I’m seeing similar behavior like @trackdork in several Photons of mine. I’m running SYSTEM_THREAD(ENABLED), and I’m explicitly casting SYSTEM_MODE(AUTOMATIC). Even though it’s technically not necessary to call Particle.process() when you’re running automatic system mode, I’m still calling Particle.process() periodically throughout my loop application in an attempt to keep the cloud connection up to date. I’m always able to re-flash firmware to these Photons when they exhibit this strange behavior, but I dislike the idea of manually resetting the Photon to re-establish full connection to the cloud. I use Mobicle (made by Control Everything) as a platform to publish events, monitor variables, and observe system status of my Photons; when the Photon is in this cloud connection limbo state, I can’t access any of the Photons in the Mobicle app. I know that Particle isn’t responsible for 3rd party integrations like Mobicle, but I’d thought I’d mention as it’s pertinent to this issue.
Aside from manually pinging the cloud with Particle.process(), do you know of any tips to maintain full connection to the cloud?