Lorawan-stack: Device MAC layer configuration in the console
Summary
Device MAC layer should be configurable from the console.
Replaces https://github.com/TheThingsNetwork/lorawan-stack/issues/1378
Why do we need this?
- Class B device creation/updating from the console
- Creation/updating of end-devices using non-default MAC layer settings (e.g. The Things Uno)
What is already there? What do you see now?
CLI as the only means of configuring device MAC layer
What is missing? What do you want to see?
Support for configuring all MACSettings fields.
Field priority list
High
All devices
- [x]
rx2_data_rate_index - [x]
rx2_frequency - [x]
factory_preset_frequencies
- [x]
Class A-specific (aka, all non-multicast devices)
- [x]
rx1_delay - [x]
rx1_data_rate_offset - [x]
resets_f_cnt
- [x]
Class B-specific
- [x]
ping_slot_periodicity
- [x]
Medium
Class A-specific (aka, all non-multicast devices)
- [ ]
max_duty_cycle - [x]
supports_32_bit_f_cnt - [ ]
use_adr - [ ]
status_time_periodicity - [ ]
status_count_periodicity
- [ ]
Class B-specific
- [ ]
ping_slot_data_rate_index - [x]
ping_slot_frequency - [ ]
beacon_frequency
- [ ]
Low
Class A-specific (aka, all non-multicast devices)
- [ ]
adr_margin - [ ]
desired_rx1_delay - [ ]
desired_rx1_data_rate_offset - [ ]
desired_rx2_data_rate_index - [ ]
desired_rx2_frequency - [ ]
desired_max_duty_cycle - [ ]
desired_adr_ack_limit_exponent - [ ]
desired_adr_ack_delay_exponent
- [ ]
Class B-specific
- Non-multicast
- [ ]
class_b_timeout - [ ]
desired_ping_slot_data_rate_index - [ ]
desired_ping_slot_frequency - [ ]
desired_beacon_frequency
- [ ]
- Non-multicast
Class C-specific
- Non-multicast
- [ ]
class_c_timeout
- [ ]
- Non-multicast
NOTE: Some of these may already be configurable (e.g. FCnt stuff), please update the checkboxes accordingly and check that these settings are places in correct places (i.e. it's not available for multicast devices)
I believe that class B and C-specific settings should be available for all devices, even for devices for which respective SupportsClass{B,C} is false. This way the users can (temporary) disable/enable class B/C operation whenever required and keep the specific settings.
Class A-specific settings should only be available for non-multicast devices.
How do you propose to implement this?
Add all fields from MACSettings https://github.com/TheThingsNetwork/lorawan-stack/blob/74c9da9a9e07a31d7103eabcd3440f9c80c24ea1/api/end_device.proto#L190-L284 as fields to Network Layer configuration. These fields should be configurable at all times, i.e. both on creation and update.
Use comments from the proto for description.
Can you do this yourself and submit a Pull Request?
@bafonins will handle it
rvolosatovs
All 9 comments
I am mostly done with the high priority fields for the MAC Settings configuration:
Screenshots
ABP:
class B:
OTAA:
However, in order to add all of them and allow the users to register, for example, The Things Uno via the Console the mac_state.factory_preset_frequencies field is missing. Im not sure how exactly this should be represented in the UI, currently I have these ideas:
- As multi-select:
IMO, such field makes selecting frequencies very easy. Additionally, we can present to the user frequencies based on the frequency_plan_id for the end device. However, as @rvolosatovs mentioned that inputs can have arbitrary values and do not necessarily depent on the frequency plan of the end device.
Additionally, for this approach it would be great to have an RPC to fetch presets of frequencies per band.
- As array of number inputs (similar to how we allow adding headers to webhook integrations):
This approach is more flexible, however, it takes more time for the user to set the field, requires typing frequencies.
- As multi-select with options to create new labels:
Basically, a combination of 1 and 2.
@rvolosatovs @johanstokking
bafonins
on 30 Mar 2020
I think having the list (2) is clearest, as that shows the order. And the order is important.
The frequencies can indeed be anything, but it would be very helpful to fetch them via an existing frequency plan.
johanstokking
on 30 Mar 2020
Adding compat/api cause we might need an NS rpc for getting the frequency plan.
johanstokking
on 30 Mar 2020
I think having the list (2) is clearest, as that shows the order. And the order is important.
Both select components (1) and (2) preserve the order as well.
The frequencies can indeed be anything,
With (3) arbitrary frequency values can be added as well
bafonins
on 30 Mar 2020
I think solution (2) is the cleanest as well, while (3) looks nicer for small amount of frequencies, having multiple (e.g. 4 or more) will look cluttered and hard to keep track of.
It would be great if we could have frequency suggestions for (2) in each textbox (from the proposed frequency plan RPC), so kind of what you see in (3), but per-textbox
rvolosatovs
on 30 Mar 2020
More or less done with the implementation, but want to wait for https://github.com/TheThingsNetwork/lorawan-stack/issues/2605 to be merged before making a PR to add tests for device wizard (including the mac settings handling)
bafonins
on 12 Jul 2020
What is the status here?
johanstokking
on 3 Nov 2020
@johanstokking https://github.com/TheThingsNetwork/lorawan-stack/pull/3065 is ready for review. I added all high and some medium priority fields.
bafonins
on 3 Nov 2020
Changing milestone of this issue no next up. All high priority fields together with some medium priority fields were added in https://github.com/TheThingsNetwork/lorawan-stack/pull/3065. Will come back to this later if any other fields should be added to the console.
bafonins
on 21 Dec 2020
Related issues
ZeroSum24
·
3Comments
htdvisser
·
4Comments
w4tsn
·
6Comments
johanstokking
·
8Comments
adriansmares
·
8Comments