A number of others have asked about this from various other APIs
It may be more expedient in the short to medium term to hold the values on the database and if you get a lower figure, you can assume there has been a restart and accumulate them
@descartes , do you mean the total of uplink and downlink messages will be available in the API on short/medium time? And that I store these numbers also in my own database and recalculate the total of my gateway in a month for historical data?
That is no issue if the numbers will be available in the API.
The JSON have “rxRate”:70.93811,“txRate”:0 they are measured every 4-6 min and are indicative of packets per hour
@Johan_Scheepers I do apologize, but is packages the same as a message? And if this is every 4 to 6 minutes, you do not have actual numbers to calculate with. Marc
I think we all refer the the same thing a a few different ways, packets / messages / uplink / downlink and most probably a few more terms that can be used.
Don’t have a exact number, I think they measure packets and the min and then simply packets/ min*60, but sure @johan can give a more accurate answer. Also seen these fields are not available if you quarry to often.
There are a few other fields I would like to know there significance, event.clientX , event.clientY and event.bbox.
Yep, Gateway Server updates the gateway statistics every 4 to 6 minutes (random to distribute load). The RX and TX rates indicate the packets per hour. This is only indicative for the busyness and liveness of gateways. Although you can, I would discourage polling these values and converting them back to actual numbers (based on consecutive updatedAt timestamps), because you’ll be missing updates and with many gateways you’ll be hitting the API rate limiter.
We are working on a separate API for routing statistics, including per-gateway aggregates over time.
1 Like
Very useful API, thanks. My gateway moved (Antenna location changed thanks to GPS + Location correctly set in console). How long will it take to get the new value through the API ? (Is it minutes, hours, days? )
That should be minutes, up to 6 minutes roughly.
First of all: Great to have this API !
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.
ETag is a bit tricky, but Last-Modified can be used so you can pass If-Modified-Since instead. I’ll file an internal issue.
1 Like
A Node-red tool around the TTN Gateway Radius and Gateway API
4 Likes
Added an new table calculating and displaying the distance and azimuth from the new node to gateways.
Also add a window calling on @avbentem airtime-calculator for TTN and a window calling on The Things Network Status Page
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
You will have to change the url’s as well.
Thanks Nick - any idea what the url ought to be? I have made many guesses…
Doh, replied too fast, it’s not on the instances so it’s not a TTS API call.
Do you have packet broker turned on for your instance?
Yes I believe we do - our gateways forward stuff to community apps and our apps receive messages from community gateways via packetbroker
I’ll have a look at mine, if you get my drift.
1 Like
Which TTS version are you running?
Are the gateway locations and statuses public? See gateway settings in the Console.
You should be using your NetID and tenant ID with which you connect to Packet Broker.
Otherwise reach out privately and we’ll get this fixed.
Hi @johan - sure, I’ll log a support call.
It is TTS Cloud edition and yes the gateway locations and statuses are public.