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.
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.
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.
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.
This solves #282 because the issue was that auto created measurements
did not have a name and without the measurements tab open, the error
was not visible.
Before ChirpStack v4.5.0 forceRender was not used on the Tabs.TabPane,
in which case the validation would not run on unrendered tabs, which
explains why the form could be submitted even with the empty
measurement names.
Closes#282.
This moves the onMessage handler out of useEffect and it fixes
appending the the array. The .unshift() method does not work
well using React.useState. It would prepend, but since it would not
change the array (it adds an item to the array), the update would
not propagate.
This refactor the UI components from class based element into function
based elements. This makes it possible to use hooks that are used now
by most React components. This also updates React and Ant to the latest
versions (+ other dependencies).
This makes it possible to add gateways to a multicast-group, which in
case configured will always be used for transmitting the multicast
downlinks.
This also moves the multicast class-c scheduling to the multicast-group
configuration. Options are delay between multiple gateways, or GPS time
synchronized transmission.
The device might not always send its periodicity to the network-server
(using mac-commands). As well there is some ambiguity about the default
ping-slot data-rates. While the Regional Parameters Specification
defines the default beacon data-rates, it only defines the default
ping-slot frequency for Class-B.
This also changes the API field from class_b_ping_slot_period to
class_b_ping_slot_nb_k, where ..._k must be between 0 - 7 as defined by
the LoRaWAN Specification. This removes some ambiguity as 'period' could
mean different things in different contexts.
The <Admin> block hides components when the user doesn't have sufficient
permissions to perform an UI action. Without this the 'Delete device'
button was visible, but on click, the user would be redirect to the
login page due to permission issues (API).
Fixes#71.
By selecting a region configuration, devices using the device-profile
will only stick to the selected region configuration, rather than the
configurations provided by the selected region common-name.
This change also renames the region 'name' option to 'id' in the region
configuration, as well it adds a 'description' to provide a human
readable description, which is used in the drop-down in the UI.
This also fixes the JS API generation. In a previous commit the the
protobuf package was updated, but the latest protobuf compiler no longer
supports generating JS code (this now requires an external plugin). This
has been fixed.
Please note that if you have implemented custom ADR algorithms that are
referring to the 'regionName' key, that you must change this to
'regionConfigId' (see the ADR code example).
In case the decoded payload contains random keys the auto-detect
measurements feature will add new measurements for each uplink. With
this option it is possible to turn auto-detection off to avoid
polluting the database with many measurements.
Closes#42.
