Hello there community,
I´ve been trying to figure out how to collect RAK7258 stats(including GPS) when using a external MQTT broker.
Right now i am sending my messages to an external broker, but i cannot figure out how do i obtain the stats of the RAK itself(one of the most simple one GPS)
Many thanks
Hi @bioshock2k RAK7258 doesn’t have GPS! In which mode you use the gateway? In Packet forwarder mode you can subscribe to gateway/{{eui}}/stats topic for gateway status. {{eui}} should be the gateway EUI or wildcard +.
Hi,
I should have added “fake GPS” .
That topic is the one under Lora Network Server->Gateway?
I have subscribed to that topic…maybe im point to the wrong IP. My external broker has an IP of for example 192.168.1.5…therfore my MQTT broker address should have that one as well?
PS: what is wildcard +?
If you’re faking the location anyway, why not just insert it later in the process?
In terms of getting the stats messages that are sent, keep in mind that there two TWO distinct uses of an MQTT broker in a LoRaServer/Chirpstack setup, which could be the same broker, but often would be different.
The first broker carries the gateway/ topics and sits between the gateway bridge and the LoRaServer/Chirpstack. If you are running the server on the gateway, then you certainly want to keep this broker internal to the gateway to avoid unecessary Internet round trips.
The second broker carries the application/ topics with decrypted output of the server (and downlink requests backt through it). These you might set to a cloud type broken to make the data available - but the stats messages are not included here, as those are gateway topics rather than application ones.
If you want the “stats” messages on a cloud MQTT, probably you should switch from running the server in the box to running Chirpstack in the cloud, that way you can also use a newer version of it, you gain the ability to combine the feed from multiple gateways in the future, and you won’t have to re-register your nodes if the gateway box gets damaged or stolen in the field.
That is true, i was focused on actually getting the value ahahaha.
Got it.
My MQTT server is a raspberry pi for this example, therefore they share the same network.
So if i understood correctly is that my gateway configuration should have the default config, and if i wanted to retrive those topics i should assign with the 127.0.0.1 IP?
And this is good advice! i will look into it!
Which MQTT broker? There are two - the gateway/ topics broker and the application/ topics broker; you could set them to the same place, but that would probably not make sense here: as long as you are running the server on the gateway, you should use the gateway as the first broker.
This sounds a bit confused. Keep in mind that 127.0.0.1 is the computer version of “myself” - so one computer can never use that to reach another, as it always points back to itself.
Really you probably want to switch to running the most recent version of Chirpstack on the pi, rather than on the old version included on the gateway (though running it in the cloud would be even better).
I am gathering my application topics in my Raspberry under these topics"application/{{application_ID}}/device/{{device_EUI}}/join"
For what i understood so far i need to acces the gateway /topics under "gateway/{{eui}}/rx " right?
This makes sense! But then should i configure it to an available free IP?
I am using Node-RED btw not chirpstack, in this scenario is the best option for me.
Those are on the first MQTT broker, presumably the one internal to the gateway. I would strongly recommend that you NOT change that setting, unless you move to using an externally hosted LoRaWan server.
If you want to try to obtain that data, then you need to point your MQTT client at the gateway’s actual IP address.
I am using Node-RED btw not chirpstack, in this scenario is the best option for me.
These fill distinct, non-overlapping, complementary functions.
It would appear that you are currently using the built-in server in the gateway to implement that actual LoRaWan protocol. This is an old version of Chirpstack, from back when the project was still called LoRaServer before the LoRa trademark holder forced him to rename it.
Node-RED then does things with the output of LoRaServer/Chirpstack.
That seems to have to work…but it doesnt, unless i do change my Lora Packet Forwared to “Lora Gateway MQTT bridge” which i get the information i want…but lose connection to my application topics.
I got the point to get only one of the information i want but not both at the same time…
I really think i am missing something in the configs…
Oh i see…but is my software old then? i though i had installed the latest firmware 
I’m not sure what you are changing there - hopefully you are not changing the gateways own settings.
You will need to distinct MQTT clients to subscribe to both gateway/ topics on the gateway and application/ topics on the pi-hosted broker.
Oh i see…but is my software old then? i though i had installed the latest firmware
AFAIK all firmware builds for the “industrial” gateways use old versions of LoRaServer from before the rename to Chirpstack and substantial implementation changes that happened around the same time. It’s much easier to update Chirpstack on a more conventional Linux platform like a cloud box or even a pi - including the pi based “developer” gateways.
Having the server in the box is great as an introduction or portable demo, but for a production deployment you really want to run the server in the cloud not in the field; and for a multi-gateway deployment, you basically have to.
That i am aware but getting the results i got described before.
Yes it does make sense, but right now for me that is not needed.
Put your gateway back on working settings.
Accomplishing you goal is about getting an MQTT client on something else (presumably the pi) to subscribe to the gateway topics feed on the gateway broker.
That should not require changing gateway settings.
It is working, my pi is subscribed to te application topics without a problem.
Now getting the gateway/ no i have no feed from there.
Leave the existing client subscribed to the pi broker for the application/ topics and add a second independent completely independent MQTT client to get the gateway/ topics from the gateway broker.
Talking in Node-RED language, i have setup 2 diferent nodes each with different clients. I do not get information off the gateway/ topic like that…only application.
If i do the change i said previously the node that reads the gateway/ topic receives messages and the application /topic stops to receive.
Again, you are going to need to have an entirely separate MQTT client to obtains the stats messages.
Do not change the settings of your your existing one, create another entirely independent one so that it can have the necessarily different setting of being pointed at a different broker.
If you can’t have distinct clients which are completely independent and subscribed to different brokers within one instance of Node-RED, it may be that you’ll need two distinct instances of that as well.
In the end though, there’s really not that much interesting in the stats messages.
Isn´t it what i already have?
A MQTT client does not mean 2 different brokers, just a broker with two clients…and that is what i have.
Or am i thinking wrong?
Node-RED does all that…I will but my gateway to default settings and retry…because something is odd on the “it should be working” and my side clearly isn´t ( and it has nothing to do with MQTT)
Thanks for the help i will report back!
No.
Your two very distinct types of data actually exist on two distinct brokers.
As such, you’re going to need two distinct clients to retrieve it.