Checking if Core is online and API return codes

[Iv4n]

Hey guys,

I have been trying to find a way to check whether a core is online at a specific moment (not scheduled), I did find a workaround, but the documentation says that it would return 404 if the CORE is not connected to the cloud but with the API calls I have only received it if an ONLINE core does not have the requested function. In addition, the API is returning codes which I believe do not make sense nor are very consistent.

Offline core:
GET devices/{deviceid}/variable: 408 Timeout: {“error”: “Timed out.”}

POST devices/{deviceid}/function: 200 OK: {“error”: “Timed out.”}

GET /devices/{deviceid}: 200 OK: {“id”: “{deviceid}”,“name”: “Spark core”,“variables”: null,“functions”: null}

Online core:
GET devices/{deviceid}/variable: 200 OK: {“cmd”: “VarReturn”,“name”: “test”,“error”: “Variable not found”,“coreInfo”: {“last_app”: “”,“last_heard”: “2014-02-10T15:29:19.534Z”,“connected”: true,“deviceID”: “{deviceid}”}}

POST devices/{deviceid}/function: 404 Not Found: {error: “Function not found”}

GET /devices/{deviceid}: 200 OK: {“id”: “{deviceid}”,“name”: “Spark core”,“variables”: null,“functions”: null}

^^^^^ Last one could change if any variable or functions are exposed.

Yes, I could create a function and check for the “connected: true” part, but there are some problems with this:

• I have to send an already existing exposed function which I have to know before hand (which might change from core to core) and have to code it so it’s ignored because it’s just an online check and I want no action to be done.
• I can expose a brand new function just to return 1 which effectively would reduce my exposed functions by 1 and of course, have to take the time to put it every time.

I guess meanwhile I could try sending a GET variable or POST function and check the Json for timeout.

My recommendations for the spark team:

• I believe it would be awesome to have the “connected: {state}” in the GET /devices/{deviceid}
• If possible have the last_heard in the GET /devices/{deviceid} as well (in case this is saved after the core is disconnected)
• Return 404 (or 408?) in GET /devices/{deviceid} if core is offline
• Return a consistent code of 408 or 404 when doing /variable and /function on offline cores
• Return 400 on a non exposed /variable and /function

Thanks for your time and for reading my post!

[Dave]

Hi @Iv4n,

Hmm, the device info endpoint should have a ‘connected’ property. I’m adding that back in, and it should be included in our next code push. I’ve been trying to avoid returning 404’s when the core is actually configured for that user. We return 404 when a user hits a core they don’t own / isn’t claimed. You’re right in that the API should be as consistent as possible, and that’s something we’ll converge towards definitely. We want to make sure we don’t break any existing apps (mobile, web, etc), so these changes might start appearing when we start v2.

You can get a list of all your cores and their connected status by hitting your devices endpoint:

https://api.spark.io/v1/devices?access_token=your_access_token

You can also hit the attributes endpoint for your core, and see the connected status there:

https://api.spark.io/v1/devices/your_core_id/?access_token=your_access_token

Thank you!
David

[sarvagyavaish]

I get connected ‘true’ even if my core is offline. What is the proper way to check if a core is online?

Here’s the command i executed while my core was powered off:
curl https://api.spark.io/v1/devices/DEVICE_ID?access_token=ACCESS_TOKEN

and here’s the result
{
“id”: “DEVICE_ID”,
“name”: “CORE_NAME”,
“connected”: true,
“variables”: [],
“functions”: [],
“cc3000_patch_version”: “1.29”
}

[Dave]

Hi @sarvagyavaish,

That property can have a half life of something like 10 minutes when a core connection is suddenly dropped / isn’t cleaned up properly. I’m working on fixing this, but you can always try something like grabbing a variable from your core / calling a function if you need to be 100% certain your core is online. Sorry about any confusion that caused!

Thanks,
David

[b3ko]

Hi @Dave,
I am having the same issue where the battery dies on my core but it still says it is online.
Since the core can go offline without me knowing i am checking if it is online first and then proceeding if it is. however 10 minutes is a long time and was hoping this would be fixed soon.

I saw your comment:

I'm working on fixing this

how is that going? have you identified a fix and if so do you know when it will go live?

If it won't be fixed soon is there a function i can call to flush the cache or something?

thanks for any info.

best,
jon

[Dave]

Hi @b3ko,

There are a few ways we could make the resolution a bit clearer on cores being online / offline. I had a project in the works recently, but had to delay it a bit. Ultimately it relates to how the socket is cleaned up by your core when it goes offline. If the socket is closed cleanly, the server will know the core is offline immediately, but if not it waits for the socket to time out.

What if I include the last ping time from your core in the device status API calls, so even if the API says it’s online and is wrong, you’ll get a timestamp of the last time your core pinged, so you can tune your own logic to say something like: “If my core hasn’t pinged in 10-30 seconds, then it’s offline even if the server says otherwise”

Thoughts? That way I can add enough information that you can get your desired behavior without adding any restrictions / assumptions to other people’s use case.

Thanks,
David

[uChobby]

I’ve been playing with making the devices/ calls, getting status back for a core showing whether it’s connected or not.

when the core is active, I get a quick response showing connected=true, when the core is offline, the response takes a very long time but eventually, after a few cups of coffee :> comes back connected=false.

Please fix this. Ideally the response is quick in either case. If the core is online, then the full response. If the core is offline, a response with just connected=false is fine. Just don’t make us wait.

[Dave]

Hi @uChobby,

Good question! There are two types of ‘online’ checks that the API will make, one is quick, and one is slow:

If you call the “List devices” endpoint, you’ll get a fast timeout of about 2 seconds:

#fast online check
GET /v1/devices

If you call the get device attributes endpoint, the api will wait for your core to reply with details about what variables and functions are registered. I’m working on reducing this delay as much as possible, but right now that could mean the api waits up to 30 seconds for a reply back from your core.

#slower attributes check
GET /v1/devices/your_core_id

There is currently a private event when your cores come online, and I’m working on adding an event for when the core goes offline, but this will have a lag time of about 60-90 seconds depending on if your core disconnects cleanly or not.

I hope that helps!

Thanks,
David

[uChobby]

Aw… so if we do a clean disconnect the response will be quick and accurate. That works fine for me. Is there anything special that we need to do in the firmware when we go to sleep to signal cleanly?

I have not tried this yet…

[Dave]

Hi @uChobby,

I suspect if you’re using semi_automatic / manual modes, you can call Spark.disconnect() - http://docs.spark.io/firmware/#spark-disconnect

Thanks,
David