Issue: MQTT Gateway stats via GatewayBackendConfiguration feature only available when gateway setup as a UDP forwarder, not when using built-in Lorawan server
Setup:
LoRa® Server:1.1.0062_Release r202
Mosquitto external MQTT broker
According to the docs, it should be possible to see gateway stats at your MQTT broker when using the built-in lora server in the gateway, but I cant get it to work. Only works when the gateway is setup as an UDP semtech forwarder.
Any Ideas?
Hei,
This is actually a bit old. What exactly are you trying to accomplish?
If I am guessing right you want to use the build in server to point it to your MQTT broker via the Bridge, right?
Using the built in server I am assuming you also have an application and device created and want to forward the decrypted payload data. You can do this via the Global Integration tab:
Hi Vladislav, Thanks for your quick response!
I am evaluating the built-in lorawan server as an alternative to using chirpstack in an external server.
I am not sure if you mean the firmware I am using is old?
We want to use the built-in server from RAK, it will save a lot of resources needed for chirpstack, however we really like to get the lorawan gateway stats by MQTT as we do if we use the RAK as a UDP forwarder only,
But, for some reason when we switch from using thr RAK as a UDP forwarder to using the built-in server, we no long are seeing messages in the Gateway topic arriving at out MQTT broker. We did set up the Gateway Back end MQTT so I think it should work.
Maybe we set something wrong on the RAK UI?
Cheers
Patrick
In Chirpstack (including in the older still version still branded as LoRaServer that runs in the RAK gateways) MQTT actually shows up in two places:
Between the gateway component and the server
Between the server and application clients
Gateway status messages would only be in the first MQTT setup devoted to gateway messaging, and not in the second devoted to application messaging.
It’s possible both MQTT setups may use the same broker, or they may use distinct brokers. In particular, if you are configuring the server component to send its output to some external broker, that’s not going to do anything with the gateway messaging, which is likely to remain pointed at the internal broker.
Be sure you are trying to subscribe to the broker which actually has the message types of interest.
Hei @Chirpper,
Christ is right. By the way I meant the doc is outdated 
I was going to suggest the same make sure you are subscribing to the right MQTT topics for the integration you want to use.
Hey guys, thanks for taking an interest with this.
So to describe what I am doing;
setup the Rak 7258 in the UI as UDP packet forwarder to my own external chirpstack server (on a R-pi)…I use my end-device to test the RAK is working as a gateway packet forwarder only, I see all lorawan frames going through the RAK, and on to my chirpstack Pi…All good. Also I use MQTT explorer to connect to the mosquitto broker also on the same PI as chirpstack, I see BOTH application (payloads etc)MQTT messages AND Gateway MQTT (Events/commanes etc) messages on the broker. Great! now I can monitor and make logs to Node-red about the gateway events etc
Now I change the RAK packet forwarder to Protocol: “Built in server”. I setup my end-device applications in the RAK server and get them joined and sending uplinks etc.
I set up the RAK server application MQTT to point to my external pi mosquitto broker (like I did with the Chirpstack), and I see application MQTT messages appearing at the broker!, awesome! just like with Chirpsatck.
But…
Then I setup the RAK server gateway back-end MQTT to point to my Pi mosquitto, expecting to start seeing the Gateway MQTT messages (Events/commands etc)… but I dont see any MQTT topics or messages :(.
Did I do or expect something wrong?
P
Then I setup the RAK server gateway back-end MQTT to point to my Pi mosquitto, expecting to start seeing the Gateway MQTT messages (Events/commands etc)… but I dont see any MQTT topics or messages :(.
That would set where the server expects to communicate with gateways.
But it would probably not set how the gateway (specifically the gateway bridge) expects to communicate with the server.
My guess is when you do this, the server stops getting any gateway traffic at all.
You’d need to also change the configuration of the gateway bridge to point to the external MQTT.
But once you do that, there’s essentially no reason to use the internal sever - you’d be bouncing the raw traffic up to the cloud, back down, processing it, then bouncing any downlinks back up and down again. Why would you want to do that?
If you really want to just monitor what is going on in an internal setup, then you probably want to stick with the internal broker, but add a custom component that gets the status messages and forwards them to an external broker, so that this monitoring is outside of the critical operational path.
Hi Chris, Oh ok I thought that the server communicates with other gateways via the LoRa MQTT Bridge (in the Lora Gateway tab) , not the MQTT back end… (in the sever gateway tab: “Gateway Backend Configuration”.
To summerise I understand that we have 3 MQTT connections possibilities:
Correct?
PS
The LoRa MQTT bridge is how the gateway connects to the MQTT broker used for gateway traffic
.
The Gateway backend configuration is how the server connects to the MQTT broker used for gateway traffic.
Thus those two are the respective ends of the same flow of communication.
Normally when you run the server on the same computer comprising the gateway, you have only that one single gateway in your system.
If you want to put the raw gateway traffic up on a cloud MQTT broker, then it makes little sense to run the server on the little computer in the gateway to begin with, especially if you have more than one gateway.
It might make sense to spend some time on the chirpstack site gaining a better understanding of this system; what’s built into the RAK gateway is an old version from before the LoRaServer -> Chirpstack name change.
Hei @Chirpper,
I believe it is like this:
Option 3 is meant to get that same data as in option one I believe, however for a more specific case I believe. Seeing how your gateway acts a Server it aggregates all the traffic for any gateways that are connected to it using their own Option 1. Plus this data is actual payload data as the server does its job:) Than the whole data set is forward, but it should be presented as coming from that particular gateway (not actually sure about this).
This should not make the server gateway getting traffic from the other gateways or nodes as a matter of fact.
This is how I see it, but I could be wrong.
Best ask @yutao to give us the details as he knows best:
@yutao could you please clarify or as a matter of fact anyone else that is sure how this works @rakwireless-staff
The Gateway Backend interface can collect the LoRa packet from other gateways and send them to the Build-in LoRa Network Server in this gateway.
Thanks all, I really appreciate your feedback and your time to clarify this topic
P
