ChirpStack Application Server is an open-source LoRaWAN application-server.
MIT License
Bot releases are visible (Hide)
Published by brocaar over 2 years ago
Published by brocaar about 3 years ago
This adds the following metrics to the device overview:
rxInfo
if available for join event in PostgreSQL integration.This adds the following metrics to the gateway overview:
Published by brocaar about 3 years ago
By using a Redis Stream instead of Pub/Sub, the last frames and events (per gateway and device) can be retained, providing a configurable amount of history when opening the related pages (default is 10). This also improves the live frame and event logs interface to provide a better overview and faster rendering.
Note: Redis Streams requires Redis 5.0.0+.
This moves the multicast feature under applications, to enforce that all devices within the multicast group belong to the same application as the multicast group.
Before you upgrade, please validate that if you have any existing multicast-groups that:
If these conditions are met, ChirpStack Application Server will automatically migrate your multicast group(s) to the same application as your devices. In any other case, the migration will throw an error asking you to either remove the empty multicast group(s) or to re-assign the devices so that the above criteria are met.
This adds InfluxDB v2 support by making the InfluxDB API protocol version configurable when adding the InfluxDB integration.
UserInfo
call. (#613)Published by brocaar over 3 years ago
This adds the LoRaWAN 1.0.4 mac-version and RP002-1.0.0 and PR002-1.0.1 regional parameter revisions to the device-profile configuration.
This implements the ReEncryptDeviceQueueItems
method to the (internal) application-server API. This method is used by ChirpStack Network Server v3.13+ when it needs request the application-server to re-encrypt the device queue-items.
This implements automatic schema migrations for the PostgreSQL integration. When you have manually created the tables (as documented previously), then these tables will be automatically adopted and updated to the latest version. For newly setup integrations all tables will be created automatically. (#573)
txack
message. (#576)confirmed_uplink
and dev_addr
for uplink. (#579)marshaler
configuration when encoding rx_info
to JSON.tx_info
field for uplinks.txack
payloads into PostgreSQL database.Published by brocaar over 3 years ago
This removes FUOTA from the ChirpStack Application Server as well as handling the handling of application-layer payloads related to FUOTA. The reason for removing FUOTA is to provide more flexibility as it allows for custom FUOTA implementations. One such implementation is the ChirpStack FUOTA Server.
Like with the Gateway client-certificate feature, this feature makes it possible to generate application-specific client-certificates for authentication and authorization with the MQTT broker. In this case the CommonName is set to the application ID.
This feature makes it possible to make gateways private to a specific service-profile. When enabled, received uplinks can only be used by devices under the same service-profile. To enable you must assign a service-profile to the gateway and update the service-profile to enable the private gateways feature.
Note: this requires ChirpStack Network Server v3.12+.
This adds a ADR algorithm selection option to the device-profile. In combination with the ChirpStack Network Server pluggable ADR feature, this makes it possible to use different ADR algorithms for different types of devices.
Note: this requires ChirpStack Network Server v3.12+.