Apparently the Photon should re-connect to the cloud after it looses connection, but it never has for me. I have 6 sending temp. data to UBIDOTS. Every now and then one will start breathing green and will never recover until I press reset. I know cloud is fine because other 5 are still sending data.
https://docs.particle.io/guide/getting-started/modes/photon/#cloud-not-connected
Breathing green happens when the connection to the cloud is blocked for more than ten seconds. In all likeliness, something in your code is blocking the Photon from connecting.
It works for days at a time before dis-connecting. Should it not reconnect by itself when the cloud is available again ?
It should (and usually does) unless something interferes with it - and we’ve seen this most the time caused by application code.
How does your code look like?
void loop() {
sensor.requestTemperatures();
delay(1000);
float temperature = sensor.getTempCByIndex( 0 );
if (temperature > -40 ) { // only send if good temp.
ubidots.add(“Core”, temperature);
ubidots.sendAll();
}
delay(59000);
}
As a safeguard to help troubleshoot, you could add Particle.connect() at the top of your loop. It’s quick. and does nothing if the cloud is already connected.
I don’t think this is the cause, but takes out one possible source of confusion.
My guess is that the ubidots networking is hanging for some reason, blocking the loop.
You could use the ApplicationWatchdog class to shutdown wifi and bring it up again if it detects that the application loop has hung for more than (say) 90 seconds.
I’m not too concerned that the cloud connection is droping but that is not re-connecting. 5 other Photon’s continue sending data while one is breathing green and it never re-connects (waited over 24 hrs before reset).
I will add any code you recommend but need an example. I don’t know what you mean by “ApplicationWatchdog”.
Had one breathing blue (WI-FI MODULE NOT CONNECTED) today but connected right away after RESET.
Used PhotonWdgs to set a watchdog timer. Had 3 restarts so far. Not sure how that helps debug but I guess it proves the code is freezing and it keeps the data flowing. My next step is removing the part that sends data to UBIDOTS I guess to see if thats the problem ?
UBIDOTS is causing the issue, added some code to publish the time the call to UBIDOTS takes. Averaging around .3 Sec.
1 Like
Using threaded mode can allow the application to block and not disrupt the connection to the cloud.
If there is a minimum test case to reproduce the issue, please let me have it and I will investigate.
indent preformatted text by 4 spaces
(Just wrap your code in a block of this)
```cpp
// your code
```cpp
#include "SparkIntervalTimer/SparkIntervalTimer.h"
#include "photon-wdgs/photon-wdgs.h"
#include "Ubidots/Ubidots.h"
#include "OneWire/OneWire.h"
#include "spark-dallas-temperature/spark-dallas-temperature.h"
#define ONE_WIRE_BUS D2
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensor(&oneWire);
#define TOKEN "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
#define DATASOURCE_NAME "Hottub"
Ubidots ubidots(TOKEN);
int send_data_ind;
Timer timer1(60000, send_temp);
void setup() {
sensor.begin();
timer1.start();
ubidots.setDatasourceName(DATASOURCE_NAME);
PhotonWdgs::begin(true,true,60000,TIMER7); // set watchdog timer to 60 Sec.
}
void send_temp() {
send_data_ind = 1;
}
void loop() {
PhotonWdgs::tickle(); // reset watchdog timer
if (send_data_ind > 0) {
sensor.requestTemperatures();
delay(1000);
float temperature = sensor.getTempCByIndex( 0 );
if (temperature > -60 ) { // only send if good temp.
ubidots.add("Water", temperature);
ubidots.sendAll();
send_data_ind = 0; // data sent, reset indicator
}
}
delay(1000);
}
This seems to work now. I had all the code in send_data() proc called by Timer1 and nothing in the main loop. Then I read how timer code is like interrupt code and should not block so I moved it all to the main loop. It’s been running over 24hrs with no reset. It was resetting every few hours before and the temp. was -127 50% of the time.
I spook to soon. Now in the past hour I’ve had several re-boots.
Also since I added the watchdog I can no longer flash the Photon without physically putting it into safe mode.
Thanks for posting your code. But is that really a minimal test case? How about removing the watchdog, and the sensor, and instead just publish dummy sensor values to ubidots?
If the hardware isn’t contributing to the problem it’s best to exclude it from the test to reduce the number of variables that we’d need to investigate.
By the way, the send_data_ind value is accessed by multiple threads - the timer thread, and the main application thread, and so it should be declared volatile.
Hey ron how are you?
Well I discover a problem last week that was preventing the Ubidots library from reconnecting and fixed it. Please upgrade your Ubidots library to version 2.0.3. To upgrade the library click on the “i” icon and select the latest version
The problem was a infinite loop in the sendAll function of Ubidots, sorry for that my friend, by the way if you have more suggestion tell me and i will do it fastly
1 Like
added volatile (is there anywhere I can read more about that ?) and removed all the Temperature stuff to c if it still restarts, I will also try updated ubidots lib on other Photon.
Thanks, will try that now.
Yes, you could search this forum or google - volatile is a standard C modifier, so you will find plenty in the net.
Nice tell me when you try it