RAK7268 - WisGate Edge Lite 2 - Breathing LED issue

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…

1 Like

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
}
1 Like

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 :wink:

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.