Hello, we are creating an application, and we are using mosquito and chirpstack gateway bridge, but we don’t want to use the application server, we want to read the messages directly from the queue. We have the code for MQQT ready, and we are reaching the messages with the byte array payload from /event/up topic, but we cant decode it to insert the latitude and the longitude to our database. Can someone help us?
Having been in this position many times, I’m of the opinion that it’s highly advisable to write a wrapper between your devices and ChirpStack’s devices, than to write and maintain your own application server.
Also, make sure you’re starting with ChirpStack v4.
It’s a pain to maintain two databases, when I create an organization in my application, I need to connect with ChirpStack API to create an organization, and then create an organization on my database keeping the id of the Chirpstack database, the same with the applications, and the same with devices. I want to keep only one device, only one organization (in our database is a ranch), and one application (in our database is a Land) and read the messages directly from the MQTT queue.
I saw we need to add the OTAA keys and the encryption is AES-128, but if Chirpstack is open source, I don’t know why I don’t find some methods on the Chirpstack code that is on GitHub.
If you believe in open source philosophy, can you share with us how to decrypt the messages?
By right, the data is encrypted between nodes and servers.
So gateways or gateway bridges should not be able to read the messages between nodes and servers.
I don’t want to decode the mesage on the gateway bridge, i want to do it in My Main server. But, can someone explain me how to decrypt the payload? Let me decide what is the best approach.
I believe everything is already open-source? You will find all the code here:
This includes encryption / decryption of data.
You will find documentation how to use the lrwn crate (see the above GitHub link) here:
For ChirpStack v3, you will find the lorawan Go code here:
Also this code is well documented:
I agree with @bconway. Handling LoRaWAN frames is a lot more than the encryption / decryption. You also need to maintain the state of the mac-layer, different protocol and regional parameter revisions etc…