I’m trying to build my own gateway monitoring system using Node-RED on TTS Cloud. My plan is to use these API call to get information on connection status on each gateway.
GET /api/v3/gateways (to get information like name, description etc.)
GET /api/v3/gs/gateways/{gateway_id}/connection/stats (to get connected/offline status)
My challenge is that I’m not able to get the name and description from each gateway. I can see it should be possible here Gateway APIs | The Things Stack for LoRaWAN but I don’t know how to get it?
When using /api/v3/gateways I’m only getting gateway_id, eui, created_at and updated_at.
This kind of info isnt likely to change much or regularly once registered, so an adhoc look at the gw related url will pull name - description etc helping with
Checking this say once a month may show up any naming/description changes - you can then populate into your database…just dont automate it to hit every minute! (Think of the poor servers ) Note this also captures online/offline status at time of snapshot, but again would avoid regular/very frequent pulls just for that purpose.
I understand. The link does not work for me, the JSON is empty. I’m not using TTN but TTI Cloud instead. Does that make any difference? How often am I allowed to pull? We are in the process of moving LNS to TTI, and we currently have maybe around 100 indoor gateways - so we need a good way to monitor if a gateway goes offline, and being notified asap.
I think that one is a pull from V2 - not sure it will survive V2 Sunset scheduled for Dec 1st! (Would be happy to learn otherwise), note similar but not identical GW ID/EUI from V2 pre-migration (below) and post-migration V3.
I believe draws from same data source as the main one I used previously for V2 (still do for the remaining not yet migrated GW’s!), which I also anticipate (am planning for/assuming) will die with the V2 sunset and great server ‘switch off’ https://account.thethingsnetwork.org/api/v2/gateways/gs3_ttn_testgw011a
I just need to get information if a gateway is online or offline and save it to my database, so I can monitor for how long a gateway has been online/offline, and also send me a notification when a gateway goes down.
So which API should I use for The Things Stack Cloud if I want to monitor a lot of gateways? I just need name, description, online status etc.
Search the forum as GW monitoring and alerting has been a regular topic over the years,
IME and from other posts for such an estate my recommendatiuon would be to deploy a canary node in reasonably close proximity to every GW as and when deployed. If close this allows for a short on air time SF, and even deminished TX power - lowers battery consumption/extends life if not running off mains power source, and reduces prospect for collisions/interference with production messages. Indeed I normally use a ‘production’ node as a canary so I get useful data as well as alerting (A simple T&H monitor - e.g. Laird RS186 or Dragino LHT65 good options.), Alternatively a node sending a zero byte payload (on a fport of your choice?) provides a simple heartbeat and low airtime solution.
By using a canary not only are you checking if the GW is ‘online’ as a piece of IT kit you are also testing the full RF + Data path from node to NS… a far more useful test than just checking of it is hanging on the network! Note: I have had 3 GW’s ‘go deaf’ over the years - 2 where the concentrator card or MCU interface died - total deafness - and one where there was a massive loss of sensitivity - down 35-40db on historic levels - which was suspected to be down to a close proximity lightning strike. Just monitoring these GW’s as on/offline from IT perspective would not neccessarily have revealed a problem, using a canary node highlights the problem in say 15, 20 or 30mins - if update rate set at that interval
I have already searched in the forum Maybe I should explain a little bit on how our system works - because I’m guessing it is a little bit different from what people normally have.
We have indoor gateways installed on many locations across Europe and have hundred of end devices on each location that each sends data many times during a day. All of them are near the gateways, so they should all send with SF7. I know that I could just check in my database if end devices have send from a specific gateway and then monitor if gateway has not received any data the last 15-30 min, which then means that it is probably offline.
Our challenge is that sometimes a gateway gets unplugged for whatever reason, and that means our system could go down or the other end devices need to send to gateway further away (lower DR), which is a problem because all of our sensors is battery powered.
I want a monitoring system that can check all the gateways on TTI and where I don’t need to manually keep a list of gateway id’s that my system needs to monitor.
So you have all these devices and all these gateways but you don’t have an asset management database? Or query TTS once a day/week to download all the IDs to make sure your database is up to date (hint, don’t allow anyone access to the console, only via an app, keeps things in sync).
Come in to my bat-cave, I have many solutions along these lines because none of this is unusual.
As a freebie, every uplink tells you which gateways heard the device - just parse that to update the gateway status and, as @Jeff-UK likes to say, Bob’s your uncle. Which doesn’t work for me, as he’s me dad, but that’s another story.
Note Nodes wont immediately start sending on higher SF’s if close proximity GW goes down even if set for ADR (it takes time to adjust under say ADR - typically around 20 messages on TTN), Parsing the node metadata for receiving GW’s will tell you if GW down or not contributing to message delivery if under redundant cover, parsing RX signal level for a well established node (or better yet a cluster as any one node may see local masking) will tell you if the RX level has dropped significantly but not gone full deaf.
If you get an alert/warning you can then investigate if GW itself is the problem as an exception (turn-off/unplugged, failed, dropped backhaul, or whatever).
Thank you for trying to help me I do know how ADR etc. works, and we do save the whole frame in our database for each uplink. All I wanted to do was using the API described here
to monitor all my gateways, and don’t have to look in my database and manually add/remove every time we install a new gateway. This is only a PoC project so I was just hoping to make something quick using the API to test with.
These API calls are indeed currently the best way to do this.
For the first one: as others already commented, please think about how often your gateway list changes; you probably don’t need to list all your gateways every hour, because you won’t be adding new gateways that often.
BTW: the first request should always be made to the eu1 cluster, because that’s where the gateway database lives, the second one should be made to the cluster your gateway is connected to.
I understand the confusion. This is the V2 API of Packet Broker Mapper, which has nothing to do with The Things Network V2. The Packet Broker Mapper API is new, and will stay around after The Things Network V2 shuts down in December.
In the future we plan to add a new “Event Server” component to The Things Stack Enterprise that should make it easier to monitor large numbers of gateways by setting up rules that would (for example) send a webhook to your monitoring system when a gateway connects/disconnects.
) Note this also captures online/offline status at time of snapshot, but again would avoid regular/very frequent pulls just for that purpose.
(Would be happy to learn otherwise), note similar but not identical GW ID/EUI from V2 pre-migration (below) and post-migration V3.
(A simple T&H monitor - e.g. Laird RS186 or Dragino LHT65 good options.), Alternatively a node sending a zero byte payload (on a fport of your choice?) provides a simple heartbeat and low airtime solution.
Maybe I should explain a little bit on how our system works - because I’m guessing it is a little bit different from what people normally have.