Guidance on Data Flow & Best Practices for a LoRaWAN Network with ChirpStack

[Liam_Philipp]

@sp193 has very good answers to these but I couldn’t help giving my own 2 cents.

@arthursd

1a) Decode uplinks first and then store them in a database (if so, which type of database is best suited)?

Decode the uplinks in Chirpstack, then use an integration to pass the JSON data to your application. The database choice is up to preference and whatever is best suited for your application.

@arthursd

1b) How is this usually handled in real-world implementations?

Using the redis streams is typically a layer deeper and more complicated then is necessary. For our application we use the EMQX integration, which is essentially MQTT++. This allows for more easily activating real-time triggers like alerts based off uplinks, instead of needing to constantly monitor a database for changes. That being said we do then store necessary data from the EMQX messages into SQL for our application to pull in the future. Do not use the gRPC API for retrieving uplinks, Chirpstack is not meant to store data itself and deletes it after 10 or so uplinks, the proper way to get the uplinks out of Chirpstack is with an integration.

@arthursd

1c) If multiple sensors of the same type exist, what’s the best way to retrieve and differentiate their data? Should I tag them somewhere (e.g., in ChirpStack, within the database itself, or in a separate table storing additional device information)?

Sp’s answers here are probably the best solution. For our purposes we do not need to pull geographically but instead by client, so we are using a separate application in Chirpstack for each client, typically that also ends up being geographical.

@arthursd

Would you consider MQTT a must-use technology in modern ChirpStack implementations?

I wouldn’t say it is must use as an integration (obviously it is a must use on the backend), but I’d say it’s the most useful for real-time data processing. If there are no real-time actions that need to be done from your application based on uplinks (for example if your application is only for summarizing data when needed) you could consider other integrations. EMQX also works for the real-time trigger requirements.

@arthursd

What are the practical use cases for gRPC in a ChirpStack-based setup?

I use the gRPC API for any interaction our portal must make to control Chirpstack, but not to monitor it. For example when a new user signs up, we create an application in Chirpstack via gRPC. When they want to change their device settings, we send a downlink to the device. When they want to add a device to their account, we use the gRPC to create one in Chirpstack. Etc…

@arthursd

What is considered a good or best-practice data flow for a LoRaWAN network?

Really depends on your application but I would say 2 as well. For example our application receives the data from Chirpstack via EMQX, then translates what it needs into a persistent database. So it falls into #2.

As an aside to these questions. If you’re running a large project you also likely want to look into some high availability and redundancy measures. I am currently working on this for our own deployment and if you’re interested you could get some ideas from my plan. It certainly is not the be all end all, or even the most practical setup for many deployments, but it will work well for our purposes: HA and redundancy for Chirpstack - #2 by Liam_Philipp