Hi,
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.
Regards
Same here!
Did you figure out something?
I found the issue and a solution (at least for my case).
Problem lies in /lib/functions/breathing_light.sh
breathing_light_status() {
mwan3 status | tee | grep -q online
[ $? -eq 0 ] || return 1
[ -n "`pidof lora_pkt_fwd`" ] || return 1
if [ "`uci get lorawan.network.mode`" == "network_server" ]; then
[ -n "`pidof lorasrv`" ] || return 1
fi
return 0
}
The code expect lora_pkt_fwd to run, But in my case (CUPS on TTN) it does not, but station for basic station is running.
So I modified it as such:
breathing_light_status() {
mwan3 status | tee | grep -q online
[ $? -eq 0 ] || return 1
if [ "`uci get lorawan.network.mode`" == "basic_station" ]; then
[ -n "`pidof station`" ] || return 1
elif [ "`uci get lorawan.network.mode`" == "network_server" ]; then
[ -n "`pidof lorasrv`" ] || return 1
else
[ -n "`pidof lora_pkt_fwd`" ] || return 1
fi
return 0
}
Now the light is properly green when it should.
Don’t know how to push this change to RAK though…
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 
Regards
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.
I have tried WisGateOS v1.3.1 at it seems to be that this has still not been fixed when using LoRa Basics Station. Can someone else confirm this?
Status lights really aren’t useful, since the real world installs no one is typically there to look at them.
What actually matters is that your network server platform is reporting the gateway is currently connected.
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.
i have reported the same thing here…
and i too have to deliver this to a client by Feb 20th and i hope the Rak team will fix these bugs ASAP.
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).
https://www.thethingsindustries.com/docs/reference/api/gateway/
Why would you ever use TTI/TTN API for that? Why not just check the status of Basics Station? You know there are other LNS than TTN 
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