Data Storage Device ID Query Not Working

Hello. I currently have a device that is sending data to TTN data storage. I can successfully use the first 2 endpoints discussed here to get a list of device IDs (my 1 device shows up) as well as the second endpoint for getting data. But when I attempt to query by a specific device using the 3rd endpoint, (/api/v2/query/{device-id}) I get a 204 (No Content) back. I am using the device ID returned by the first endpoint.

Does anyone know why my device ID isn’t producing any responses. I also curl’d it myself and got the same no content response.

Thanks in advance for any help.

HI ya.

I’ve just done a little test on my own swagger console and my Node-Red implementation, the query you want is
https://xxxxxxxx.data.thethingsnetwork.org/api/v2/query/device_id?last=7d

For device_id, use the device ID as returned by device query with no brackets or otherwise.

One thing i have found is that if I use Swagger, you can see the query it has used when it responds

Did you receive any uplinks in the past hour? (Assuming the integration was enabled at the time the uplinks were received.)

If you’re using a Decoder in TTN Console, then beware that the Data Storage Integration silently fails for attributes with null values.

Indeed, that may surely help. The default is 1 hour.

Asides: note that a non-existing device ID will return 204 No Content too (if it does adhere to the naming rules). And note that the integration will store at most 7 days of data. There may also be some limit for the maximum number of results, but one should not run into that when adhering to the Fair Access Policy.

Hey Matt!
Thanks for your response. I am using the same query you suggested using the device ID returned by the device query with last=7d and am still not getting any response but I appreciate you trying that out on your implementation!

Hey Arjan,

I confirmed that I am indeed receiving uplinks using the api/v2/query endpoint provided by the swagger tool for the last hour. But right after I run that query and try the api/v2/query/{device-id} endpoint, I get no response for 1h or 7d. Thanks again for the help!

Does anyone have any possible suggestions to address my issue? I am getting uplink when I hit the endpoint that includes all devices but when I hit the endpoint for a specific device, I get a ‘no content’ response.

What relevant output do you see when getting data for all devices, and which curl command are you then using to query for a single one? (You can redact/hide the access key.)

(To format that output, see also How do I format my forum post? [HowTo])

I have a test application in the office that uses Data Storage as it’s primary retrieval means, it calculates the timespan relative to its last retrieve so I know this works. As I use a calculation, I always request a number of seconds, so you may want to try 3600s or 604800s

Usually I find people (clients) get a 204 when the device id isn’t quite right.

In the first instance, can you COPY and paste what you are using, then change the key AND tell us what environment you are using - OS, programming language etc

And whilst we are looking at that, can you confirm you have tried using the Swagger online tool linked from the integration for testing? If you go in to the Data Storage integration there is a link called “go to platform”

This is working for me:

https://descartes-room-monitor.data.thethingsnetwork.org/api/v2/query/descartes-tt-outdoor?last=1h

as does this:

curl -X GET --header 'Accept: application/json' --header 'Authorization: key ttn-account-v2.UxRAbhp0NFcfCW3Ye61BDbeyYSXu-RS2F3okEBfiwFw' 'https://descartes-room-monitor.data.thethingsnetwork.org/api/v2/query/descartes-tt-outdoor?last=1h'

It’s the multi-level temp sensor outside the office. I’ll revoke the key once you’ve confirmed it gives you some data back.

Hey Nick, thanks responding. I can confirm I have been using the Swagger online tool, which provided me with the curl command for a device with ID dl-pr26_5100

curl -X GET --header 'Accept: application/json' --header 'Authorization: key xxx' 'https://ruchir_dl-pr-26_5100.data.thethingsnetwork.org/api/v2/query/dl-pr26_5100'

This is the command that is currently producing a 204. Even though this curl

curl -X GET --header 'Accept: application/json' --header 'Authorization: key xxx' 'https://ruchir_dl-pr-26_5100.data.thethingsnetwork.org/api/v2/query'

produces a response similar to this:

[
  {
    "battery_voltage": "map[value:2.744 displayName:Battery voltage unit:V]",
    "device_id": 5100,
    "device_id_1": "dl-pr26_5100",
    "pressure": "map[displayName:Pressure unit:bar value:0.030670166015625]",
    "protocol_version": 2,
    "raw": "AhPsAAND7VJFCrg=",
    "temperature": "map[displayName:Temperature unit:°C value:14.615625000000009]",
    "time": "2020-10-15T12:49:46.585897243Z"
  },
]

I have also confirmed that your test example is working for me when I try it. You can revoke your key. Thanks!

Hello Arjan my response to Nick details the curl commands and outputs you asked for. Thanks!

That’s weird. Any chance your payload format decoder is outputting an attribute called device_id? Or, if that is actually outputting device_id_1, then it seems the device id in TTN Console is simply 5100? What if you use 5100 in the URL?

I concur - perhaps it would be useful for you to try:

https://ruchir_dl-pr-26_5100.data.thethingsnetwork.org/api/v2/devices

to get a list of devices as nature & TTN see them.

And/or create a read only key like I did and let one of us try it out for you.

And show us your decoder!

Running https://ruchir_dl-pr-26_5100.data.thethingsnetwork.org/api/v2/devices produces the following response

[
  "dl-pr26_5100"
]

Using device id 5100 with endpoint https://ruchir_dl-pr-26_5100.data.thethingsnetwork.org/api/v2/query/5100

produces the same 204, no content response

I currently do not have access to the console and decoder, but am working closely with someone who does and will try to get that information ASAP.

Thanks!

If you do a compare and contrast, you’ll notice that the prefix to the url is the application id and the device id is at the end.

https://descartes-room-monitor.data.thethingsnetwork.org/api/v2/query/descartes-tt-outdoor?last=1h

So descartes-room-monitor is the application id and descartes-tt-outdoor is the device id

So for this:

https://ruchir_dl-pr-26_5100.data.thethingsnetwork.org/api/v2/query/5100

I can’t tell if ruchir_dl-pr-26_5100 is some very specific application name or a combination but it definitely fails my sniff test.

And 5100 is clearly wrong, it should be dl-pr26_5100

PS, if you follow the go to platform link from the integration, it would setup most of this in Swagger, all you have to do is hit the authenticate button and add your key.

Hey Nick,

I have been using an authenticated Swagger to produce the responses that I shared. The application ID is indeed ruchir_dl-pr-26_5100.

So that’s one half sorted.

How about testing it with the id that TTN uses:

You could also use the access key you’ve got for the Storage Integration, to subscribe to the uplink data using an MQTT client. That will show you what is in the JSON attribute payload_fields. (And I’m quite sure you’ll see a field device_id that confuses the Data Storage query.)

Like with Mosquitto on a Mac, if you’re in EU868:

mosquitto_sub -v -h eu.thethings.network -t '#' -u ruchir_dl-pr-26_5100 -P ttn-account-v2.your-access-key

Hey Arjan, I used your example to setup an MQTT client. When I use your command and my access

the program waits without receiving any uplink data even though the sensor sends data every 10 minutes. I confirmed with the Swagger UI that data is still being sent for the sensor. Do I have to update the topic field of the command to something other than -t '#'? I’m currently trying to get access to the console to look at the decoder as well. Thanks!

Using 5100 also produces the same not content response

That # is a wildcard that will show you all messages. So no, no change needed for that. I cannot explain why it doesn’t work; it really should work the correct application id and access key, assuming you’re using EU868. If not, then the server name needs changing too.