This adds a Gateway Mesh section to the web-interface (+ API endpoints)
to see the status op each Relay Gateway within the Gateway Mesh.
The Gateway Mesh (https://github.com/chirpstack/chirpstack-gateway-mesh)
is an experimental feature to extend LoRaWAN coverage throug Relay
Gateways.
onFocus is only triggered when when dropdown doesn't have focus where
onDropdownVisibleChange is always triggered when opening / closing the
dropdown.
Closes#334.
In general ChirpStack is configured with a rx1_delay configuration
matching the network latency (e.g. on cellular, one might want to set
this to rx1_delay=3). However, this does not take into account a
possible latency of the end-application. Handling the uplink and
enqueueing a downlink might take more time than the configured rx1_delay
(and get_downlink_data_delay) allows.
This option makes it possible to increase the RX1 Delay in the
device-profile. If the RX1 Delay has between increased relative to
the system default, then the get_downlink_data_delay will be
incremented with the same amount of seconds.
All these files can be generated using the `make api` command and there
is no real need to commit these into the repo. Only the api/go files
need to be comitted of how the Go import system works.
This also updates the Rust, Go, JS and gRPC-web (JS) code generation and
UI build to use the nix-shell environment instead of using Docker.
The z-index of the header was set to 1000 and the drawer header is behind the UI header so single frame download and title not displaying
Setting the z-index to 1002 is enough to fix the Drawer header issue.
This aligns the multicast class-b ping-slot configuration with the way
how it is configured in the device-profile. This deprecates the
class_b_ping_slot_period field in favor of the class_b_ping_slot_nb_k
field, which should be a value between 0 - 7 (this is defined and
explained by the LoRaWAN specification).
Closes#255.
There can be multiple reasons for this, e.g. it is not supported by the
browser or the browser does not provide this feature because there is no
secure context (HTTP).
Closes#231.
If enabled, metrics will be automatically detected and created based on
the decoded payload. The key will be set, but the name is left blank for
the user to configure. This can be confusing as it leads to validation
errors in the device-profile form if the name is not filled in.
The UI does show that one of the fields failed to validate, but even
with such notification, it is not clear that users have to check one
of the form tabs which they didn't edit on save.
This makes the name optional and uses the key as fallback such that
saving the form no longer fails in case the name is still blank.
Closes#313.
Note that the integration events will contain the application +
device-profile + device tags. Integration events will NOT contain the
tenant tags. Most likely tenant tags will be used to store information
about the tenant, data that is unrelated to the integration events.
Fixes#211.
This implements end-to-end encryption between the end-device and
end-application. The encrypted AppSKey or SessionKeyID is forwarded to
the end-application which should be able to decrypt or request the
AppSKey to decrypt the uplink payload. As well the end-application will
be able to enqueue encrypted application payloads.
Using this mechanism, ChirpStack will never have access to the uplink
and downlink application-payloads.
