[feature_request] ChirpStack - Extended Device profile

Hey, brocaar!

Are there any plans to customize [regions.network] from region_#####.toml in Device Profile of ChirpStack server?

It would be very convenient to be able to customize the parameters of this section for different groups of devices, it would allow flexible and precise customization of the network to work with devices. Because now the network parameters are common for the whole network and a particular network server, which is often not very convenient.

I’m talking about the ability to change these settings in Device Profile. By default when creating a Device Profile you can use the values from region_#####.toml, but with the ability for users to change the settings and values they want.

[regions.network]

# Installation margin (dB) used by the ADR engine.
installation_margin=10

# RX window (Class-A).
# Set this to:
# 0: RX1 / RX2
# 1: RX1 only
# 2: RX2 only
rx_window=0

# RX1 delay (1 - 15 seconds).
rx1_delay=1

# RX1 data-rate offset
rx1_dr_offset=0

# RX2 data-rate
rx2_dr=2

# RX2 frequency (Hz)
rx2_frequency=869100000

# Prefer RX2 on RX1 data-rate less than.
rx2_prefer_on_rx1_dr_lt=1

# Prefer RX2 on link budget.
rx2_prefer_on_link_budget=true

# Downlink TX Power (dBm)
downlink_tx_power=27

# ADR is disabled.
adr_disabled=false

# Minimum data-rate.
min_dr=0

# Maximum data-rate.
max_dr=5
1 Like

This will probably not be supported. The reason is that in case of LoRaWAN networks, these configs should be defined by the network operator, not its users.

1 Like

I understand, but to some extent, LoRaWAN network operators are also users who manage their network. And this tool is just for them.

When describing this proposal, I assumed that it would be convenient for a network operator to be able to set these parameters for Device Profile when managing a large fleet of devices.

As I said, it is possible to make default values unchangeable for normal users, but for the administrator it should be possible to set/change these values in Device Profile.

I had experience of using other network servers where such functionality was implemented (I worked in LoRaWAN network operator with 2000+ Base Stations and about 1 million devices). And the functionality I am offering is very convenient in some non-typical scenarios. The ability to change the proposed parameters in Device Profile allowed either fixing the devices or realizing some very complex and remote projects.

Please consider implementing this functionality. It would bring chirpstack a few steps closer to a carrier-grade solution, which would be very cool!

Anything else confusing to you?

There is nothing confusing with your proposal, but at this moment I prefer to leave these settings in the .toml files. If it is needed, it is possible to create multiple region configurations already. E.g. if you would like to have one EU868 configuration with RX1 delay = 1 and one with RX1 delay = 3.

An other reason why I prefer these kind of settings centralized in the .toml configuration is that it makes it possible to make changes for all devices for a certain region configuration without the need to update all device-profiles.

E.g. one of my clients experienced issues with receiving downlink frames. The issue was a mix of high network latency and asymmetry in link budget. The gateway was reporting a good SNR for uplinks, but the devices were reporting a significant lower SNR. We changed the .toml configuration to increase the RX1 delay (to deal with the network latency) and RX1 DR offset (to use a lower DR for the downlinks). If this configuration would have been at many device-profiles, we would have needed to review all the device-profiles for that region and update them individually.

4 Likes

I forgot that in current versions you can already do that! This is exactly what I was talking about as my example!
Thanks for your comment, it makes me realize that this functionality is already implemented :slight_smile:

My original request was to bring the ability to edit the corresponding .toml file into the GUI of the server, it would be a bit more user friendly. (and the logic would remain unchanged). However, this feature may be a very low priority (if you decide to implement it at all)

Thanks!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.