I second this. Just migrated do v3 and my nodered status is not working.
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": [],
}
1 Like
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!
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
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@ttnnot 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!
2 Likes
I can confirm the API works…nice!
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?
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.
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.
2 Likes
@ronnie_low_power, you’ll only get data in the last_status_received field if your gateway sends a status.
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
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)
That’s not up to him, it’s up to the people writing Basic Station, which could be you …
Reason for asking. I along with others have asked that question in the github issues and no response. Just wondered if htdvisser may have some idea. Not looking for any action on his part.
I would have a go but I’m not sufficiently versed in C to do this. I have looked a few times but could not figure out its architecture to understand how it would be added. I also came to the conclusion it’s not easy and the code may need some restructuring, otherwise it most likely would have already been done by now.
- Lean Design
- No external software dependencies (except mbedTLS and libloragw/-v2)
- Portable C code, no C++, dependent only on GNU libc
- Easily portable to Linux-based gateways and embedded systems
aka:
We kept things simple by omitting any design documentation and made all the filenames somewhat cryptic.
I think we can be almost 99.999% sure TTI have their hands full so any addition would be a community effort and it would be rather gateway specific as to what attributes it could send. It would certainly be nice to know if your gateway is cooking or has enough battery life when running on solar.
Maybe @Jeff-UK could make enquiries, particularly as he’s in to solar and a bit of status info may help him too.
1 Like
There are other software options available…
Is that the one with the ‘challenged’ install script?
Exactly what I do. I have decided not to move to Basics Station until “status” is available.
Even though I bumble my way through writing C, I also send additional gateway data direct from the gateway to a database. Data elements include lorawan traffic (status) data, voltages & temperatures etc inside the gateway and environmental sensors located in close proximity and connected to the gateway.
Great feedback on Github, there is a way in Basics Station to create the “stats” message.
There is a more generic feature where a string of data can be injected from outside Basics Station into the gateway-server link.
For gateway status, all that is needed is another application to append an appropriately formatted string to a file name cmd.fifo and Basics Station will inject this.
Refer:
Health Status Messages? · Issue #46 · lorabasics/basicstation (github.com)
and
1 Like
The discussion above got me thinking. Since the current default configuration for Basics Station does not send a regular status message, then I assume the load on the Network Server will reduce as gateways move to Basics Station.
Based on the operating experience of the public network, is there now a recommended (or optimum) time period gateways should use between each status message?
The move to V3 is an opportune time for this parameter to be adjusted on the existing gateways.
The same timing would apply to gateways running Basics Station where the stat packet is injected into the gateway-server link