Chirpstack and Azure IoT architecture

#1

Hi, Sorry if my question is misplaced but I can’t really grasph this.

Im looking at building a Lora integration for Azure IoT.

I was under the assumption i’d need:
Devices → Gateway → LoRa Server (Chirpstack) → Azure IoT (Either IoT Hub or IoT Central) → data storage/end-user applications.

However, when I view some of the Chirpstack documentation it says:
Devices → Gateway → Azure IoT Hub → Service-bus queue → LoRa Server (Chirpstack). Link.

Also, in this architecture. It says:
Devices → Gateway → MQTT Broker → Chirpstack Network server → Chirpstack Application Server → Azure Service-Bus (Service-bus queue?).

Does anyone have any clarity on this?

#2

The links are for ChirpStack v3.
Better use Chirpstack v4 instead?

#3

At the moment v4 gateway bridge does not support Azure IoT Hub. i understand it will in the future though, so @adwp would need to run v3.

I would recommend using the Chirpstack Azure Quickstart guide, and then adapting from there to suit your requirements: Quickstart Microsoft Azure - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server

1 Like
#4

Im sorry, maybe I have misunderstood, but I was under the impression that Chirpstack would help me get the data from the devices/gateway to the Azure environment and not the other way around? Why would I need Chirpstack? What is the role of it? I believed I would let:
device → gateway → chirpstack → Azure IoT Hub → Azure data storage (e.g. Synapse Analytics).
The link you gave would mean:
device → gateway → Azure IoT Hub → Azure Service-Bus → Chirpstack → Azure data storage (e.g. Synapse Analytics)?

Could you possibly contribute with some clarity to my misunderstandings?

#5

The data would still need to flow to Chirpstack in order for the LoRaWAN packets to be processed by Chirpstack. Azure IoT Hub, to the best of my knowledge, does not have any built-in LoRaWAN network server. it would have no idea what to do with the packets coming from the gateway.
IoT Hub is just an MQTT broker which allows authentication of the gateways and passes the data to Chirpstack. If all you want to use Azure for is the data storage, you can just run a standalone Chirpstack instance on any Linux machine (not necessarily Azure) and then use the App Integrations to push data to Azure after.

#6

Thank you for your reply! This is really confusing to me, im sorry. But okay, lets say I have 10 LoRa devices and a multitech conduit AP gateway. Then how would the architecture look if I just want to store the data in time-series and enable fetching the data from e.g. Power BI or a web app?

If the Chirpstack gateway bridge forwards the data as Mqtt. Why can’t the Azure IoT Hub not be satisfied with that data and just forward it to a database? why would you use another Mqtt broker which sends the data to Chirpstack LNS? According to this the Chirpstack Gateway Bridge forwards Mqtt data to a broker. To my understanding that data could just be handled by Azure IoT Hub and then forwarded to other Azure services?

Also, what would be the cost roughly to host Chirpstack in a VM on e.g. Azure? The Things Network seems really expensive in comparison.

#7

I think what you’re missing is that LoRaWAN devices dont just send their data in plain text via an MQTT broker. The packets flowing from the gateway to the MQTT broker are encrypted and contain a bunch of other information that the Network Server (Chirpstack) needs in order to manage the device sessions and decode the payloads. without the data first going to Chirpstack, you wouldn’t be able to get any of the device payload information.

I’m not sure on pricing, but if i were you, and i was only using 10 devices, i’d spin up one of the cheapest Linux VMs, and do a docker installation of Chirpstack as it’s almost ready to go out of the box. You proably want to follow some of the install guides on the Chirpstack page. I’d also highly recommend reading up on LoRaWAN architecture in general, as it sounds like you’re pretty new and missing some key pieces of information that are causing a lot of this confusion.