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.
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.
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 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.
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.
