This makes it possible to configure one or multiple DevAddr sub-ranges
instead of using the whole DevAddr range provided by the configured
NetID.
Closes#49.
This type defines the (NetID derived) prefix that must be used when
generating device addresses. This can be retrieved from the NetID, but
it is also possible to define a prefix that defines a smaller address
range within the NetID.
See also #49.
In case the codec returns a NaN float, this is converted to None to
avoid Protobuf serialization error. This also fixes the eventlog such
that it does not break out of the loop (unless it is a channel error).
Messages that can't be processed will be ignored and an error is
printed.
Fixes https://github.com/chirpstack/chirpstack-v3-to-v4/issues/4.
As the spawn_blocking thread is not terminated when the frame_log_future
is dropped, it would keep the Redis connection open. By closing the
redis_rx channel on client-disconnect, we can check if the channel has
been closed inside the spawn_blocking thread, and return if this is the
case.
Closes#40.
Depending the channel-configuration, this would send three LinkADRReq
mac-commands while the same configuration could be send to the device in
two LinkADRReq mac-commands.
The env. variables are used such that the same configuration can be used
for Docker images, .deb and .rpm packages. However, if installing .deb
or .rpm packages, this can be confusing as executing 'chirpstack -c
/etc/chirpstack' will fail because these environment variables are only
available when using systemctl to start the ChirpStack process
(configured in the .service configuration file).
In case of mult-server deployments, this can be confusing as each VM
generates different certificate files by default, where all instances
must share the same certificate (or at least CA certificate + key).
The other issue is that the MQTT broker certificate must contain the
correct hostname, which can (most of the times) not automatically be
retrieved. Documentation to generate these certificates can be found
here:
https://www.chirpstack.io/docs/guides/mosquitto-tls-configuration.html
In some scenarios, this check returned true while the avx2 extension was
not available (e.g. QEMU emulated CPU).
See for more details: https://github.com/RustCrypto/hashes/pull/386.
