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 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.
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.
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).
This makes it possible for external services to subscribe (through
Redis) for realtime events. E.g. a create, update or delete device event
could trigger an external synchronization.
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.
