I am using electron to publish data to particle cloud every one second (using Particle.publish) based on switch input.
I notice that the Electron stops operation i.e the code stops executing when the electron tries to re-establish connection with cellular network (following connection loss).
How can I ensure that the code in the electron keeps executing even when the electron tries to re-establish the connection with the cellular network.
SYSTEM_THREAD(ENABLED) & SYSTEM_MODE() are the keywords to look up in that regard
@ScruffR, Thankyou.
I’ve added the below lines of code before setup.
SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(SEMI_AUTOMATIC);
and called Particle.connect(); in setup.
Tried few times, the code stops executing when electron tries to re-establish the connection with cellular network, i.e did not solve my problem.
PS: I removed the antenna to simulate lost connection
It seems that cellular connection comes with some inevitable blocking, but with the above settings the blocking period should be cut shorter quite a bit.
With the below settings, we still lost 20s worth of logging time i.e. about 20 events:
SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(SEMI_AUTOMATIC);
Is there ANYWAY we could keep running the logic, when the network connectivity drops ? As we are logging data, it becomes paramount for us to track all the events. If we loose a few events, the rest of the data is not useful, because every event depends on the previously logged event.
Or should we have a Photon running the logic all the time and use the Electron just for publishing the measured data. In this case there are many issues like:
Any suggestions and ideas would be appreciated.
The issue should not be the dropping of the connection, with SEMI_AUTOMATIC and SYSTEM_THREAD your code should keep running, only the (auto)reconnect would block your code.
I'm not sure if the reconnect is happening automatically after a connection drop and if so how to prevent that.
I'd have to test that situation. But I wouldn't keep pulling the uFL connector for that. These connectors are not meant for frequent mangling 
I would like the code to run even when the Electron tries to reconnect. i.e. in my application the code needs to run 24/7, since it needs to listen to a device without any interruption.
Is this possible to achieve using the electron ?
I understand that SYSTEM_THREAD is a beta feature, do you know when this feature will be out of Beta phase for reliable operation ?
PS:
Does the photon also stop running the code while trying to reconnect to the Wifi ?
Not anymore AFAIK, the docs might just lag a bit behind there
That depends what you understand when you say "stop running"
Neither of the devices stop running during reconnection, they are just occupied by other tasks, leaving less time to attend to other tasks.
Just as your own code doesn't stop the device running when you call delay() or have a tight blocking loop.
If you have time critical tasks, can you do them in an interrupt service routine?
BTW, if you say
Doesn't that require an active cloud connection and hence you will not be able to publish or receive any data while disconnected anyway?
Thankyou, this solved my issue.
Am I correct to assume that an interrupt will 'interrupt' every other type of block.
e.g.
attachInterrupt(D1, manualOn, RISING);
Would let it bypass every other blocking code, connects, reconnects etc?
Thanks
Lets say most types of other blocks.
Interrupts have priorities, and a lower priority interrupt cannot preempt any higher priority interrupt, but normal non-interrupt code can be interrupted any time (unless marked as ATOMIC_BLOCK).
But you need to consider that due to their forceful nature ISRs have to be light weight and aren’t allowed to do everything.
Can you now use a software timer? From my testing these seem to run while the Cell network is dropping and trying to reconnect.
I am using these timers to control my program flow instead of adding code to the loop function. This may not be the best approach but seems to work for me.