last_heard stale in device list?

Troubleshooting
1

I’m working on a webapp to control a bunch of photons and it seems that the last_heard field doesn’t match when getting the device list vs the device directly. The following two blocks were fetched within seconds of each other and while the direct details last_heard in the single device request is updated very frequently (every second or less) the last_heard field in the list appears to be when the device was last rebooted?

List contents: https://api.particle.io/v1/devices?access_token=...

[
  {
    "id": "18002....",
    "name": "ac-controller-living",
    "last_app": null,
    "last_ip_address": "50.46.123.224",
    "last_heard": "2015-08-04T08:41:32.915Z",
    "product_id": 6,
    "connected": true
  }
]

Device contents: https://api.particle.io/v1/devices/18002...?access_token=...

{
  "id": "18002....",
  "name": "ac-controller-living",
  "connected": true,
  "variables": {
    "status": "string",
    "data": "string"
  },
  "functions": [
    "sendNEC",
    "setAcModel",
    "setState"
  ],
  "cc3000_patch_version": "wl0: Nov  7 2014 16:03:45 version 5.90.230.12 FWID 01-2f845efd",
  "product_id": 6,
  "last_heard": "2015-08-04T21:18:28.113Z"
}
2

Hi @edalquist,

Good question! There are some spots in the API that were built very quickly during the push after our first kickstarter, but they haven’t been revisited recently, and remain a little inconsistent. :\ In this case, “last_heard” should only be returned on the device attributes endpoint /v1/devices/your_device, and not on others, because this is the place where that information is available. On that endpoint, last_heard corresponds to the last_ping we heard from the device in question.

I love bug reports like this, I’ll add this to the backlog to be fixed. Ideally I’d love to just drop those attributes from endpoints where they don’t make sense, but I want to be careful not to break any apps that depend on them.

I hope that helps!

Thanks,
David

1 Like
3

Thanks for the quick answer! I’ll stop using “last_heard” from the device list then. You do have that /v1/ in your URI for a reason, you could push out v1.1 and remove the deprecated fields :smile:

Also since last_heard isn’t reliable in the device list maybe just set it to the unix epoch for v1? Then it would at least be less confusing when trolling through the REST APIs.

I’m glad the report was useful, after doing software development for long enough (especially OSS dev) the value of reproducible reports with examples sinks in.

2 Likes
4

I looked at updating the docs but I can’t figure out where the API details are getting defined: https://github.com/spark/docs/issues/105