You mention that people should cache the results when they query the API.
→ Would it be possible to add an ETag header in the HTTP response?
This way a client cache can verify if certain data/content has changed without overloading the API by doing a simple HEAD request and not af full GET request.
Hiya, this works nicely for the community edition, but I can’t get it working for our private instance. I assumed I just needed to change tenantID from ttn to our instance name, but that just returns an empty array. Is there some kind of authentication step I am missing?
Many thanks
Hi Johan. I have the same problem with my gateway. Also not on community edition, but the free tier cloud.
Have packetbroker allowing to route traffic. Set gateway to public. Etc, etc.
I thought it has something to do with the fact that I registered my gateway before on the V2 network. Then switched to V3 (community edition) and then switched to V3 (cloud) that it kinda messes up with id’s or something. Maybe didnt deregister the gateway in V2 the right way.
When I use the url’s from first post and try to query the individual gateway info I can query the gateway on the V2 network, stating it’s offline.
But V3, changing net id, etc… nothing.
I have tried to follow this procedure to hide my develop gateway location. However, in the api response the “location” is still present. How can I remove it?
Maybe relevant for this thread; i’ve been trying out the Helium console, and one feature i found useful is the Coverage tab: it allows to list and map all gateways/hotspots that are seeing packets of my devices (no packets in below case because no mapping activity in the last 24hrs)
I think it could be useful to integrate similar functionality in the TTN applications console, to have easy access to a list of gateways serving the end devices and understand on which gateways the application depends. I see that the rxmetadata has the gateway info, so it would seem easy to extract it and keep a log of the gateways, packet counts, and show a map.
Store all you uplink information, including gateway information in a DB, then you can just recall all the data for the time period you require an display your nodes and relative gateways on a map.
Hey Johan, nice one…we don’t get many users posting ‘Labs’ stories or “how too’s” these days…do you fancy writing this up for others to follow as many TTN users are not ‘software’ eng’s ( ) and whilst may understand concepts and methods may not be comfortable starting such a
“Very easy, you can build your own.”
project https://www.thethingsnetwork.org/labs/