Gateway API to fetch online status

[dhavalnc1]

Hi Everyone,

I am new to this Lorawan world and need help to figure out some basic features for my Lorawan gateways. I have connected the Laird gateway to TTN console and i can see the sensor data coming in from the sensors.

On the Gateway overview page, i can see the Gateway ID, status and lots of other parameters. Is there any REST API to fetch this details from the outside application? I want to display the list of gateway online/offline statistics on my website. I can do that based on the sensor data arrival time, but instead i want to fetch the Gateway statistics on request when ever the user wants to see.

I found one solution in the forum “https://noc.thethingsnetwork.org:8085/api/v3/gateways/gw_id”, but this is not working.

[Jeff-UK]

v2 not v3 should then work

[arjanvanb (Arjan)]

Also, not HTTPS.

[dhavalnc1]

Thank you so much guys. The “http://noc.thethingsnetwork.org:8085/api/v2/gateways/gw_id” worked.
The response is:
{“timestamp”:“2020-08-20T13:30:47.178148912Z”,“uplink”:“1749”,“downlink”:“1653”,“location”:{},“frequency_plan”:“US_902_928”,“gps”:{},“time”:“1597930247178148912”,“rx_ok”:1749,“tx_in”:1653}

How can i get the online status value connected/not connected?
The timestamp value is when the gateway was online last time. I can decide the online status based on timestamp. Is there any document which provides the list of all APIs to fetch Gateway status?

[Jeff-UK]

“connected/not connected” is effectively a timeout value determined as some period from last “timestamp” when seen…most GW’s ‘update’ on 30sec interval timeline, others longer. Typically I find the Console can take anything from 2min to >30mins to ‘change’ to not connected if I shutdown or disconnect the netwroek connection…(similarly when coming back on line though I have seen it take many hiurs depending on Console Data Display scrape activity timing…

[descartes (Nick McCloud)]

For a modest investment, you could have a canary device that uplinks a small payload at what ever interval fits your downtime notification needs (but obviously respects the fair use policy).

By doing this, your gateway stats will tick up and the timestamp will be updated AND as a bonus, you can check the uplink has arrived at your application so you know that the gateway is alive & well and that the infrastructure is passing on messages.

But obviously, don’t hammer the gateway status.

What downtime can you cope with - I haven’t got anything running that couldn’t go a few hours without issues - maybe an irritating gap in data, but all alerts should have boundaries set - “hey, there may be a issue”, “ouch, that hurt” and “byeeeeeee” - which the server should also be able to extrapolate - and maybe one day, I’ll figure out enough ML to get it to auto-guess for me.

[Jeff-UK]

I’ve got into the habit of always installing such a canary typically 50-250m away from any new GW deployment if I can get a good site for just such a purpose - most on 20min update some longer/slower - critical application locations might be as low as 5mins - proximity means canary chirps on SF7 with no significant payload to worry about so its low time on air (might send canary battery level but usually try for a powered location if poss). If I have to get closer to GW I set Tx power v low so as to minimise battery use and minimise near/far problems for remote sensors, as well as helping ensure GW is running with ability to pick up low sensitivity signals - have seen some GW’s in past go partially deaf - I suspect due to latent failure due to static damage or near miss with lightning strikes… Always keep canary at least 3m, pref >5m away from GW ant and behind an absorber if poss…

[ronnie_low_power]

Hi All,

With the v2 → v3 in mind, I am trying to figure out how to retrieve that status of v3 gateways?
Currently I am using NodeRed (node-red-contrib-ttn module) to fetch v2 gateways.

Should we be using these to convert our checks, and what would be an example URL?
https://www.thethingsindustries.com/docs/reference/api/gateway/

[darkman]

I second this. Just migrated do v3 and my nodered status is not working.

[descartes (Nick McCloud)]

This looks like the most likely candidate as a ‘web page’ type request:

https://www.thethingsindustries.com/docs/reference/api/gateway_server/

GET /api/v3/gs/gateways/{gateway_id}/connection/stats

Returns a packet that looks like this:

{
  "connected_at": "0001-01-01T00:00:00Z",
  "protocol": "",
  "last_status_received_at": "0001-01-01T00:00:00Z",
  "last_status": {},
  "last_uplink_received_at": "0001-01-01T00:00:00Z",
  "uplink_count": 0,
  "last_downlink_received_at": "0001-01-01T00:00:00Z",
  "downlink_count": 0,
  "round_trip_times": {},
  "sub_bands": [],
}

[patrik_baertschi]

Hello everybody
I could not find the https adress i have to use for the eu1 server?
With the http://noc.thethingsnetwork.org:8085… it does not work.
Thanks for your help!

[Jeff-UK]

@patrik_baertschi

With the http://noc.thethingsnetwork.org:8085 … it does not work.

If that is the url you used then not surprised it didn’t work, as incomplete. Also if/when you get the correct one you will see it is actually a V2 noc (as called out in the url) so won’t work with V3.

See also earlier post

NOC v3 url

As I understand it there won’t be a directly equivalent noc… V3 moves to a much more distributed architecture based around clusters, though I too would welcome something along similar lines, even if just at the cluster level. As mods and users we could often look into V2 noc to help determine gw status and assist with trouble shooting. Perhaps @johan could advise what if any similar capabilities we may have going forward. The old noc allowed people like Meeta Co in Australia (now defunct) to app…

[ronnie_low_power]

All,

Getting a bit further on the URL.
In the below commands, replace ’ NNSXS.API_KEY ’ with your API key, and 1234567890 with your gateway ID.

Example v3 URL:

curl -i -H “Authorization: Bearer NNSXS.API_KEY” https://eu1.cloud.thethings.network/api/v3/gateways/eui-1234567890/rights

or

curl -i -H “Authorization: Bearer NNSXS.API_KEY” https://eu1.cloud.thethings.network/api/v3/gateways/eui-1234567890/api-keys

and

curl -i -H “Authorization: Bearer NNSXS.API_KEY” https://eu1.cloud.thethings.network/api/v3/gs/gateways/eui-1234567890/connection/stats

I do have the API key belonging to the specific gateway, and get the result (the GW is indeed offline)

{“code”:5,“message”:“error:pkg/gatewayserver:not_connected (gateway eui-0000024b080605f0@ttn not connected)”,“details”:[{“@type”:“type.googleapis.com/ttn.lorawan.v3.ErrorDetails",“namespace”:“pkg/gatewayserver”,“name”:“not_connected”,“message_format”:"gateway {gateway_uid} not connected”,“attributes”:{“gateway_uid”:“eui-0000024b080605f0@ttn”},“correlation_id”:“2b7bc0cc621440258c72834b9aa95941”,“cause”:{“namespace”:“pkg/redis”,“name”:“not_found”,“message_format”:“entity not found”,“code”:5},“code”:5}]}

Now need to test when the GW is online!

[vaasseniot]

I can confirm the API works…nice!

[ronnie_low_power]

I am still a bit puzzled by the ‘last_status_received’ element…
My GW is online, and the uplink/downlink counts show increasing but the timestamp on last_received_status is almost the same as the connected_at timestamp:

From node-red:

connected_at: "2021-02-16T13:13:42.432475261Z"
protocol: "ws"
last_status_received_at: "2021-02-16T13:13:42.465851358Z"
last_status: object
time: "2021-02-16T13:13:42.465716693Z"
boot_time: "0001-01-01T00:00:00Z"
versions: object
firmware: ""
package: ""
platform: "kerlink - Firmware  - Protocol 2"
station: "2.0.5(kerlink/std)"
advanced: object
features: "rmtsh"
model: "kerlink"
last_uplink_received_at: "2021-02-16T20:45:22.715022985Z"
uplink_count: "2395"
last_downlink_received_at: "2021-02-16T20:42:34.237813913Z"
downlink_count: "35"
sub_bands: array[6]

Should this last_status_received timestamp be recent?

[descartes (Nick McCloud)]

@ronnie_low_power

Should this last_status_received timestamp be recent?

As discussions evolve here we get more insights in to the infrastructure - to stop the database(s) melting, some data is cold - ie it’s not updated live - which makes sense.

The wording and the structures imply that the timestamp is when the gateway last sent a status message - the question being is, what is that status message!

@htdvisser, can you tell us how the last_status_received field is defined / updated please.

[htdvisser (Hylke Visser)]

This depends on the type of gateway. The UDP packet forwarder, as well as the MQTT forwarder of The Things Kickstarter gateway regularly send status messages with information about the gateway. The Basic Station protocol doesn’t send regular status messages, and the only status we get is when it sends the station, firmware, package, model, protocol and features fields when it connects.

[descartes (Nick McCloud)]

@ronnie_low_power, you’ll only get data in the last_status_received field if your gateway sends a status.

[ronnie_low_power]

Hi Guys,

Many thanks for the clear feedback. It explains why there is a difference between de gateways. In my case I use the ‘Basic Station’.

As I am trying to monitor my gateways in a simple NodeRed flow, is there a query possible, which basically shows the same status, as is visible the new console?

In other words, where is the console Gateway status retrieved from, and can we do that via any API?

Many thanks for helping out!

Ron

[TonySmith]

@htdvisser

The Basic Station protocol doesn’t send regular status messages,

The lack of status messages was opened on Basics Station Github back in November 2019. It includes a response “We have this feature on our roadmap and it will be included in future releases.”

@htdvisser you are a bit closer to the action, Any idea when that might occur?

Health Status Messages? · Issue #46 · lorabasics/basicstation (github.com)