Handling downlink event to send downlink data to a persistant storage

[BerdinEge]

• I have searched the issues of this repository and believe that this is not a duplicate.

Summary

There is an integration named Postgresql in Chirpstack and in this integration we can store device uplink data optionally. Why dont we also store downlink data ? I need it to see which Mac Commands device has received in certain dates.
Network server handles uplinks and creates downlink when its necessary. NS also send every uplink data to AS. AS sends this uplink data to integrations. We can also send downlink data to AS and AS should send this data to integrations.

What is the use-case?

I will be able to see downlink payloads in postgresql integration( loradatastore ) when this feature implemented. I need a persistant storage to read downlink data and use it on an application. Redis streams or API requests are not the correct way to do this work. Chirpstack should write downlink data to a persistant storage just like uplinks. I also work with other LoRa Servers. They store downlink data in a persistant storage too.

Implementation description

There is a task named "sendFRMPayloadToApplicationServer" in NS that sends uplink data to AS. I implemented a new task in downlink data.go named "sendFoptsToApplicationServer" to send downlinks(just like the uplinks' sendFRMPayloadToApplicationServer task).
There will be some changes in downlink handling and integration handling logics of AS. I implemented the changes in AS. It also requires new protobuf definitions and publishDownlinkRequest class(and some other classes) in Chirpstack API. I implemented them too.

Can you implement this by yourself and make a pull request?

I already implemented it and testing it now. I can make a pull request when it become production ready.

[brocaar]

I'm currently not planning to support this. There are two ways which allow you to inspect the uplink / downlink mac-commands (and PHYPayloads in general):

• The live LoRaWAN frame-logs in the web-interface
• The Redis streams that you can configure through the NS configuration

The reason to expose this as a Redis stream is that it allows you to persist it in your database of choice, you are not tied to PostgreSQL or a pre-defined db schema. The Redis Stream is not the final storage, it is a buffer which will persist the data until you have consumed it.