I have made 7 word clocks running the same software based on the particle photon. Three are running in the Netherlands whereas the other four are in Switzerland. They were all running fine for several months. The clocks call Particle.syncTime() once an hour and send data to the Blynk server every 5 seconds. I have SYSTEM_THREAD(ENABLED).
During the last few days all 3 clocks in NL stopped running at least once whereas the 4 in CH are still running without issues. Yesterday evening I updated all 7 clocks to 0.5.3 with the same result: NL clocks stopped responding during the day and the CH clocks keep running.
Since the photon is inside the clock (and I’m in CH) I don’t know the LED blinking pattern but they start again after unplugging the power for a few seconds.
I checked the status (http://status.particle.io) and it seems that the latency was much higher than normal at the times the NL clocks stopped responding. No idea if this is related and/or why this is not affecting the photons in CH…
I was wondering if people had similar issues during the last few days or if someone has an idea what could cause this behaviour.
@ScruffR Thanks! I did not use WiFi.ready for any cloud calls and will give it a try.
This morning my own clock was not responding and the photon was flashing cyan. I restarted my wifi router and it went to flashing green so it seems it couldn’t connect to wifi. After unplugging the photon for a few seconds it started as usual again.
Is there a possibility that my code is preventing cloud/wifi re-connection when I have system thread enabled?
I think that Blynk and/or other things trying to use WiFi while it’s not connected will interfere with the reconnect.
I’ve also noticed that the Blynk app might hammer the device when you got widgets that pull data from your device interfering with OTA flashing in SYSTEM_THREAD(ENABLED).
So best is to prevent any of these from happening while not fully connected.