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 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.
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 fallback was already implemented for reading the private key when
generating MQTT client-certificates, but it was not used when reading a
private key for connecting to the MQTT broker.
While it is recommended to use PKCS#8 private-keys, this will perform an
auto conversion for RSA PKCS#1 and EC P256 SEC1 private-keys to PKCS#8.
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.
This refactors the multiple update functions into a single function
accepting a change-set struct. This also adds a sanity check to make
sure we are not updating the gw loc when lat / lon / alt are all set to
0.
This migrates the device-sessions from Redis into PostgreSQL. This fixes
a performance issue in case the same DevAddr is reused many times
(e.g. devices rejoining very often or a NetID with small DevAddr space).
There were two issues:
The Redis key containing the DevAddr -> DevEUIs mapping could contain
DevEUIs that no longer used the DevAddr. This mapping would only expire
from the Redis database after none of the devices would use the DevAddr
for more than the configured device_session_ttl.
The other issue with the previous approach was that on for example a
Type 7 NetID, a single DevAddr could be re-used multiple times. As each
device-session could be stored on a different Redis Cluster instance,
there was no option to retrieve all device-sessions at once. Thus a high
re-usage of a single DevAddr would cause an increase in Redis queries.
Both issues are solved by moving the device-session into PostgreSQL
as the DevAddr is a column of the device record and thus filtering on
this DevAddr would always result in the devices using that DevAddr, as
well all device-sessions for a DevAddr can be retrieved by a single
query.
Note that to migrate the device-sessions, you must run:
chirpstack -c path/to/config migrate-device-sessions-to-postgres
A nice side-effect is that a PostgreSQL backup / restore will also
restore the device connectivity.
Closes#362 and #74.
