Connected to TTN with LNS protocol, status LED is breathing red (abnormal situation). If LoRa internal server is selected, led is breathing blue (normal situation).
Logs doesn’t show any error, except that it doesn’t find a Quectel modem.
I can simply change LED color in menu but for me it would be great to see if the gateway is working well or not looking at it. And I think this behaviour is not what it is expected.
Looks like some positive steps, but I don’t think your logic is quite right for the cases you aren’t using since “lorasrv” runs in addition to lora_pkt_fwd not instead of it.
I would probably make the lora_pkt_fwd check the else to your basic station configuration check, and leave the lorasrv if and check independent as they were.
So something more like this (unchecked)
breathing_light_status() {
mwan3 status | tee | grep -q online
[ $? -eq 0 ] || return 1
# either basicstation or a classic packet forwarder should be running
if [ "`uci get lorawan.network.mode`" == "basic_station" ]; then
[ -n "`pidof station`" ] || return 1
else
[ -n "`pidof lora_pkt_fwd`" ] || return 1
fi
# loraserver may be configured in addition to the classic packet forwarder on which it depends
if [ "`uci get lorawan.network.mode`" == "network_server" ]; then
[ -n "`pidof lorasrv`" ] || return 1
fi
return 0
}
Thanks for your answers !! @Raomin no I did not find the time to investigate more … At least I was looking for the service/script which runs the LED but this week I hope I will be able to test this modifications
So I tested Raomin code and it seems to work well but : I changed LNS URL to introduce an error (“wss://eu1.cloud.thethings.networ” instead of “wss://eu1.cloud.thethings.network”)
Logs shows error but the LED is till breathing green :s
PS : is there any adminsys documentation about WisGate OS ? I could made my own research but as there is a lot of tweaks, it’s hard to dig …
The script only checks that there’s a copy of the station process running at that instant in time, it doesn’t check that the process is “happy” or how long that same process has been running for. So it wouldn’t see errors that don’t result in process death, and it wouldn’t reliably catch something that keeps dying and respawning except when it was down at the moment it was checked.
Typically the really meaningful gateway status is reported either from the network server or your own remote status reporting scheme - gateways in actual use aren’t typically where someone can physically see their LEDs.
If you really want to, with some investment of effort to develop criteria you can probably find a way to capture more meaningful information on the LED however.
In most cases you are probably right, but we actually used them because we have partners installing our gateways and sensors all our Europe. They don’t know anything about network and LoRaWAN so we use the status LED’s to help us troubleshoot when/if a gateway goes offline.
I’m testing a RAK7268 atm. to see if this should be our new gateway going forward and one of it’s USP’s to me was the LED on the front beside other things. Since this is a commercial product I would expect the RAK team at some point to fix this bug in an upcoming firmware update.
Having a red LED blinking on the front, even though the gateway is working like it should is very confusing.
One workaround and very efficient way would be that the gateway connect to TTN API to get its own status. If any problem exists (internet connection problem, packet forwarder process down, network server down …) it would blow red, and if everything is okay, blow green.
But it’s not easy to get this process “user friendly” because of tokens and other few things which would need modifications in the interface (not a simple script writing).
Because as I said it checks a complete toolchain. For now basicaly it’s just chekcing that an embed process is running, there is a lot of other fails that could lead to an inoperative gateway. But I get your point, it would only work for TTN and not other LNS but I think the majority of people will use TTN, so it would be a good step at least