That was where the old V2 NOC was good as above, now if monitoring your own nodes (obviously wont work for handling annon 3rd party nodes) when you extract the data to your own database you can analyse the message metadata to see which GW’s handled the message and keep a count of where you see your GW being used…sadly doesnt account for total traffic though.
Thanks for the replies.
I noticed there is a list of gateways with every message received from our sensors, however our goal was really to monitor total usage and not just our own packets.
Guess I will have to use the workaround and request the traffic in close intervals, check the timestamps and add up the values to get an estimate of the total traffic.
And potentially find yourself disconnected - every API call to the TTS CE infrastructure comes at a price, a price we don’t pay and adding more servers to accommodate is becoming increasingly less feasible. So anything that queries very frequently has to be super essential.
So please before diving in, let’s all investigate all the potential and ask the TTI engineers for their view - particularly as it’s always nice to ask the people that have to solve the issues we create.
In the meanwhile, rather like footfall in a shopping centre, you could do worse than leave the console open and download the JSON for analysis - it won’t be single byte accurate but it will give you plenty of indication of traffic. And it may well be that this can be captured using other tools. What is effectively Server Side Events pushing data to a browser or Javascript app has far less impact than a database query and, bonus, gives you far more detail.
If you use the below API it is update ~6min, gives you a very good idea of how busy a gateway is.
IRC it is the average over the time period, most use cases this is sufficient
https://mapper.packetbroker.net/api/v2/gateways/netID=000013,tenantID=ttn,id='gareway id'
1 Like
And here we go, edited for brevity: https://eu1.cloud.thethings.network/api/v3/gs/gateways/descartes-m2m-tele-2/connection/stats
{
"connected_at": "2022-09-14T11:35:19.407560827Z",
"protocol": "udp",
"last_status_received_at": "2022-09-30T09:46:37.818776459Z",
"last_status": {
"time": "2022-09-30T09:46:37Z",
"versions": {
"ttn-lw-gateway-server": "3.21.2-rc0-SNAPSHOT-43bc66caf"
},
"metrics": {
"rxok": 1,
"rxfw": 1,
"ackr": 100,
"txin": 0,
"txok": 0,
"rxin": 1
}
},
verses ...
"last_uplink_received_at": "2022-09-30T09:46:08.306405002Z",
"uplink_count": "27971",
"last_downlink_received_at": "2022-09-29T20:57:38.157190434Z",
"downlink_count": "479",
"round_trip_times": {
"min": "0.024917124s",
"max": "0.024917124s",
"median": "0.024917124s",
"count": 1
}
}
Those counters look very extra useful to me!
Doing this call on a 15 minute basis for 24 hours once a quarter to get some time of day traffic profiling - but not all your gateways - just one at a time, along with doing this call once every 24 hours so any restarts get latest figures would feel about right - but let’s ask @adrianmares what he thinks, as he’s the one that has to put money in the swear box every time we think of toasting the servers.
PS, I don’t think Adrian actually swears but I do suspect he is the Chuck Norris of Servers - he doesn’t need to type the command, the server just does it.
I understand that sending too many API requests might cause problems and really like the approach of requesting the data in intervals and kind of estimate the traffic between them. (assuming that the traffic for most sensors is evenly distributed over the day).
Just like in your example, I mostly get values of 0 and 1 for now which makes an interpolation less accurate, but I will see what I can make of it. Thanks for all the input!
What we need/would help is the reinstatement of the gw lifetime persistent message count per V2, rather than the session only count, that we were promised would be reinstated once V3 transition completed and settled, like much of the other community friendly options that no longer exist 
@adrianmares any chance?
1 Like
Scroll down in the box above and you get:
"last_uplink_received_at": "2022-09-30T09:46:08.306405002Z",
"uplink_count": "27971",
"last_downlink_received_at": "2022-09-29T20:57:38.157190434Z",
"downlink_count": "479",
LoRaWAN has many many moving parts - looking at everything is the trick to find the solution!
That’s true, but if I e.g. send the first request and get a response with “uplink_count: 100” and the second request with “uplink_count: 200” that just means that the traffic status was sent 100 times between my requests.
It does not contain any direct information about the number of packets sent in the meantime. In this example I would go about this something like this:
In 30% of the requests there was a packet send in this status message (i.e. rxok = 1), I missed 100 uplink messages, so I assume that there were around 30 packets sent between my requests.
It’s not as detailed as the old solution seemed to be, but it’s still better than having no information at all
Says nothing about status messages - it tells you you have had 100 uplinks!
Er, no, it means that 100 uplinks were sent which is what @Johan_Scheepers & @Jeff-UK was referencing in their first replies. @Jeff-UK wants more because he’s insatiable, he wants a field for lifetime count as well as these counters reset when your gateway restarts or updates.
Additionally, as above, please don’t run away to create a solution until we’ve had some input from TTI engineering - there may be something we’ve missed or someone else may have an idea. You’ve not had it before today, a couple of more days won’t hurt.
Sorry, then I just missinterpreted the uplink count.
We will discuss the options internally aswell, so it will take a while before we implement any of this anyways.
Edit: I’m blind, also figured out that those values are shown in the console by the up and down arrows. All good, maybe I don’t need to recall the API at all depending on how often the counters are reset.
TRy the link Nick supplied amending for your GW-ID… check again tomorrow - just dont try and grab data every few mins and for all your GW’s - servers wont like you!
Note the data you get back will depend on the device and packet forarder your are using…
e.g. This is a remotely deployed Solar powered RAK ODU that is running UDP/PF where next is a TTIG locally on Basic Station - in each case you see uplink data
|||
|---|---|
|connected_at|2022-09-30T01:54:49.260481829Z|
|protocol|udp|
|last_status_received_at|2022-09-30T11:45:04.113455121Z|
|last_status||
|time|2022-09-30T11:45:04Z|
|versions||
|ttn-lw-gateway-server|3.21.2-rc0-SNAPSHOT-43bc66caf|
|ip||
|0|185.69.XXX.XXX|
|metrics||
|txin|0|
|txok|0|
|rxin|3|
|rxok|2|
|rxfw|2|
|ackr|100|
|last_uplink_received_at|2022-09-30T11:45:07.374012020Z|
**|uplink_count|2950|**
|last_downlink_received_at|2022-09-30T11:35:33.754778949Z|
**|downlink_count|59|**
|round_trip_times||
|min|0.041130681s|
|max|0.104855442s|
|median|0.085358101s|
|count|3|
|sub_bands||
|0||
|min_frequency|863000000|
|max_frequency|865000000|
|downlink_utilization_limit|0.001|
|1||
|min_frequency|865000000|
|max_frequency|868000000|
|downlink_utilization_limit|0.01|
|downlink_utilization|0.0014654578|
|2||
|min_frequency|868000000|
|max_frequency|868600000|
|downlink_utilization_limit|0.01|
|downlink_utilization|0.0007327289|
|3||
|min_frequency|868700000|
|max_frequency|869200000|
|downlink_utilization_limit|0.001|
|4||
|min_frequency|869400000|
|max_frequency|869650000|
|downlink_utilization_limit|0.1|
|5||
|min_frequency|869700000|
|max_frequency|870000000|
|downlink_utilization_limit|0.01|
TTIG:
| connected_at | 2022-09-30T11:10:09.606516987Z |
|---|---|
| protocol | ws |
| last_status_received_at | 2022-09-30T11:10:09.639585891Z |
| last_status | |
| time | 2022-09-30T11:10:09.639458434Z |
| versions | |
| package | 2.0.4 |
| platform | minihub - Firmware 2.0.4 - Protocol 2 |
| station | 2.0.4(minihub/debug) |
| firmware | 2.0.4 |
| advanced | |
| features | rmtsh |
| model | minihub |
| last_uplink_received_at | 2022-09-30T11:59:33.931601521Z |
| uplink_count | 216 |
| last_downlink_received_at | 2022-09-30T11:56:28.417722911Z |
| downlink_count | 3 |
| round_trip_times | |
| min | 0.031407882s |
| max | 0.262213007s |
| median | 0.034172995s |
| count | 20 |
| sub_bands | |
| 0 | |
| min_frequency | 863000000 |
| max_frequency | 865000000 |
| downlink_utilization_limit | 0.001 |
| 1 | |
| min_frequency | 865000000 |
| max_frequency | 868000000 |
| downlink_utilization_limit | 0.01 |
| downlink_utilization | 0.00039210668 |
| 2 | |
| min_frequency | 868000000 |
| max_frequency | 868600000 |
| downlink_utilization_limit | 0.01 |
| downlink_utilization | 0.000019982223 |
| 3 | |
| min_frequency | 868700000 |
| max_frequency | 869200000 |
| downlink_utilization_limit | 0.001 |
| 4 | |
| min_frequency | 869400000 |
| max_frequency | 869650000 |
| downlink_utilization_limit | 0.1 |
| 5 | |
| min_frequency | 869700000 |
| max_frequency | 870000000 |
| downlink_utilization_limit | 0.01 |
To understand GW utilisation and plan for any new deployments I used to have a routine where I would use console to look through the counts for my/my community collaborators & clients GW’s typically once per month, for busy units once per week for lightly used once per quarter and look at increments (manually but not much effort) if I saw high traffic I might plan for a new unit to densify…especially if seeing lots of downlnks - which render unit ‘deaf’ and impacts coverage… running a query such a Nicks (servers permiting) under similar regime may serve until I can get pesistent counts back on GW console pages 
They are from the same source, as above, reset when your gateway resets / goes offline / updates.
Or just project manage the lazy ar5e in to creating something for you …
no expectations - doing a query once a month no issue other than loose data as above if session resets - particularly affects TTIGS and from what I saw this morning TTKGW’s, some solars occasionally stop for a few hours in winter/bad weather if battery capacity too low then recover later which is a pain, but not enough for field trip/expense to swap out until new battery needed (3 - 5 year maintenance cycles!), also some test GW’s used for field tests and trials a few days/weeks/months at a time obviously end up reseting under power cycling due to site moves
Thanks for useful thread - I found this while asking a similar question - how can I report back to my “funders” that the community asset they continue to pay for is being used. I did a bit of digging into results from past few weeks that showed an average of 1450 uplinks an hour and 8 downlinks between Dec 22nd and Jan 3rd. Rebooted the GW an hour ago to clear the session and have observed 3072 uplinks and 20 downlinks in past hour (around midday).
Am now realising that I have nothing to compare that with! Does that seem like high or low utilisation? It also looks like a few devices are sending messages every 30 seconds.
Nether/Both - its a how long is a piece of string type question!
I have a few GW’s that see <10 uplinks per week (keep alives every few days) then bursts of ~100 per day when used for logistics in the area, others have steady 10’s k uplinks per week… I know of some handling 10’k uplinks per day… several have r0lled over multiple Mu over their lives 1-5 years+
May be ‘foreign’ nodes from other networks or devices potentially breaching FUP depending on payload and SF used…without details difficult to say…in the GW console you can see the Dev Addr in the uplink metadata - DA of 26 xx xx xx will be TTN/TTI traffic 00/01 xx xx xx will be experimental nodes - from TTN or any other network that supports such nodes…