I’m also having Photon stability issues - just posted here :
Cloud stability and Core / Photon differences
My Photons don’t seem to have problems reconnecting to the network, and I don’t know if they actually lose the WiFi or if the cloud goes down. I’m running 0.4.5.
In 0.4.6, the device will detect if it cannot talk to the cloud and will change the status LED. Do you see any other kind of activity that indicates loop() is still working?
Good question, currently when the weather station is deployed I can’t connect a usb line so I can monitor serial output so the only evidence of loop function is successful data upload. I could add blinking D7 to the loop so when it get’s to the breathing cyan but not uploading or showing up in Build or Dev as online it would indicate if the loop is working. I can visualize the Photon without disassembling the weather station so that might work.I will post my results once the test is completed.
It is certainly possible but I doubt it. Most of the code is from the SparkFun Photon Weather Shield Guide and most of that code has been around for some time in various forms. The only thing I am doing differently is uploading data from all sensors to Weather Underground using the TCP client calls.
@mdma, re: your 0.4.6 comment, can you discuss what will be displayed with the status LED that is different from current indications? I have assumed that sustained fast flashing cyan (connecting to the cloud) is already an indication that a device cannot connect. Is this a misunderstanding on my part? Can you describe the proposed distinction between fast flashing cyan any any new indications? Thanks.
The distinction is that the device can show breathing cyan when it is infact offline. This can happen if the main loop is blocked, so that the system cannot service the cloud connection. When the cloud isn’t sent a regular heartbeat, it will disconnect. The change in 0.4.6 makes it visible that the device is now disconnected by reverting to breathing green until a connection can be re-established.
In a nutshel, it helps ensure the connection status on the LED more closely reflects reality even if the device is stuck in an infinite loop. This is a separate issue to when the device is blinking cyan.
I apologize if I’m threadjacking but I think I’m having a similar problem. I have a Photon that’s running some basic LED blinking code to make sure it runs OK long term. dashboard.particle.io says the device went offline Sep 24th 2015 at 4:58 am (US Pacific) and the CLI ‘particle list’ also shows offline, but the Photon is still happily blinking the LEDs, the Photon status LED breathes blue like normal, it responds to ping, and “particle get (device) (var)” returns valid data (I’m publishing uptime, which I can see increasing on each call, and an analog pin reading of a temp sensor, which seems to be accurate).
I flashed it with 0.4.5 last weekend. It ran for about a day before going offline like above (e.g. reporting offline but seemingly OK) so I rebooted in case it was a fluke. I can reboot again but thought I should check to see if you want me to try anything else first.
Thanks for elaborating on the 0.4.6 status LED indication @mdma, for clarifying breathing vs. blinking cyan … (and for pointing out we may be mingling a couple of different issues here). My line of comments/questioning has been related to those instances of a non-blocking app (Tinker?) where there is a random loss of cloud connection, and failure to auto-reconnect (blinking cyan). (I do realize your last post indicates a different failure mode … one where the app is preventing the re-connect).
I need to learn much more about this, but am assuming that the Photon OS provides the heartbeat, not the app?
(Updating my earlier post, the 0.4.5 Photon I currently have running on the SF Weather Shield, posting to Phant, is still humming along well at 100+ hours now with no disconnects. Longest interval I’ve gone for so far … encouraging).
Just to follow up on my SparkFun Photon Weather Shield and breathing cyan when it is in fact offline. I added a blinking of D7 for one second to the loop just before it updates weather sensor data. It now has been up for about 24 hours without loosing a cloud connection, the longest so far. I will continue to monitor.
That's correct. So long as loop() is being exited, or delay() is called, then the photon can send the heartbeat. With multithreading, the heartbeat will always be sent independently of what the app is doing.
Does that mean there must be a delay() in the loop (or exiting the loop()) currently or is multithreading in place with 0.4.5 or is multithreading part of a future release? If multithreading is not yet in place that might explain why adding a 1 second blink of D7 is allowing my weather shield Photon setup to remain connected to the Cloud. I am now at about 36 hours and two night cycles (it’s solar powered) and it is still blinking and uploading.
Yes. loop() exit or delay() must be called at least every 15 seconds for the cloud connection to remain active.
I did not know that, I bet several others with cloud connection problems aren’t aware of this either. Will multithreading be added at some point in the future? Thanks
@mdma, So with firmware 0.4.6 that was just released I presume with a separate system thread, loop() exit or delay() DOES NOT NEED TO be called at least every 15 seconds for the cloud connection to remain active. Is that correct? Also after updating to 0.4.6 I get a cloud boolean error for alert-it previously worked in earlier firmware versions, code snippets below
"#include “SparkFunMAX17043.h” // Include the SparkFun MAX17043 library
double voltage = 0; // Variable to keep track of LiPo voltage
double soc = 0; // Variable to keep track of LiPo state-of-charge (SOC)
bool alert; // Variable to keep track of whether alert has been triggered
Spark.variable(“voltage”, &voltage, DOUBLE);
Spark.variable(“soc”, &soc, DOUBLE);
Spark.variable(“alert”, &alert, INT);
Perhaps there is a problem now with the SparFunMAX1703 library??
Thanks,
Bill
The problem is that you’re passing a boolean pointer to a function that is expecting an int pointer. The type of the variable is INT and so should be your local variable. change bool to int and the problem will disappear.
As it was, the system would be using 4 bytes for the variable value, yet in RAM the application was only allocating 1. Depending upon the data before and after, you could end up with a very unusual variable value.
The new compiler checks are there to prevent this.
The system threading behavior is described in the docs where you’ll find the answer to your question about maintaining the cloud connection. https://docs.particle.io/reference/firmware/photon/#system-thread
Thanks, makes sense, I had borrowed the offending code from SparkFun’s example on how to use the MAX17043.h and thanks for the link.
As of 0.4.7, I have had this “rapid flashing cyan” situation pop up twice – once in SEMI_AUTOMATIC mode, the other in AUTOMATIC mode. It just sits there forever, only to be fixed by power cycle or reset button. My RSSI was around -71 (not that great), and I have a feeling it just dropped the connection and encountered some kind of block while trying to reconnect.
SYSTEM_THREAD(ENABLED);
STARTUP(System.enableFeature(FEATURE_RETAINED_MEMORY);
TCPClient (to send data to Weather Underground) that currently does not check the wifi or cloud status before trying to establish its own connection, maybe I should change that. I do have code that kills any existing connection to WU if it takes longer than 5s to receive a reply, but I don’t think my application would be getting to that point if a connection failed to establish in the first place.Is this still considered to be a system firmware issue (getting stuck on fast-flashing cyan)?
(ping @mdma for good measure)
Apparently I was incorrect. The first time that this happened after installing 0.4.7, the device locked up rapid-flashing cyan as described above. Now that I’ve had a chance to come home and look at the state of the Photon after its second lock-up, it looks as though this time it was a rapid-flashing-green lockup, if that means anything.
Thanks for the update! The color change really helps.
I will look to add measures to detect these long wait times and try to kick start the system to reconnect.
The fast flashing green means it’s trying to resolve an address with the AP. These are things outside of our direct control, but we can at list detect it’s taking a while and try to kick start the Wifi subsystem! 