If enabled, metrics will be automatically detected and created based on
the decoded payload. The key will be set, but the name is left blank for
the user to configure. This can be confusing as it leads to validation
errors in the device-profile form if the name is not filled in.
The UI does show that one of the fields failed to validate, but even
with such notification, it is not clear that users have to check one
of the form tabs which they didn't edit on save.
This makes the name optional and uses the key as fallback such that
saving the form no longer fails in case the name is still blank.
Closes#313.
This removes the aws-sdk-sns crate (+ dependencies) and refactors the
AWS SNS integration to use reqwest for the API call + aws-sign-v4 for
creating the AWS request signature.
Even with the messages being handled async (tokio::spawn(...)), during
high throughput or a burst of messages, the channel might still fill up
causing messages to be discarded without any error being printed.
This makes it possible to use a range of JoinEUIs per Join Server.
Use-cases are either Join Servers using a JoinEUI range or the
configuration of a "catch-all" Join Server prefix ("0000000000000000/0").
This improves the log output on the following points:
In case when .context(...) is used, the error printed in the logs would
only show the outer error. This has been improved to show the complete
chain of errors.
In many cases error! and warn! logs were used for logging related to
user input. This is very inconvenient when using log output for
monitoring as it can trigger alerts based on end-user mistakes. While
refactoring the logs, the following criteria has been used:
* error = Messages that need attention and that are within the domain
of the ChirpStack administrator.
* warn = Messages that should stand out of the other log messages, but
that might be end-user (or end-device) related. Depending on if you
have control of the full chain or not, you might or might not want to
be alerted based on these messages.
Tracing spans have been improved to make it easier to correlate between
log messages and events.
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.
Using sub-queries, the amount of potentially selected records is
reduced. As well the joins on api_key.tenant_id causes (or might
cause) seq scans, because api_key.tenant_id is nullable.
The gw_time defines the RX time by the gateway, the ns_time defines when
it was received by the NS. The latter could for example help to debug
latency between the GW <> NS.
The JSON encoding should only be used for debugging purposes! However
this change avoids showing errors in case there are unknown fields in the
JSON payload. This would happen when for example the MQTT Forwarder
and ChirpStack uses a different API version (which in case of Protobuf
would be fine, as long as the major version remains the same).
This removes the device lock that is stored in Redis to avoid Class-A
and Class-B / Class-C overlapping. Instead, it consistently sets the
scheduler_run_after timestamp, which indicates if the Class-B /
Class-C scheduler should consider scheduling downlinks for a particular
device.
This also updates the get_with_class_b_c_queue_items function to make
sure that multiple ChirpStack instances can execute the same query at
the same time, without getting the same set of data (as the device
records are locked for update and then updated with a
scheduler_run_after timestamp in the future).
This crate can be used to build external ChirpStack integrations.
The plan is to move all non-HTTP based integrations to external
repositories. The reason is that these integrations usually require
quite some external dependencies as these rely on their own SDKs.
