Flashing green and not breathing cyan again if not restarted [Solved]

Dear all,

I recently letft my core up and running all night and the morning after it was flashing green. The only solution was to restart it to make it breathing cyan again.

So I decided to setup some sort of monitoring system to check whenever the Core is online or not with a little script that connects to https://api.spark.io/v1/devices/CORE_ID/?access_token=TOKEN and parses the response checking if the boolean “connected” is true. This an example of response I parse:

{
  "id": "CODE_ID",
  "name": "Name",
  "connected": true,
  "variables": {
    "var1": "string"
  },
  "functions": [
    "func1",
    "func2"
  ],
  "cc3000_patch_version": "1.28"
}

Note: BTW this is not “real time” updated value, so the best is to directly query a variable (https://api.spark.io/v1/devices/CORE_ID/var1?access_token=TOKEN). If offline the response is: "error": "Timed out."*
Note 2: Core does not respond to ping (CC3000 firmware?)

Basically what I discovered is that at 5am my internet connection drops (for probably 1 min, alarm system check), the Core is wi-fi connected to the AP and starts flashing green, but for some reason when my modem connects back again, the core does not start breathing cyan as supposed to.

I did some tests simulating the disconnection unplugging the telephone cable form the modem and plugging back after a short and long times and as soon as the connection is established, after a while the Core breaths cyan again.

On top on this, at 5am another script executes func1 (via curl) and after 10 sec it reads the result of var1 but both fails curl: (6) Couldn't resolve host 'api.spark.io' so I don’t think these requests even arrive to spark nor have an impact to the Core. Anyway I will schedule this script to run after and see what happens.

Do you have any suggestions or ideas?
Thank you,
dk

Solved.
I scheduled the request 5 min later and the issue in the last 3 days did not repeated.

2 Likes

Hi @d82k,

Just to double-check, did you run a deep-update on this core? That can be helpful if it hasn’t been run yet, especially on busy wifi networks. If you’re interested, you could jump into manual, or semi-auto mode and manage the connection more closely ( http://docs.spark.io/firmware/#advanced-system-modes ), or sometimes I’ve seen projects that just full out System.reset() ( http://docs.spark.io/firmware/#system-reset ) the core after some time, or if it gets lonely.

I hope that helps! :slight_smile:

Thanks,
David

Dear @Dave, thank you for your reply.
I was not considering a deep update since the version of the patch of CC3000 is 1.28 do you think I might benefit anywhay from it?
Thanks for the link on the advanced system modes, I missed it, very interesting.
Yes my other alternative would have been to schedule some sort of system reset in the loop such as: if Time.hour()) == 12 and running time > 1h, than reset so that if the core is running for more than hour and it is midday it reset otherwise it keeps running.
How to I understand instead if he is not connecting since long time?
Thank you
dk

Hi @d82k,

Hmm, maybe I was reading too quickly, and I suspect I misunderstood. I think more recent firmware versions (not cc3000 versions), are better about restarting the core / radio if it can’t get online, but it sounds like you’re in a different scenario. You have wifi, but your internet disappears for a while, and your core gives up connecting to the cloud. It sounds like maybe the normal connection handling code might give up. If you did manual mode, I’m guessing you could be more assertive about getting back online. :slight_smile:

Thanks,
David