Hi everyone,
as far as I read, we can subscribe to an app topic in MQTT. But can we subscribe to a gateway ? Using NodeRed I’d like to get gateway informations, and have an alert if the gateway is off.
Apparently, this forum said that it’s not possible. But maybe there is some changes now ?
Thank you,
imho it’s not possible because gateways have no MQTT-broker.
But there are gateways who can connect to a MQTT-broker.
Hi simmoinard,
I know this is a bit of a hack. Works for me though:
Some gateways are able to connect to multiple network servers simultaneously. Usually this is frowned upon, since you risk running outside of legal limits. On the other hand, if you control the second server and make it receive only, then you will not have a problem.
To achieve this you could use something like the chirpstack-gateway-bridge. This bridge will allow your gateways to connect to it, receiving all their traffic and metadata and it will forward it to an mqtt-broker of your choosing in quite a configurable way. The topic gateway/GATEWAYEUI/state/conn will give you something like
{"gatewayID":"MTMwNyYAQAA=","state":"ONLINE"}
I would not jump through these whoops if I wasn’t interested in the traffic data as well.
Even more of a hack: set up a device as a beacon - have it send a message like once an hour or so - and place it around your gateway. Have node-red subscribe to the application/node uplink messages as described in Receive Events and Messages | The Things Stack for LoRaWAN and if your gatewayID is in the list of gateway_ids, your gateway is online.
Since I haven’t touched this in a while, there might also be a more elegant solution.
Kind regards
msei
@simmoinard This has been a recommended method for monitoring GW status for some years from many of us, though as a ‘beacon’ can have specific meaning in LoRaWAN world terminology we tend to use the term Canary or Canary Node (as in canary in a coal mine!) to warn of downtime or other operational issues. (Forum search is your friend!), personally I try to nominate an existing useful device due to be deployed in close proximity - say 10-300m range from GW - as being the nominated canary node, rather than having to deploy an ‘extra’ device specifically for the job - say one that is already capturing useful data like temp/humidity etc. Recommend its close enough and on ADR such that it will start or migrate to SF7 in order to minimise on air time (limit congestion contribution) and power consumption (maximise battery life if not on alternate power source). 
As you will see from prior Forum discussions one reason for recommending this type of option is not only do you get confirmation GW is online - as a piece of IT or networking kit - but you are also checking the the full signal path from node to LNS including the RF stages, otherwise status may show GW is online but the RF front end of the GW might be shot or compromised - perhaps by local lightning strike! 
and signals degraded, poor or even none existant (see some of my prior comments using Search). Clues that something drastic like that might include RSSI values falling by 20, 30 or 50+db from historic levels, or significant fall back in SF under ADR - a device that was at SF7 that turns into one at SF11 or SF12, and potentially combined with a corresponding reduction in RSSI will indicate a problem - lightning as above, moisture ingress to GW antenna connections etc. that should then be investigated.
Thank you everyone, this is very, very clear !
@Jeff-UK @msei I will create a Canary then 
you convinced me.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.