This makes it possible to automatically remove items from the queue in
case the expires_at timestamp has reached. This field is optional and
the default remains to never expire queue-items.
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.
This needs to be tracked by git to make cargo publish work. If this
folder is in the .gitignore, then cargo publish will ignore this folder
as well and the publish command will fail because of missing .proto
files. If we would temporarily remove / rename the .gitignore file, then
cargo publish will error because the git state is dirty.
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 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 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.
This includes:
* Changing the modulation parameters to its own type.
* Changing the timing parameters to its own type.
* Change the gateway_id to string. As the json encoding for bytes fields
is base64, this was confusing some users.
* Change the uplink / downlink id to uint32 from uuid. A string
representation of the UUID field (for the same reason as the gateway
id) would consome quite some additional bytes. An uint32 provides
sufficient uniqueness for the purpose of uplink / downlink.