You can configure the Chirpstack gateway bridge with an MQTT integration so that it sends the decoded packages to an MQTT broker. In the documentation I noticed that there is the Chirpstack MQTT Forwarder that (at least to me) kind of does the same thing. So what is the point of the
Chirpstack MQTT Forwarder if the gateway bridge does the same thing?Am I missing something obvious here?
They are similar in that they serve the same purpose: To connect gateways to ChirpStack over MQTT. However, there are some differences:
Gateway Bridge is older in design, written in Go, and can run either on a gateway (if memory allows) or as a cloud service.
MQTT Forwarder is newer, written in Rust, and can run on memory-constrained gateways where Gateway Bridge cannot. It is not designed as a cloud service.
IMO: When used with TLS-enabled MQTT broker, both on-gateway approaches are more secure than running a UDP packet forwarder over the Internet to a cloud service. If you’re starting fresh today, I would recommend using MQTT Forwarder on the gateway.
3 Likes
Thank you for the explanation.
I cannot change the gateway and cannot install anything on it, so I will have to use the gateway bridge. But I will consider using the MQTT forwarder when I build by own gateway (right now I’m waiting for the miniPCIe concentrator card to arrive).
But there is one more thing that I don’t understand yet. In the documentation of the configuration of the MQTT forwarder there is no mention of the basic_station backend like in the documentation of the configuration of the gateway bridge. Does that mean that the MQTT forwarder does not support basic_station (thus no websocket)?
Thanks.
Correct, the feature sets are not identical. MQTT Forwarder supports concentratord and semtech_udp. If I wasn’t already using the gateway-provided Semtech UDP for my current gateways, I would likely try concentratord.
1 Like
Running the gateway bridge as part of the LNS (in the cloud or just as another service on your PC), allows you to not couple the gateway with Chirpstack.
The GWMP (Semtech UDP Packet Forwarder’s protocol) and BasicStation are perhaps the protocols that can be understood by most LNS out there, being created by the company (Semtech) that provided a lot of technology to the LoRa world.
On the other hand, the MQTT data used by all these Chirpstack components, is a Chirpstack-specific format.
BasicStation is a protocol created by Semtech and uses WebSockets, which can be secured by TLS.
1 Like
Originally TrackNet. What a trip.
To provide some context, the ChirpStack MQTT Forwarder was created because some devices have very limited amount of memory (e.g. MIPS based Dragino or RAK gateways). Installing the ChirpStack Gateway Bridge was problematic on these devices because of the size of Go binaries. With some tricks, it was (sometimes) possible to run the ChirpStack Gateway Bridge (e.g. compressed binaries), but it was not very reliable. The re-implementation in Rust drastically reduced the binary size.
As the ChirpStack MQTT Forwarder is aimed for installation on the gateway, there is also less complexity. If you are using the Semtech UDP Packet Forwarder or Concentratord on your gateway, I recommend to install the MQTT Forwarder on your gateway. If you are using a Basics Station based gateway, then install the ChirpStack Gateway Bridge in the cloud.
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.