Hello all.
I’m wondering what would be a good use case for ChirpStack’s MQTT integration of device data. For my understanding either the Gateway Bridge or the newly released MQTT Forwarder already send the device data to an MQTT broker/topic. Why would someone want to subscribe to that event topic and forward the data to yet another topic?
I can see use cases for Postgres, Influx, etc. but having a hard time wrapping my head around this idea.
Happy to hear your feedback.
Timo
You describe correctly that the data is sent from Chirpstack Gateway Brdige / MQTT Forwarder to an MQTT broker. From there you get to a chripstack server, which in turn can publish the data to another topic.
However, Chirpstack Server processes the incoming data. For example: decryption (on encrypted data), applying the codec, deduplication and others.
You will see that the data sent to an MQTT topic by the Chirpstack Gateway Bridge or MQTT Forwarder will therefore look different than when the Chirpstack server sends the data to an MQTT topic after processing.
So if you directly subscribe the topics which are used by MQTT forwarder and Chirpstack Gateway Bridge, you don’t have a Chirpstack server in between. And that’s where all the LoRa magic happens.
The MQTT integration is a great way to pull device data into another service in real-time, for which things like Postgres wouldn’t make sense, such as a data pipeline or larger IoT platform.
Most of my clients use ChirpStack as a small part of a larger platform. We typically subscribe to both the gateway (bridge/forwarder) topics and the device (integration) topics. For them, there is value in the gateway payloads, even if not using the encrypted device data.
There are other queue-based integrations available, but since we’re using MQTT for gateway payloads and for non-LoRa uses, MQTT wins for the device integration.
Thanks for your replies. This makes a lot of sense, especially the deduplication part. From your experience, does this mean that the integration into an external system and not through ChirpStack’s network server is not a recommended configuration? For example, subscribing to the MQTT device topics (i.e., “application/APPLICATION_ID/device/+/event/+”) and sending the different event types to some other pub/sub system.
I would like to use the MQTT broker/cluster for a larger platform and forward all events, whether coming from a LoRa gateway or some other source, to the same sink.
I think I got confused earlier 
The “application/APPLICATION_ID” topics are already the topics ChirpStack’s MQTT integration publishes the gateway data to, right? And in case of ChirpStack v4 the payload is encoded in Protobuf and not JSON, correct?
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.