My Photon is running in Manual System Mode because I do not want to be cloud connected al of the time.
The application connects autonomously once every hour to the cloud and then remains connected for about 40 seconds.
Apart from that I can make a manual connecting to the cloud when needed.
For connecting to the cloud (either manually or from whitin the application) I use a rather simple mechanism: I generate a System.reset () and then the first thing in the loop() is connect to the cloud. The connection is shut down simply by WiFi.off(), either as a part of the automatic procedure or of the manual procedure.
The part of my application that doesnot need the cloudconnection runs fine always. The part that requires cloud connection however shows occasionally a strange behaviour, not permanently, but a few times per day:
the status LED is first breathing cyan most of the time (which is good), but two strange things may also accur after some time:
the LED is turns into solid Cyan and the system does not respond to any attempt to interact over the cloud through Particle console: the system is blocked.
while breathing cyan, the LED all of a sudden starts blinking cyan very fast (as if it is losing connection) and then starts breathing cyan again and the system is acting normal again.
I have a feeling that both faulty situations might have to do with the same underlying problem, although they never occur simultaneously (as you could conclude from the description above).
In an attempt to analyse what is wrong I have been switching off parts of the application successively, I have been limiting the number of Particle functions and variables, I have been liiting the number of retained variables , etc, but all with no clear indication of where things might go wrong.
Does anybody has a good idea of how to tackle this issue in a more structured way, because my trial and error does not seem to bring me any further?
Further to what I wrote yesterday:
When the status LED is SOLID CYAN and I do a system reset, he device seems at first to start up normally, (i.e. the LED then starts breathing cyan again), however, the system does not react on any Particle function or Particle variable request when using the console…
There is only one way to get the system out of this faulty state and that is by putting the system in safe-mode and then do a reset again.
Again, as I said yesterday: the system only blocks the cloudconnection part of my application. There is piece of code that doesnot require any interaction with the cloud and that is performing correctly even though the status LED is solid cyan.
I am not sure whether I will be able to help, but let’s see.
Without having seen your code, my suspicion in SYSTEM_MODE(MANUAL); is the likely culprit. Running in this mode, you not only have to make sure you call Particle.Connect(); at the appropriate times, but also Particle.process(); every time you need to device do actually do what your code told it to do. Failing to do this can have all sorts of intermitted errors as a result.
My advice (without knowing to much about your code) is always start with SYSTEM_MODE(SEMI_AUTOMATIC);especially if the only reason for not running the automatic mode is the fact that you want to manipulate being connected or not.
Thanks for your help!
I’ve tried your suggestion, but that in itsself didn’t help much because in my code I am using both Particle. connect() and Particle.process. However: you’re right: there is no reason in my code not to go for the semi-automatic mode, so I’ve changed that.
What’s more: based on my observations that the non-cloud related part of my code runs well and I only see strange things while being connected to the cloud (or being in the process of getting connected), I now only use the Particle.console for interacting with the device.
Before that, I used both the console AND a webpage that I wrote myself (with a number of GET’s and POST’s).
The device seemed to act correct then.
As a next step, I’ve changed the webpage in such a way that the POST’s are only executed when de device actually shows that it is connected to the cloud.
That also seems to work fine now!
I do not know enough about how these POST’s are handled, but it looks like when the webpage attempts to send POST’s to the device while the latter is not connected yet, the attempts of the device to communicate with Particle Cloud, once it is activated from the loop, results in the disturbances I have described earlier.
Do you know if that would be a valid reasoning?
I’d appreciate your comment!
I am sorry it did not help. Running SYSTEM_MODE(SEMI_AUTOMATIC); there should be no need in include any Particle.process(); calls as this is all handled automatically. It will however run void loop(); even if not connected to Particle cloud.
If the Photon behaves inconsistently and you can narrow it down to when the website is posting to the device (and when device is no connected) if sounds to me like for some reason something is then calling the device to connect, not sure how as the device should in essence "not know" anything about the post as it is not connected??? Unless of course your post from the website is using an interrupt for example to then wake the device to receive the post?
I would think, and it might be my preference only, that before anything posts to another device, it should check for connection first and receive confirmation as apposed to 'fire and forget', but as I said, this might be my preference only
I hope some more experienced guys can jump in and shed more light, but suspect they might want to see your code
Yes no sorry, I got that. From what I understand you sometimes have data being pushed from your website to the device correct?
It is these instances that I am trying to figure out. What is throwing me at the moment is why it is seemingly waking up your device if this was not intended from the start So if it was me, I would approach the comms this way:
1.Website checks device status
2.Device is awake and acknowledges
3 Website receives handshake
4.Website sends data
of course the opposite will be:
1.Website checks device status
2.Device is sleeping
3 Website does not complete handshake
4.Website holds on sending data
If it was me, I would approach like this.
1.Website checks device status
– 2a.Device is awake and acknowledges
– 2b.Device is sleeping. Website does not receive response. Website wakes up device.
3 Website receives handshake
4.Website sends data
My understanding is that IF the device is indeed connected at the time of receiving data, then there is no problem? My logic then tells me to:
Either
not send data if you know the device is sleeping Or
Wake device up, wait for confirmation and then send data.
So if it was me, I would approach the comms this way: