If it is a basic function, maybe you could become better by implementing it?
You may find it easier to setup a small device near the gateway and then you can detect if that has stopped uplinking - this then tests the entire path from gateway receiver all the way through TTS to your end point. If you search the forum for ‘canary’ it should throw up previous discussions along this line.
In the short run, I would like to suggest investing in your knowledge of Node-Red. Through a periodically pull request on the TTN-API you can request your gateway status and depending on the outcome you can send yourself an email or tweet a message like this bot: https://twitter.com/RFSeeTweets.
Yes, this is a possibility. However, my network at www.ttn0478.nl has now about 16/17 gateways covering 160 km2 and overlapping each other for redundancy. A canary sensor won’t always be the best solution for me in this case.
And for all my sensors I have monitoring on in Datacake. If not seen in 1440 minutes, I get an alert,
You’ll see in the various discussions that it’s suggested you check for your gateway in the metadata - it’s not the mere presence of the uplink, it’s the detail of the uplink - which may well cover a number of gateways for you at once.
The canary with a small enough payload can run at around 3 minutes as well.
Such feature is currently in planning but will still take a while since we will implement it as part of a general Event Server that will allow setting up a whole range of user-defined triggers (e.g. if my-gateway status = disconnected) and actions (e.g. send an email). This will, among other things, support users in a variety of maintenance and monitoring use cases, especially when running large fleets.
Yes, although technically it never was TTN v3, it just took time for the real name to leak out.
I’d be voting for not on TTS CE unless it’s got restrictions in place from the beginning and doesn’t show a significant impact on the whole CE cluster.
Restrictions? TTN v2 recently had a bit of a melt down and a restriction of 50 MQTT connections per application was put in place. Yup, that’s fifty! So as we tend to use all the resources we can have (for free), if it is available for CE, I’d hope we can only have one email address for alerts and can expand up from there if it’s OK. And perhaps not be too trigger happy on alerts - so whilst TTI may run at 2 minutes, maybe we have to wait 10.
This new feature will very likely be an enterprise (paid) feature when used limitation-free. We have yet to decide if and how this feature will be made available for TTS CE as well.
I wish I could say but I cannot make any estimations. For the moment we’re very much dedicated to optimizing the stability and fleshing out more essential functionality of the software before taking on more big features like these.
I am sorry to say it but your feature is not helpful for the community as they run on TTN-CE and not on V3-enterprise. In addition is “thinking about it” and “not yet decided” not helpful either for the community because they have a need for such features now.
Lets not divert off topic and see what we can do now.
However, useful for a quick check if GW on line (‘true’)
Have left several V2 GW’s set up as and when migrating them to V3 - i.e. havent chosen to delete V2 GW entry yet, but believe e.g. TTIG migrations or moving the TTGW (Kickstarter) takes old data off line as in