Pass additional uplink metrics to the backends

[proffalken]

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

Summary

At present the values for RSSI, SNR, and fCnt are passed through to the various backends when a packet is received.

It would be fantastic to see the SF and DR values passed as well so we can graph these in Influx/Grafana/etc.

What is the use-case?

We have a couple of sensors that are right on the edge of the network as far as coverage is concerned. In the Chirpstack dashboard, we can see that there are a number of devices using different DR's, but we can't see a breakdown of what those devices are, nor can we see how a device has utilised ADR over time.

If we were able to store this data in our backend database (InfluxDB in our case) then we would be able to track the sensors over time as they are placed further and further away from the gateway to prove whether they are actually using ADR or not.

Implementation description

ADR values including SF and DR should be passed to the backend databases.

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

I can give it a go, but I don't really have the skills! :)

[jpmeijers]

I would like to see these parameters exposed too. Data rate is currently available and one can guess the SF and BW from there, but explicitly stating the SF and BW used for the uplink would prevent any incorrect assumptions.

Also Coding Rate is important: https://github.com/brocaar/chirpstack-application-server/issues/566

[omogenot]

Please add power as well.

[jpmeijers]

Power: The LoRa Network Server does not know what power level an end device used to transmit, as the end device does not report this as far as I know. We can however guess from the last ADR downlink that was sent. I however do not think we should add a "guessed" value into the metadata.

[omogenot]

Well, in terms of stats, it could be a nice to have value. No one prevents you from labelling this value as "Last ADR requested value" :-)

[brocaar]

I would like to see these parameters exposed too. Data rate is currently available and one can guess the SF and BW from there, but explicitly stating the SF and BW used for the uplink would prevent any incorrect assumptions.

In this context I'm not sure if I agree with this, the problem is that this information is modulation specific, e.g. not all the data-rates have a spreading-factor (FSK and LR-FHSS).

[brocaar]

nor can we see how a device has utilised ADR over time

Are you sure this is not possible? When I implemented the InfluxDB integration, I posted an example dashboard:

Please take a look at the Channel usage heatmap, this is querying the frequency tag (aggregating the channel usage over time). The same could be done using the dr tag to graph the data-rate usage of a device over time.

Also I think it is better to store the dr as a tag instead of value. Note that in InfluxDB tags are indexed, where values are not. Storing the dr as tag means that you can aggregate (e.g. group by) on the dr, for example to create a data-rate usage heatmap.

[proffalken]

Hey all,

Sadly my company has had to close down as a result of both Brexit and Covid and as a result I'm no longer using Chirpstack.

This means that I won't have the time to be able to shepherd through this change, is anyone else able to take it on?

[brocaar]

I'm sorry to hear that @proffalken :(