You could have a device nearby that cycles the power on the gateway if its sent an appropriate downlink.
No, wait, erm, will that work?
Good afternoon @descartes, automation is full of variants on the “dead man handle” combined with “fail to safe” to deal with these kind of situations.
The way that I personally deploy this in LoRaWAN infrastructure is as follows:
- Mikrotik PPoE backhaul cellular radio with LORIX gateway powered via PPoE dog-leg.
- Mikrotik routinely checks a URL and depending on what it finds the LORIX gateway can be power-cycled by software-toggling the PPoE dog-leg.
This means that I can do a remote full power-cycle of the gateway with no extra hardware at all. I have not yet automated the URL control setting but that would not be hard if there was a semi-intelligent canary.
This kind of approach is completely normal in the mobile/cellular industry to remotely handle stuck Remote Radio Heads (RRHs) up towers. All the equipment can be power-cycled via the semi-intelligent -48VDC PSU.
I’ve cheap(ish) GSM modules that if they don’t get an SMS, recycle the power, through to one ADSL router out in the far sticks that is on a peg timer so it gets cycled during the middle of the night every night as BT can’t keep the wet string warm enough to work all the time.
The word of warning to anyone trying this, is when you turn it off, leave it off for at least 30 seconds as some power supplies like to blow if you pull the rug for only a few seconds and just occasionally, power consumption is such that the capacitors keep things going enough that the item it’s connected to doesn’t truly turn off and can restart in a very questionable state.
But how to do it sensibly for the devices, I’ve not been sending a confirmed uplink, just a single late night downlink. But only for more critical devices. I guess my scheme takes up more radio time so I need to review this.
Another word of warning is to be sure of the nature of the gateway - if it is e.g. Pi based then simply pulling power may well corrupt SD Card leadig to dead GW 
A trigger of a graceful shutdown and restart is then a benefit - though there are times when a full cold reboot may be an advantage. A short mains power outage here last week (<5 secs) managed to knock out 4 gw’s on test - 3 x Pi based only one of which could quickly be recovered (I still havent had time to re-flash the other two! ) and a Dragino LPS8 that is on old firmware and which didnt automagically pick up the (restored a short time after the GW) WiFi again on reboot so had to be manually reset…
A relay in parallel to the switch/monitor.py offered by some of Charles/Ch2i builds does just fine on those Pi based GW’s that support it…
Considering that a gateway has to have an Internet connection, then unless the gateway had an anti-use design (TTIG and a few others), you can simply send the gateway a command.
It’s true that hard rebooting Linux based gateways with conventional filesystems and storage media is a bad idea (which is in part the same reason why such things aren’t a ,good solution for field use to begin with).
My approach as been multiple levels of protection, eg:
-
something on the gateway checks on round trip communication with servers, if that fails, the daemons involved like packet forwarder, etc are restarted
-
the same for the internet connectivity, restarting that
-
this checking feeds a hardware or external supervisory watchdog
So ideally only the thing which has failed gets force restarted; but ultimately, if the checker itself is failing, then box will be restarted.
There’s then a remote access scheme, such that if the box is up, then odd behavior (for example receiving but not transmitting) is someone one can ssh in to investigate.
I did once see the jit transmit queue in the packet forwarder somehow get stuck full and never drain, thus blocking all transmission, but haven’t been able to replicate or to figure out by inspection how that could happen.
Incidentally, it’s worth noting that rebooting a host Linux often will not cause an actual reboot of a mobile data modem; we ended up adding giving the host system a GPIO controlled power switch for the modem.
It actually seemed to work with the help of a Fieldtester