Gateway Stats Through MQTT

I have a question regarding receiving the gateway statistics thought the MQTT broker. Once you subscribe to a gateways topic do you automatically receive the gateway statistics of that gateway? If so how do you know if the statistics are based on daily or monthly aggregate data for example?

Stats from a legacy Semtech packet forwarder gateway at least are non-cumulative, just counting since the last report. Try it with something like mosquitto-sub and watch for a bit… On some of my gateways I’ve actually subscribed to the stats from another process as an independent a round-trip connectivity check and use them to update a little OLED display where I do add up the per-report counts to create totals alongside system and Internet uptime.

As long as both the gateway and you stay connected to the broker you’ll keep getting them; if you have a programatic MQTT client you may need to implement reconnect logic to handle the occasional Internet hiccup.


I think I might have a similar question:
I need to collect the statistics data from all gateways (gw id, number of messages received, join requests, etc), same data I see in Live Lorawan Frames.

I do have a MQTT user with rights to subscribe to Gateway topic:


user [username]
topic read gateway/#

But I am getting


Illegal character ((CTRL-CHAR, code 24)): only regular white space (\r, \n, \t) is allowed between tokens
at [Source:; line: 2, column: 2]

This looks like I need to have a decoder, but where I should define it? Is this even a correct way to collect the gateway stats?


Probably the marshaler value in your ChirpStack Gateway Bridge configuration is set to protobuf, which is a binary format. Either use Protobuf to decode the messages or switch to the json marshaler.

See also:

1 Like

Many thanks, that worked!

Also, in gateway-bridge toml config see:

Protobuf encoding (this will become the LoRa Gateway Bridge v3 default)

Is that something I should worry on a long term? marshaler=“json” will be deprecated later?


JSON is used if you want to debug and see what’s happenning under the hood. It’s easier for human to read those pair key values, however, in deployment case scenarios you don’t want to increase your payload over the network, then, there are some other ways where you can squeeze the payload and hence improve your system in terms of overhead. That’s when protocol buffers come to rescue.

With this being said, you can make sure that your are receiving the right information and then change to protobuf to reduce overhead.

What I can suggest is to enable this only in debug scenarios. Protobuf is the de-facto option since v3.

1 Like

Thanks for the explanations, getting more clear now.
In this case, I guess I need to understand how to use Protobuf to decode the data coming from Bridge over MQTT. Have not done it yet. But thanks for giving directions.

No, the Protobuf and JSON marshaler will co-exist :slight_smile: It was actually the json_v2 (in the previous major version) that got removed. Bot the Protobuf and JSON marshaler are using the Protobuf structs so there is no additional work at my side to keep these in sync.

1 Like

Got it. Thanks again for clarifications.