ChirpStack Application Server is an open-source LoRaWAN application-server.
MIT License
Bot releases are hidden (Show)
Published by brocaar almost 4 years ago
Published by brocaar almost 4 years ago
Published by brocaar almost 4 years ago
This release adds a per-application Pilot Things integration. (#527)
dns
back to passthrough
,tls_enabled
option to Redis configuration.UplinkMsgWifi
+ wifi stream record workaround for LoRa Cloud DAS integration.Math.random
by window.crypto
in UI.Published by brocaar about 4 years ago
Published by brocaar about 4 years ago
Published by brocaar about 4 years ago
This implements the handling of LoRa Cloud Device & Application Services GNSS payload on pre-configured port (default 198).
Implement global and per organization dashboard of active devices and gateways. Please note that for devices, you must configure the expected uplink interval in the device-profile so that ChirpStack knows the difference between an active and inactive devices.
logout_url
configuration option for OpenID Connect authentication.Published by brocaar about 4 years ago
Published by brocaar over 4 years ago
This feature makes it possible to use an OpenID Connect authentication backend together with ChirpStack Application Server, for example Auth0.com. Users are automatically matched based on email address on the first login. If there is a successful match, an external OpenID Connect user identifier is associated with the user, so that even in case of an email address update, it can still be matched (and updated in the ChirpStack Application Server database).
The implementation of this feature required a couple of changes:
Usernames no longer exist in ChirpStack Application Server and have been renamed to email. Existing users can still login with their username, but on user update, the username must be set to an email address.
Previously there was an unused email field. As there was no guarantee that this field was unique this field has been deprecated. It is still present in the database as email_old
so that the new email
field (containing the old username
as value) can be updated by hand if needed.
Creating new users as an organization admin has been removed. However, the OpenID Connect integration provides a registration_enabled
option, which automatically creates new users when it does not exist.
Together with the registration_callback_url
, it can be used to automatically onboard new users. When this option is set, ChirpStack Application Server will make a HTTP request to configured URL when a new user is created. This makes it possible to implement an onboarding service which (using the API) could:
Previously there was an auto-complete field to assign an user to an organization. As the username has been replaced by email and to not leak email addresses, the autocomplete function has been removed and the exact email must be given when associating a given user with an organization.
This migrates the geolocation integration from ChirpStack Network Server to ChirpStack Application Server and allows a per-application integration configuration. The LoRa Cloud Geolocation integration provides support for TDOA, RSSI, Wifi and LR1110 based GNSS geolocation.
This implements the integration with the LoRa Cloud Device & Application Services.
This feature makes it possible to (temporarily) disable a device.
This (global) integration makes it possible to forward events to a Kafka broker.
When also configured in ChirpStack Network Server this makes it possible to generate per-gateway client-certificates which can be used to implement gateway authentication and authorization. For example a MQTT broker can be configured to validate the client-certificate against a pre-configured CA certificate and if valid it can use the CommonName of the certificate (which contains the gateway ID) to authorize publish / subscribe to certain topics.
This option makes it possible to configure the maximum gateways and devices that can be created per organization.
It is now possible to configuring per-application integrations for AWS SNS, Azure Service-Bus and GCP Pub/Sub
The interface to configure per-application configurations has been re-implemented.
This updates the HTTP integration with a single endpoint configuration. Instead of configuring a per-event endpoint, this makes it possible to have a single endpoint to which all events are posted, with the event
as query parameter.
This update makes it also possible to configure the marshaler (JSON, Protocol Buffers and legacy JSON v3) per HTTP integration.
Already configured HTTP integrations are not affected by this update but it is recommended to update your configuration so that you will automatically receive new event-types when they are introduced.
The MQTT integration has been updated with new MQTT topic configuration. Instead of configuring each topic separately, an event_topic_template
template can be configured, which is used for all events. The command topic(s) can now be configured through the command_topic_template
variable. In case the old configuration is still present, then the old topic configuration will remain active for backwards compatibility.
Important:
For consistency with the other components, the new configuration does introduce a change in MQTT topics (default configuration):
application/[ApplicationID]/device/[DevEUI]/rx
-> application/[ApplicationID]/device/[DevEUI]/event/up
application/[ApplicationID]/device/[DevEUI]/join
-> application/[ApplicationID]/device/[DevEUI]/event/join
application/[ApplicationID]/device/[DevEUI]/ack
-> application/[ApplicationID]/device/[DevEUI]/event/ack
application/[ApplicationID]/device/[DevEUI]/error
-> application/[ApplicationID]/device/[DevEUI]/event/error
application/[ApplicationID]/device/[DevEUI]/status
-> application/[ApplicationID]/device/[DevEUI]/event/status
application/[ApplicationID]/device/[DevEUI]/txack
-> application/[ApplicationID]/device/[DevEUI]/event/txack
application/[ApplicationID]/device/[DevEUI]/location
-> application/[ApplicationID]/device/[DevEUI]/event/location
application/[ApplicationID]/device/[DevEUI]/tx
-> application/[ApplicationID]/device/[DevEUI]/command/down
It is now possible to also generate per-organization API keys in the web-interface for easy integration with the gRPC and REST API.
Published by brocaar over 4 years ago
This makes it possible to generate (and revoke) API keys directly from within the web-interface. Internally, a lot of authorization code has been cleaned up to remove duplication and make the code easier to maintain. (#421)
This release introduces the support for Redis Cluster and Redis Sentinel.
objectJSON
formatting in web-interface.updated_at
field on organization user update. (#430)Published by brocaar over 4 years ago
The monitoring configuration has been updated so that it is possible to configure both a Prometheus endpoint at /metrics
and healthcheck endpoint at /health
. This change is backwards compatible, but to use the /health
endpoint you must update your configuration.
This makes it possible to store additional user-defined key/value configuration per gateway. Metadata pushed by the ChirpStack Gateway Bridge is now stored by the ChirpStack Application Server and visible under metadata.
This makes it possible to store additional user-defined key/value configuration per device-profile.
The myDevices Cayenne endpoint is now enabled for the myDevices integration.
tagname:tagvalue
)./health
endpoint.Published by brocaar over 4 years ago
This release provide new error events for OTAA errors, frame-counter resets and re-transactions / replay-attacks (requires ChirpStack Network Server v3.7+). It also adds new error events when the gateway reports an error on downlink scheduling (e.g. collision, invalid frequency, ...).
This publishes an acknowledgement when an item from the queue has been sent to the gateway for transmission and was accepted by the gateway.
This new integration makes it possible to forward payload events to myDevices IoT in a Box. myDevices Cayenne integration will be made available soon.
This adds a configuration option log_to_syslog
. When enabled, log items will be forwarded to syslog.
device_activation
table and code.Published by brocaar almost 5 years ago
This new integration publishes device events to an AMQP / RabbitMQ message broker.
This makes it possible to store (for example) calibration values as device variables and use this variable in the JavaScript codec.
This cleanup optimizes the API authorization functions by using a SQL query specific to each function, instead of a shared SQL query joining all tables.